Що таке / чи є правильний спосіб сказати керівництву, що наш код смокче?

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

Деякі з основних моментів:

• Ми все ще використовуємо кадри (спробуйте дістати щось із запиту, майже неможливо)
• VBScript
• Джерело безпечно
• Ми "використовуємо" .NET - маючи на увазі, у нас є .net обгортки, які викликають COM DLL, що робить його неможливим легко налагоджувати
• Все в основному одна гігантська функція
• Код недоступний. Кожна сторінка має кілька файлів, які створюються щоразу, коли створюється нова сторінка. Основна сторінка в основному робить Response.Write () кучу разів, щоб візуалізувати HTML (runat = "сервер" - ніяк). Після цього може бути багато логіки на стороні клієнта (VBScript), і нарешті сторінка підпорядковується собі (часто зберігає багато речей у прихованих полях), де потім публікує сторінку, що обробляє, що може робити такі речі, як збереження дані в базу даних.
• Отримані нами технічні характеристики сміються. Часто вони закликають такі речі, як "автоматичне заповнення поля X з полем Y або поле Z", не вказуючи, коли вибрати поле Y або поле Z.

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

Що я можу зробити? Як я можу підняти ці питання? 75% моєї команди погоджуються зі мною і вже порушували ці питання, але нічого не змінюється.

Переконайтесь, що ви не надмірно реагуєте. Ви свіжі, напевно, не працювали багато (будь-яких?) Інших місць, і тому не готові до світу "реального життєвого коду". Реальний життєвий код - жахлива річ. Це як ваш гарний шкільний код та ваш нав’язливий підроблений особистий код проекту, займався сексом у підвалі ядерного реактора, і дитина виросла у каналізації токсичних відходів; це огидний мутант.

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

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

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

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

Повне переписання? Майже завжди погана ідея.

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

Читайте Joel On Software - речі, які ви ніколи не повинні робити. Зрозумійте його міркування, а потім прочитайте ще декілька статей про погане програмне забезпечення та способи його виправлення, написані менеджерами, а не програмістами. Озброївшись цією інформацією, ви зможете представити справу щодо її виправлення, з точки зору, яку менеджери розуміють і дбають про них. Підказка: Хороші менеджери не витрачають час і гроші, базуючись лише на думках та почуттях програмістів щодо того, що потрібно зробити.

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

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

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

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

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

По-друге, часто виникають міркування щодо витрат на покращення старих систем. Наприклад, я бачив більше ніж одну компанію, у якої ще працювали 10-річні VB6 та класичні додатки ASP. У деяких випадках це було через те, що великий проект з переміщення .NET не вдався. В інших, причина полягала в тому, що "якщо вона не зламалася, не виправляйте її". Але, в інших, вартість переїзду є виправданою, оскільки проблеми, спричинені спадковою системою, дуже ігноруються.

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

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

Найгірший підхід, який я бачив, - це спробувати зробити великий стрибок безпосередньо від застарілої системи до найновішої та найсвіжішої, наприклад, перейти від робочої, але незграбної системи VB6 / Classic ASP / COM + до системи MVC / Entity Framework.

"Ей, Бос, після Big Project я та команда хотіли б трохи часу, в ідеалі X місяців, організувати наш код. Речі, які повинні бути зроблені за лічені хвилини, займають години, тому що це все дуже неорганізовано. Якщо це неможливо зробити одразу після Великого проекту ми хотіли б запланувати реалістичний графік ".

(частково перефразоване з коментаря Аскара до питання)

Почніть читати Джоела на програмному забезпеченні (Joel Spolsky / Засновник Stack Exchange) ...

ПЕРШЕ, що я би зробив, це виконати тест Джоеля .

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

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

Сподіваюся, що це допомагає! Ласкаво просимо до програмування (вчорашній код зазвичай відстійний) ;-)

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

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

• Чи дійсно менеджмент диктує дизайн? Якщо у вас більша частина команди за вами, що вас зупиняє? Будьте ініціативними та приймайте рішення як група. Придумайте план його поступового виконання . Тоді зробіть це.
• Чи диктує менеджмент інструменти розробки, які ви використовуєте? Якщо немає часу на заміну управління інструментом, зазвичай це не хвилює. Будьте ініціативними та вирішіть, як група, які інструменти розвитку ви хочете використовувати. Якщо вам потрібно викупити у менеджменту, покажіть їм план міграції та аналіз вигідних витрат. Тоді зробіть це.
• Чи диктує менеджмент мови, якими ви користуєтесь? Будьте ініціативними та вирішіть, як група, що використовувати замість VBScript. Придумайте план його поступового впровадження і виконайте це. Якщо вам потрібна купівля управління, покажіть їм план. Тоді зробіть це.
• У мене немає нічого для специфікацій. Зазвичай це дуже залежить від людей та процесів на вашій роботі. Визначення того, що порушено, і мінімальних змін, необхідних для фіксації процесу, вимагає часу, аналізу та розуміння того, як зараз працюють справи і як вони повинні працювати. Якщо ви знаєте, що можете скласти план і спробувати переконати керівництво.

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

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

Прикладом може бути "Код недоступний":

Поточний код недоступний через X , Y і Z (перерахуйте причини, через які він неможливий). Це робить запити на зміни та нові функції дуже важко виконати, оскільки X , Y , Z (причини, через які вносити зміни, важко). Оскільки зміни важкі, команда розробників не може легко реагувати на виправлення помилок та вдосконалення.

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

Удачі. Вам це знадобиться.

"Я починав свіжий з коледжу", - повинен відповісти на ваше запитання.

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

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

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

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

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

Однак, це все ще хороший план рефакторингу та фіксації дрібних речей (наприклад, отримання хорошого VSS) на шляху керованих укусів. Зрештою, це технічне питання, а не управління. Просто зробіть те, що потрібно зробити, поки все ще виконуєте те, що обіцяєте, і ви будете добре. Керівництво, ймовірно, не буде цікавити тонких дрібних деталей якості коду, навіть якщо ви зробите вагомий випадок.

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

Шанс на перезапис трапиться досить низьким, якщо ви не зможете дуже чітко продемонструвати, що варто коштувати інвестицій $$$.

Керівництво не дбає про код. Вони дбають про те, щоб продати товар.

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

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

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

Важливо пам’ятати, хоча цей «старий» код завжди буде жахливим. Під цим я маю на увазі, ми всі зростаємо як розробники постійно. Ми пишемо хороший код, потім вчимося писати кращий код пізніше, і попередній "хороший" код здається жахливим. Занадто багато розробників потрапляють у постійні спроби покращити її і витратити більше грошей у довгостроковій перспективі. Це врівноважуючий акт. Коли говорити, це завжди чудово, якщо ти можеш зробити це краще, як йдеш. Коли ви перейдете до зміни цієї гігантської функції, розділіть її! Врешті-решт ти кудись потрапиш.

Не робіть цього.

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

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

Мені виконано завдання налаштування та розгортання у веб-проекті. Часто потрібно розв’язати несподівані проблеми щоразу, коли я розгортаю нову збірку. Більшість питань стосувалися безпеки та інтеграції (між декількома програмами веб / Windows). Наш код відстійний, чужий код смокче, вони повністю код спагетті.

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

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

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

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