Я не можу програмувати, оскільки код, який я використовую, використовує старі стилі кодування. Це нормально для програмістів?

У мене є перша реальна робота програміста, але я не можу вирішити жодних проблем через стиль кодування, що використовується. Код тут:

• Не має коментарів
• Не має функцій (50, 100, 200, 300 або більше рядків, що виконуються послідовно)
• Використовує багато ifтверджень з великою кількістю шляхів
• Має змінні , які не мають ніякого сенсу (наприклад.: cf_cfop, CF_Natop, lnom, r_procod)
• Використовує стару мову (Visual FoxPro 8 з 2002 року), але є нові випуски з 2007 року.

Я відчуваю, що я повернувся до 1970 року. Це нормально, щоб програміст, знайомий з OOP, чистим кодом, моделями дизайну тощо, мав проблеми з кодуванням цим старомодним способом?

EDIT : Усі відповіді дуже хороші. На мою (не) надію, схоже, що в світі існує дуже багато подібної бази коду. Точка, згадана у всіх відповідях, - це рефактор коду. Так, мені дуже подобається це робити. У своєму особистому проекті я завжди це роблю, але ... я не можу переробити код. Програмістам дозволяється змінювати файли лише у тому завданні, для якого вони призначені.

Кожну зміну старого коду потрібно коментувати у коді (навіть із Subversion як контролем версій), а також метаінформацією (дата, програміст, завдання), пов’язаною із цією зміною (це стало безладом, є код з 3 використаними рядками та 50 коментуються старі рядки). Я думаю, що це не лише проблема коду, але і управління проблемою розробки програмного забезпечення.

Гаразд, я буду тупим. Це погане місце для роботи ... Я був у таких ситуаціях, і зазвичай це закінчується тим, що ти проковтнувся цим кодом. Через рік або більше ви звикнете до цього, і ви позбудетесь того, як сучасні альтернативи можуть бути використані для досягнення того самого завдання простіше, більш ремонтованим способом, а також, швидше під час виконання більшість випадків.

Я покинув таке робоче місце, тому що лише через місяць я відчув, що мене затягнули у старий код школи. Я намагався дати йому піти, але вирішив не робити. Я не міг використовувати чистий код і почав втрачати навички через відсутність щоденної практики. Будь-який сучасний підхід повинен був затвердити 3 шари розробників, що ніколи не траплялося, оскільки ідея полягала в тому, що все може зламатися, коли застосовуються сучасні підходи. І тендітний характер коду, який з’являється, коли ви не використовуєте сучасні підходи, досить страшно.

Не зрозумійте мене неправильно, є випадки, коли люди надмірно розробляють рішення, і я всі проти. Але втягнення в конвенції та стиль кодування до 80 років на довгий час зупинить ваш прогрес, а також, я думаю, кар'єрні можливості.

Потім знову потрібно заробляти гроші, тому іноді доводиться робити те, що точно не подобається. Слідкуйте за симптомами вигорання і перетворюючи кодування на щоденне завдання в цих випадках.

Цей стиль кодування (якщо ви навіть хочете назвати його будь- яким стилем) є поганим стилем кодування.

Можна писати короткі функції з описовими іменами змінних та регульованим нормальним потоком на більшості сучасних мов (Visual FoxPro сучасний, так).

Проблеми, які виникають у вас з поганою базою коду, ні більше, ні менше.

Таких баз кодів існує і багато - той факт, що у вас виникають проблеми з ними, свідчить про те, наскільки вони можуть бути поганими (і що ви добре навчаєтесь).

Що можна спробувати зробити - це покращити справи, де можна - перейменувати змінні, вилучити спільні риси та розділити великі функції на більш дрібні тощо. Отримати копію ефективної роботи за допомогою Legacy Code ...

Я над проектом C # з дуже поганою структурою, не за милі від того, що ви описуєте. Просто поєднано 12 окремих функцій (очевидна копія-вставка) в одну, яка приймає один параметр.

Це насправді не «старомодно», за винятком того, що хороші дизайнерські практики не завжди були настільки популярними. Це просто поганий код. Неправильний код когось сповільнює. Ви з часом звикаєте до цього, але це лише тому, що ви звикаєте до конкретних примх у вашій конкретній системі. З огляду на новий проект, ви можете знайти зовсім нові способи написання поганого коду. Хороша річ, що ви вже знаєте, як визначити ці запахи коду.

