Як реанімувати старий безнадійний проект. Частина 1 : Рефакторинг vs переписування з нуля

via Shutterstock .

Якщо у вас є старий безнадійний проект , перед вами неминуче рано чи пізно постане питання: що з ним робити далі ? Бо такий проект все більше нагадує ненаситного ненажерливого монстра : швидкість його супроводу невблаганно падає , а вартість обслуговування непристойно швидко зростає . Муки вибору : полагодити або зробити нове? Існує два діаметрально протилежні думки з цього питання . Топи та інші менеджеричасто переконані , що старий код немає потреби переписувати , бо « ??поки ми будемо переписувати систему - конкуренти вирвуть ініціативу і заберуть усіх наших клієнтів ». Менеджерів мало цікавлять технічні деталі питання , їх завдання - монетизувати продукт і рахувати гроші . Вони свято переконані в тому , що почати переписувати систему - це отримати гарантований фриз ( « заморозка » живого проекту - неможливість внесення будь - яких змін ) . З іншого боку барикад тиснуть технічні фахівці, акцентуючи увагу на тому , що система катастрофічно застаріла , її складно і нецікаво супроводжувати . І якщо нічого не поміняється , то через деякий час проект стане колом. Інженери в першу чергу зацікавлені в простій і зрозумілій супроводі проекту , їх мотивує робота з сучасними технологіями . Вони знають , що якщо залишити все «як є» - це неминуче призведе до фризу в осяжному майбутньому. Обидві сторони побоюються одного і того ж , але по - різному розуміють причини потенційної зупинки проекту. Що відбувається далі : все ініціативні технічні фахівці , будучи не почутими , йдуть. Швидкість супроводу системи продовжує експоненціально падати. Більш кмітливі конкуренти систематично вносять оновлення та нововведення в свої продукти , відбираючи ваших клієнтів . До цього моменту керівництво нарешті приймає вольове рішення: « Треба щось робити! » І перше , що потрібно вирішити , - це який з варіантів вам більше підходить : глибокий рефакторинг або ж « переписування з нуля ». Універсального ради у виборі між цими двома варіантами немає - все залежить від тяжкості кожної окремо взятої ситуації. Але перш ніж вибирати - проведіть консультаціїзі стороннім системним архітектором і аналітиком . Ці люди можуть направити вас на потрібний шлях . А як же виходять гарні проекти? Перш ніж продовжувати міркування про головний біль старих безнадійних проектів , давайте трохи відвернемося і звернемо увагу на успішні IT - продукти. Їх все об'єднують загальні якості : 1 . Культура обміну інформацією , навчання та умовна заменимость .Учасники проекту активно обмінюються інформацією , навчають один одного , навчаються самі. Ваш керівник відкрито і з задоволенням розповідає про результати останніх зустрічей. Розробники постійно цікавляться справами один одного і можуть в будь-який момент підмінити що не вийшов на роботу співробітника . А « он той хлопець з продуктового відділу » навіть розуміє , що таке « рефакторинг/поліморфізм/успадкування » , хоча він не програміст і знати цього не зобов'язаний. 2 . Системний підхід .Практично всі процеси девелопмента мають циклічний характер і підкоряються встановленим правилам , будь то стандарти кодування , тестування , рефакторинг , кодревью , методологія розробки або документування . Навіть навчання учасників проекту поставлено « на потік ». 3 . Високий рівень особистої відповідальності .Співробітники особисто мотивовані і налаштовані на професійне зростання , в команді є учасники , які беруть на себе відповідальність за прийняття рішень . У старих безнадійних проектах , незважаючи на їх солідний вік , відразу можна знайти з десяток « незамінних співробітників » , без яких немислимо супровід деяких частин проекту. Бо ніхто не знає , як воно працює. А про системність підходів яскраво говорить випадковим чином пов'язаний макаронний код проекту і відсутність яких би то не було стандартів . Дуже часто в таких компаніях процвітає « корпоративний пінг - понг » - щоб вирішити будь-яку проблему , потрібно обійти п'ять кабінетів і витратити півдня часу. Без чого ви точно не обійдетеся Щоб докорінно змінити ситуацію , вам в основному знадобляться дві речі : політична воля і «нова кров ». Політична воля.Намагатися змінити ситуацію докорінно, не маючи при цьому підтримки керівництва , - затія безглузда . Але , незважаючи на всю очевидність цього факту , багато розробників вважають , що вони в змозі вплинути на систему « власним прикладом ». Їхній план простий і невигадливий: 1 . Красиво і ідейно писати код .
2 . Це побачать всі інші, оцінять і зрозуміють , як це круто і зручно ,
3 . і почнуть самі писати так само. Мрія прекрасна , і настільки ж нездійсненна . Насправді ж автори макаронного коду продовжать ліпити свій пекельний продукт , а « Фантазери - трудяжкам » віддадуть найважчі і запущені закутки авгієвих стаєнь проекту. Чому без політичної волі керівництва неможливо зрушити з місця цей камінь ? Тому що зміни повинні відбутися не тільки в коді проекту , а в самому підході до формування процесів розробки ПЗ. Зміни мають бути проведені системно і повсюдно . Одному розробнику , - навіть групі - це завдання не під силу , в даний процес мають бути залучені всі учасники . «Нова кров ».Якби старі розробники системи могли зробити щось «краще» , вони б це робили . Тому без залучення до проекту нових людей з відмінними знаннями сучасних технологій , підходів і високим рівнем мотивації вам не обійтися . Що ж вас чекає? Якщо ви « старий » розробник на проекті, і вас попросили залишитися при оновленні - доведеться вчитися. І це хороша новина , бо з новими вміннями ви збільшите свою цінність на ринку праці. Починайте прямо зараз! Якщо ви займаєте керівну посаду і зважилися на зміни, вивчіть особливості функціонування IT. Розробка - фундамент вашого бізнесу , і ви повинні розбиратися в його основах. Якщо ви - той самий представник «нової крові » , вас чекає багато цікавих задач і високооплачуваний пекельна праця .

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

Опубліковано: 17/11/14 @ 07:56
Розділ Різне

SEO Блог

Як реанімувати старий безнадійний проект. Частина 1 : Рефакторинг vs переписування з нуля

Рекомендуємо: