Як довести, що програма побудована на неправильній кодовій базі?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У вашому випадку я думаю, що слід довести дві речі.

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

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

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

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

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

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

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

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

Речі, які насправді мають погану базу коду:

• Захисні отвори

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

• Робочий Broken

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

• Насправді не працює

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

Що не є поганою кодовою базою (просто непогано):

• Написано на застарілому непідтримуваному техніці. (VB6, COBOL, .net1.1 тощо)

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

• Недокументований / погано відформатований код

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

Ви певним чином відповіли на власне запитання.

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

Тоді проста пропозиція очищення цього масштабу коштуватиме X годин.

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

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

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

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

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

Є причина, чому все зріле програмне забезпечення схоже на безлад:

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