Ще один безнадійний проект

Ця стаття пов'язана загальною думкою з попередньою заміткою про документування .

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

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

SEO Блог

Ще один безнадійний проект

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