Найголовніше, що ви можете зробити, це не поширювати проблему . Не сприймайте ці шкідливі практики як звичай, якщо ваша команда не є. Зберігайте новий код чистим способами, які не змушують рефактор. Якщо це так погано і у вас є час, подумайте про головний рефактор ... але на практиці ви рідко володієте такою розкішшю.

Подумайте про додавання коментарів під час з'ясування речей, а невеликі шматочки та шматочки міняйте як практичні. Якщо ви не кодуєте соло, вам потрібно попрацювати з цією командою; якщо немає умов, вам знадобиться трохи часу, щоб придумати їх, і, можливо, покладіть на себе зобов'язання повільно покращувати базу коду, якщо ви все одно регулярно його підтримуєте.

Якщо ви знайдете повністю ізольовану функцію з поганими іменами змінних і все одно виправляєте її, ви можете також зробити імена змінних чимось корисним, переробляючи ifs. Не вносити змін до загальних функцій, якщо ви не збираєтесь переробляти велику частину.

• не майте коментарів - виправте це, як ви дізнаєтесь його
• не мають функцій (50, 100, 200, 300 або більше рядків, що виконуються послідовно)

Це, ймовірно, датується попередньою ітерацією коду. На даний момент я б остерігався тонких відмінностей між схожими на перший погляд кодовими блоками, які стали "особливостями". Але незалежно від того, наскільки ця ідея є поганою, її зрозуміти досить просто ... тож я не впевнений, де у вас виникнуть проблеми.

• використовує багато, якщо висловлювання з великою кількістю шляхів - я фактично не впевнений, що ви тут маєте на увазі
• має змінні, які не мають сенсу (наприклад: cf_cfop, CF_Natop, lnom, r_procod) -

Я наголошу на обережності з бітом "перейменування змінних". Є велика ймовірність, що ви просто ще не зрозуміли мову, а назви змінних матимуть набагато більше сенсу після того, як ви там деякий час будете там. Не кажучи про те, що проблемні імена змінних також не можуть бути, але ваші приклади виглядають так, що для них є логіка, якщо ви знали, що є поширеними абревіатурами на вашому сайті. Це, очевидно, не так важливо, якщо ти команда 1.

• використовує мову, з якою я незнайомий (Visual FoxPro 8 від 2002 р.) - це ваше питання, а не код

Це звучить для мене як можливість .

Зрозуміло, що ви вже можете бачити безліч проблем у тому, як робити та керувати справами. Ви можете поскаржитися, що це все сміття і що ви нічого не можете зробити, АБО можете використовувати це як золоту можливість дійсно показати своєму роботодавцю свою цінність.

Тепер це не допоможе вам, якщо ви підете до свого роботодавця і скажете йому, що все має змінитися. Тож хитрість полягає в тому, щоб пограти деякий час, задавати ЛОТОм питань, і коли вам потрібно буде написати код, вам потрібно буде грати за їхніми правилами з усіма коментарями тощо, як вам потрібно буде тримати інших розробників. поінформовані за допомогою тієї системи, яку вони зараз віддають перевагу, в той же час ви можете вводити обґрунтовані рефактори, які нічого вам не ризикують. Можна витягнути пару методів, і якщо ваша мова це підтримує, введіть кілька одиничних тестів. На запитання, чому ви це зробили саме так, або якщо вам сказали, що ви робите щось "не так", уникайте захисних чи аргументативних підстав, роблячи звукову презентацію своєї позиції для обраного стилю кодування. Наприклад, ви можете посилатися на книги, такі як «Чистий код» Боб Мартіна, або на інші книги, статті чи навіть питання та відповіді, які ви натрапили на Programmers.SE. Все, що вам може бути корисним для підтвердження вашої позиції фактами, які можуть перевищувати ваш досвід в очах людей, з якими ви працюєте.

Що стосується надмірного коментування, то щось із цього можна усунути, якби ви додали декілька описових імен змінних та методів, але ви також могли б зробити справу для гарної системи контролю версій та використовуючи це вести облік змін і дат тощо, а також використовувати інструмент для порівняння різних версій вихідних файлів, якщо вони вже не поставляються з обраним VCS.

Як я вже говорив, це можливість зробити свій внесок у вдосконалення команди розвитку, яка звучить так, ніби вона втратила свій шлях, так би мовити. У вас є можливість виділитися як кваліфікованим і знаючим, так і тим, хто може вести приклад. Це все хороші речі, які допоможуть вам пізніше, коли ваша кар’єра прогресує.

Ласкаво просимо до джунглів !

На жаль, часто починати працювати в компанії означає, що почати стикатися з подібними ситуаціями, якщо ви не працюєте в структурованій і добре організованій компанії, такі ситуації є досить звичними ...

Моя порада:

1. Почніть вивчати та ознайомтесь з: використовуваною мовою програмування (Clipper / dBase) та середовищем (Visual FoxPro)

2. Прочитайте та проаналізуйте базу коду та починайте коментувати її

3. впорядкування / рефакторинг коду (вирішення проблеми занадто багато рядків, виконаних послідовно)

Проблема зіткнутися з подібною кодовою базою - це нормально, але це може стати великою проблемою, намагаючись поліпшити якість коду та надати "свій дотик" до програми, покращуючи кодову базу, а можливо, зробити її кращою програмою ...

Щоб відповісти на ваше запитання: Так, люди / компанії скрізь використовують інфраструктуру, яка може бути побудована на шаленому коді. Інтегруючи себе в подібні ситуації, з цим може бути дуже важко впоратися.

Минулого літа я працював стажером, розробляючи заявку, яку використовуватиме команда з контролю якості, приєднана до певного відділу. Команда QA використовувала безліч самостійних сценаріїв (VBScript, Perl, Bash) для запуску тестів на базі даних тощо, і вони хотіли об'єднати їх в одну програму. Проблема в цьому полягає в тому, що ті сценарії використовувалися в інших місцях компанії (таким чином, основні функціональні можливості / назви змінних неможливо було змінити), і код "додавали" майже 10 років; багато лайна набралося.

Ось що ви можете в цьому зробити:

1. Зверніться за допомогою: ваші колеги по службі, яким довелося шукати, хоча цей код, мабуть, знайомий з його ідіосинкразіями. Те, що вас тупо і заплутало, для них ідеально добре. Тож просимо допомоги!
2. Рефактор, коли це можливо: якщо вам доведеться переглядати / підтримувати цей код протягом тривалого періоду часу, рефакторируйте його, коли зможете. Навіть якщо ви знайдете і заміните ім'я змінної, кожен маленький допоможе. Та компанія, яку я інтернував минулого літа, мала подібну проблему використання хизких змінних імен. Кожен шанс, що я міг би запустити їх код за допомогою гребінця з дрібним зубом, змінивши назви змінних, оптимізуючи логіку (згрупувавши різні функції разом у 1, наприклад) тощо. Робіть те саме, коли у вас є можливість!

Як і у всіх випадках, якщо зовнішні функції коду працюють належним чином, не має значення, як працюють внутрішні пристрої.

Я збираюся зробити кілька коментарів, які відрізняються від багатьох тут респондентів. Багато моїх коментарів можуть бути вам очевидними, але все-таки потрібно сказати.

• Будьте обережні щодо зміни коду, який ви не розумієте, поки не зрозумієте його.
• Якщо ви працюєте в командному середовищі, з кодом, над яким працюють ваші товариші по команді, обговоріть із ними свої зміни, перш ніж вносити зміни. Ніхто не любить "одинокого збройовика" зайти і змінити код, з яким всі інші знайомі. Це не означає, що ваші зміни не мають жодних гарантій чи «правильну» річ.
• Завоюйте свої ідеї. Отримайте всіх на борту зі своїми ідеями, тоді ви можете використовувати навички своєї команди для рефакторації, а не обтяжуючи себе всією роботою.
• Прибуток управління управлінням Можливо, вони зможуть виділити кошти для переходу та повторного розбиття коду.
• Звертайтеся до менеджменту з точки зору їх розуміння щодо переваг перенастроювання бази даних коду. Більш підтримуваний код означає менший витрачений час на вирішення помилок, додавання функцій тощо. Що означає економічну розробку. Швидший час розвороту тощо.

Додавати чисте кодування, пропозиції найкращої практики легко, не розуміючи політику вашого оточення. Люди, з якими ви працюєте, можуть не хотіти змінюватись або виділяти час на зміну бази коду, але намагайтеся продати ідею всім перед тим, як заскочити і змінити все (що має властиві собі ризики)

Сподіваюся, це допомагає.

Однією з речей, яка стикається, є ваш відредагований коментар

Кожну зміну старого коду потрібно коментувати в коді, а також метаінформацію (дата, програміст, завдання), пов’язану з цією зміною (це стало безладом, є код із 3 використаними рядками та коментується 50 старих рядків). Я думаю, що це не лише проблема коду, але і управління проблемою розробки програмного забезпечення.

У мене також є проект, де я успадкував спадкову базу коду FoxPro з багатьма питаннями, які ви описуєте. Однією з перших речей, які я представив проект, було гарне сховище вихідного коду. FoxPro може інтегруватися з SourceSafe, але цей продукт використовувати болісно.

Я схопив копію scx-інструмента Пола МакНетта http://paulmcnett.com/scX.php та інтегрував її в мій цикл розробки. Це дуже добре спрацьовує витяг двійкового коду FoxPro до текстового формату, який потім може бути поміщений у джерело сховища, як Subversion, Mercurial, або навіть git. (Ви можете знайти проект SubFox за адресою http://vfpx.codeplex.com .

Ці інструменти надають історію та дозволяють програмістам працювати із завданням підтримки коду. Навчитися користуватися цими інструментами напевно потрібно певний час, але оскільки всі вони безкоштовні, насправді не має сенсу не вкладати в них якийсь час. (навіть якщо ви не можете зробити так, щоб проекти Job рухалися таким чином).

Я рішуче погоджуюся з відповіддю funkymushroom. Якщо ви - командне середовище, переконайтеся, що інші знають, що ви перетворюєте код або реорганізуєте код, якщо ви коли-небудь плануєте отримати якісь гарні завдання.

З особистого досвіду я знаю, але не ваш стиль кодування, якщо ви підтримуєте код, який інші також змінюють та підтримують, залишайтеся у стилі існуючого коду. Додавання коментарів та роз’яснення чудово, але основна схема та конвенції повинні залишатися. Старі гуру / гармати проекту очікують, що код буде подібний до того, який вони бачили роками.

Коли клієнт кричить про помилку, ваше керівництво перейде до старих гармат, щоб усунути проблему якнайшвидше. Якщо ці старі гармати під тиском виявлять, що ви "очистили код", і тому їм тепер доведеться витратити час, щоб зрозуміти, куди ви переїхали чи перейменовані, що одна змінна, яку вони знають, потребує налаштування, ваше ім’я в компанії буде змінено на " грязь ».

Як тільки криза закінчиться, спочатку стара зброя звинуватить вас повільно вниз за критичне оновлення. Далі ви виявите, що утримуєте очищений код до тих пір, поки будете в компанії. Нарешті, коли з’являться нові цікаві проекти, ваші менеджери запитають гуру про те, хто повинен працювати над проектом, і якщо ви один раз їх накрутили, ви ніколи не перейдете до нового проекту, поки ваш корм не буде кинутий в кінці достроковий термін.

Якщо ви в коледжі дізналися «правильний» спосіб кодування, і ви зараз працюєте, забудьте про «правильний» спосіб. Це не завдання коледжу, ці проекти тривають не один семестр, вони можуть жити роками, і їх доведеться підтримувати групою людей з різним рівнем знань та різним рівнем зацікавленості в останній тенденції CS. Ви повинні бути гравцем команди.

Ви можете бути найбільшим програмуванням гарячих кадрів у школі, але на робочому місці, ваша перша робота, ви новачок з нульовим рахунком. Люди, які займаються програмуванням роками, не задумуються про вашу школу чи класи, це те, наскільки добре ви граєте з іншими і скільки розладів ви приносите в їхнє життя.

У свої 20 років я, здається, звільнив декількох програмістів тузів, головним чином тому, що вони вимагають робити все "правильно". Якщо ви не приносите щось дуже-дуже-дуже унікальне для роботи, ви є змінними. Ви, можливо, були у своєму класі, але наступного року хтось ще стане кращим у своєму класі та шукатиме роботу.

Я розглядаю це як вашу основну роботу - це зберігати свою роботу, поки ви не вирішите змінити роботу. Утримувати роботу означає, що ви повинні грати добре на ігровому майданчику, який хтось інший збудував і заплатив.

Я знаю, що звучу негативно, але завжди є надія. Коли ви наберетеся досвіду, матимете успіх, ви отримаєте вплив і зможете перекласти речі на кращий шлях. Коли ви пишете новий код або новий проект, натисніть на потрібні зміни. Якщо це новий код, старі гармати не сподіваються, що це буде так, як вони його залишили, і коли вони побачать переваги, вони можуть навчитися та адаптувати новий шлях.

Стара система може змінюватися, але це потребує часу. Якщо щось змінити, це може призвести до ризику та ризику ненависті до бізнесу, і вам доведеться зайняти час та роботу, щоб зробити компанію комфортною від змін.