Що робити з чужими боргами?

Один з аспектів професії розробника - посвята профанів особливо процесу розробки ПЗ.

С. Макконнелл, Досконалий код

Мета цієї публікації - поділитися досвідом роботи над проектом зі складною історією і важкою спадщиною. Після відходу з чергового т. зв. «стартапу», я вирішив що хочу спробувати нових відчуттів: enterprise, legacy, etc. Для цього взявся за роботу над корпоративним додатком для транснаціонального концерну. Розробка на той момент йшла вже третій рік, додаток пережив кілька поколінь розробників, але стабільного релізу так і не було.

Вважаю публікація буде корисною:

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

Порушені в статті питання:

• Низька компетенція розробників, і що з цим можна вдіяти?
• Які аргументи переконливі в очах замовника для нефункціональних змін у проекті?
• Чому робота аналітиків і QA дуже важлива з точки зору розробки зокрема і для проекту в цілому?

Input

Що на вході? На співбесіді першого етапу я був заінтригований наступними подробицями:

• Використовувана версія фреймворку за роки розробки встигла застаріти
• Релізу стабільної версії продукту за два роки не відбулося
• Бізнес-складність системи часом зашкалює

На співбесіді другого етапу, за участю проектного менеджера і провідного розробника, я отримав наступну порцію нюансів:

• У поточної команди розробки низький рівень компетенції в використовуваних фреймворку, мові, тестуванні, IoC, об'єктно-орієнтованому дизайні, шаблонах проектування та архітектурі
• Предметна область дійсно непроста
• Замовник переконаний що проблем немає

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

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

• Низька компетенція розробників
• Низька якість коду (випливає з попереднього пункту), великий технічний борг
• Відсутність налагодженої інфраструктури
• Відсутність автоматизованого тестування
• Відсутність культури прийомного тестування
• Відсутність культури версіонування, внесення змін, деплоя
• Вимоги не стандартизовані
• Менеджерський борг перед замовником - приховування наявних на боці команди виконавця проблем, перебільшення успіхів, нові обіцянки до старих боргів

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

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

Починаємо з тестів

Одним з перших моїх заходів було підключення тестового фреймворку, допомога колегам у запуску та написанні тестів. Еволюція, звичайно більш гуманний варіант - не треба нікого «зливати», витрачати час і гроші на підбір більш досвідчених (і ймовірно - дорогих) фахівців. І кармічно це набагато корисніше - ділитися знанням. Але цей довгий шлях. Якщо розробник, досить зрілий, щоб вважати себе готовим до розробки корпоративних додатків за гроші, не освоїв тестування, щось в його кривий професійного зростання пішло не так. Драма в тому, що швидше за все, не витримавши нових вимог, багато хто воліє знайти нове місце роботи. Людині властиво йти шляхом найменшого опору. У цьому випадку спроба навчити - марна трата свого і чужого часу.

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

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

SVN -> Hg -> Git

Історично на проекті використовувався SVN. Мержі були справою складною і відповідальною, що супроводжувалася сакраментальною «не пуште поки в транк, сьогодні деплоїм». Колеги по департаменту в інших проектах використовували Mercurial. Близько місяця ми пробували цю систему контролю версій, але в підсумку віддали перевагу переходу на добре знайомий і популярний Git. Як і очікувалося, більшість претендентів, при формуванні нової команди, частіше виявлялися знайомі з Git, ніж з двома іншими СКВ. Чим не привід для переходу?

CI & CD

Windows Server -> Ubuntu

Remote Desktop + manual update -> delpoy.sh -> Unix + Docker + TeamCity

Копії програми для демонстрацій і тестування знаходилися на Windows Server. Керування сервером і оновлення програм здійснювалося вручну, шляхом з'єднання з віддаленою стільницею. Приблизно півроку мені знадобилося на переконання менеджера, і, через нього, замовника, що обов'язковою передумовою випуску в продакшн, має стати переведення інфраструктури на Unix. Паралельно з цим формальним обґрунтуванням, в процесі пошуку другого бекенд-розробника, я дивився в бік кандидатів, що володіють адмініструванням LAMP стека. На щастя, нам вдалося знайти фахівця з хорошими навичками в Bash і Unix: у підсумку він став у команді на 50% розробником і на 50% білд- та інтеграційним інженером. До виходу в продакшн у нас був повноцінний CI і CD. Привіт Rottenwood!

Цей захід, як інші, не суто технічне рішення. Методології та концепції розробки впливають на інші процеси, не забувайте про це. Якщо менеджер звик керувати командою, для якої підготовка релізу зводиться до «* * як- * * як і в продакшн!», недостатньо налаштувати агент у TeamCity. Вам доведеться донести до менеджера усвідомлення того, що «не можна просто взяти і» пофіксити «це за п'ять хвилин на проді до демо». Так, це буде на перших порах доставляти дискомфорт. Менеджеру знадобиться місяць або більше, щоб звикнути що деплою тепер відбувається не по стусану, миттєво, разом з падінням робочого продакшену. Тепер це усвідомлена процедура, яка нехай займає 10 хвилин, але гарантовано нічого не впустить, і дасть передбачуваний результат на будь-якому з серверів, скільки б їх у вас не було.

Для замовника аргументами необхідності виділення на це ресурсів і часу послужили:

• Зниження простою в екстрених випадках - завдяки Docker ми можемо оперативно розвернутися на будь-якій віртуальній машині в будь-якому датацентрі.
• Ми можемо поставити додаток разом з образом і він може бути запущений на будь-якій машині (такий кейс теж розглядався) без участі з боку команди розробки.
• Безпека - ізольованість контейнера з додатком від хост-машини, простота і надійність Unix для сервера. Частина пунктів при проходженні додатком корпоративного security-аудиту автоматично закривалася.
• Рідне середовище для використовуваного додатком стека, ширший набір застосовних технологій для потенційних фіч. Велика лояльність розробників.
• Відчутний приріст продуктивності без додаткової конфігурації.

Eclipse / NetBeans / Trial WebStorm / Brackets -> PhpStorm

Іншим важливим заходом стала організація придбання для команди ліцензії на PhpStorm і налаштування єдиного стилю форматування відповідно до PSR. Я вважаю будь-яка організація може (і повинна) забезпечити працівників нормальними знаряддями праці. PhpStorm і WebStorm зараз лідируючі, на мій погляд, IDE на ринку з підтримки PHP/JavaScript/TypeScript. Хороша IDE істотно здатна підвищити як особисту ефективність програміста, так і команди в цілому - легко впровадити за допомогою налаштувань єдиний code style і різні корисні «примочки» для роботи над проектом.

Devprom + Excel + *.jpg-> Jira

Цей перехід, мабуть виявився найбільш епічним і довгоочікуваним для нас. Історично, використовувався Devprom. Якщо у двох словах: нікому не рекомендую цю систему. Для мене було одкровенням, що платне ПЗ може бути настільки низької якості! Випадково система могла зависати, падати, містила відверті вразливості. Кожен апдейт, крім патчу декількох SQL-ін'єкцій (і додавання нових, судячи з частоти оновлень) привносив нововведення в розташування елементів GUI, так що звичні вже сценарії використання доводилося освоювати заново.

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

Завдяки Девпрому і винахідливості звичних до нього менеджерів, я спостерігав деякі альтернативні способи управління:

• Робота за картинками - після тестування на виході маємо папку зі скріншотами, названими відповідно до пріоритетів. Розробники весело хапають вподобані картинки і «фіксять» їх, перекладаючи картинки в папочку Done. За спробу створити на кожну картинку завдання в трекері можна було отримати по руках.
• Email-driven managment: в розсилці між членами команди протягом від декількох днів до тижня ходить лист в таблицею високорівневих «фічів». Ініціатива використовувати дошку трекера для оперативного управління розробкою - карається.
• Excel planning - складання беклогу і оцінка за допомогою легендарного табличного процесора.

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

PM-level

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

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

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

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

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

Dev-level

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

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

Після року рефакторингу, мені здається, що часом варто оцінювати розробників не за великою кількістю принесеної користі (функціональності + відповідної кодової бази), а за мінімумом залишається шкоди, у вигляді технічного боргу і непідтримуваного, або не тестованого коду. Звичайно у вашого менеджера буде альтернативний погляд на реальність. Але реальність розробки така, що «запиляти фічу» практично будь-якої складності для середнього розробника не складає труднощів. Набагато важливіше в середньо- і довгостроковій перспективі щоб це додавання не погіршувало архітектуру, супроводжувалося не крихкими і зрозумілими тестами, було спроектовано з оглядкою на принципи SOLID. У цьому відношенні, я віддам перевагу одне senior'a двом middle'ам і двох middle'ів чотирьом junior'ам. Чим довша дистанція, яку належить пройти вам і вашому продукту, тим важливіша дана теза.

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

Analytics

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

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

1. З імовірністю близькою до одиниці, завдання відніме у вас часу більше, ніж ви планували. Адже даючи оцінку, розробник завжди озвучує час на кодування. Найбільш досвідчені з нас можуть закласти ризики налагодження, тестування, супроводу документації і т. п. Але я сумніваюся що навіть кращі з розробників здатні точно прогнозувати час необхідний їм на роботу в якості бізнес-аналітика. Аналітик не буде за вас програмувати. А за перевищені терміни відповідати вам.
2. Ви будете відповідальні за всі ваші фантазії, оскільки потрапляючи в реалізацію, вони залишаються не описаними у вимогах і не узгодженими із замовником. Потім вам доведеться довго переконувати всіх, що це «не порожня фіча», і в кінцевому підсумку переписати цей код, з появою реальних вимог. Добре якщо ви ж. Набагато гірше натрапити на недокументовану поведінку і загадковий код з ініціалами, власника яких ніхто на проекті не пам'ятає.
3. Ви позбавляєте хорошого хлопця-аналітика можливості професійного зростання.
4. Ви збільшуєте ентропію Всесвіту, нівелюючи вигоду від поділу праці.

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

• Файл Visio з описом функціональності, блок-схемами залежностей між полями
• Файл Excel з правилами валідації та описом типів даних для кожного поля
• Файл PSD для верстальника, супутні вихідники (шрифти, іконки)

Такий пакет буде затребуваний не тільки на етапі розробки але і на наступних: прийомне тестування та розробка документації користувача.

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

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

Estimate it

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

Інша крайність: встановіть мінімальну оцінку. Я використовую 1, хоча багато оптимістів схильні давати обіцянки на кшталт «це можна зробити за 5/10/15 хвилин». Так, безумовно є правки, внесення яких займе лічені хвилини - не рахуючи накладні витрати на взаємодію з трекером, СКВ, документацій, тестами. Щоб не засмучувати менеджера тим, що «маленький» фікс займає цілу інженерну годину, можу порекомендувати пов'язані дрібні правки об'єднувати в одне завдання.

QA

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

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

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

Які ризики несе нерегулярне і погано організоване тестування:

• Якщо тестування проводиться рідко, буде здаватися що версія жахливо «забагана», кров-кишки-чума, а-а-а все пропало, все кидаємо, все біжимо на пожежу!! 1 - це зриває заплановану розробку, часом повністю паралізуючи її. Ризик зірвати наступний дедлайн.
• Одноразове виявлення великої кількості багів, суб'єктивно буде сприйматися, як те що їх критично багато в (здавалося б) готовій версії, що підриває ваш авторитет розробника.
• У випадку з ручним, епізодичним, слабо організованим тестуванням лід-репорти будуть низької якості - а значить важко-відтворювані, неактуальні, дубльовані. Розробники витрачатимуть додаткові зусилля і час на спроби їх відтворення. З мого досвіду можу сказати, що найчастіше відтворення бага займає часу не менше ніж виправлення. І подвійно прикро за витрачений час, якщо відтворити не вдалося.
• Час на виправлення великої кількості багів складніше оцінити, порівняно з регулярним щоденним включенням їх у план. Якщо процес налагоджений, то, маючи метрики продуктивності тестування і розробки, можна закладати оцінку виправлень у довгостроковий план, паралельно з рештою розробки.
• Шансів «пофіксити» всі стали відомими за день до релізу баги в термін буде дуже хотітися і менеджеру і молодим розробникам. Але ні, так не буває. Реліз буде або неналежної якості, або зірваний.
• Фахівці, які виконують тестування від випадку до випадку (приходять стажери, проектні менеджери, аналітики, самі розробники (впаси бог!), кава-леді, бухгалтера і сантехніки) за визначенням: а). низько-ефективні в цій ролі, оскільки вона для них епізодична б). навряд чи будуть діяти узгоджено за яким-небудь планом або сценаріями в). дадуть гарантовано неякісні звіти

Допомогти організувати здорове тестування - у власних інтересах розробника.

Найкраще - головний ворог хорошого!

Якщо вам пощастить і ви зневажите розробку до ідеального стану, це не означає що менеджмент і замовник автоматично стануть щасливі. По-перше, якщо PM, наприклад, хронічно прогинається під замовника, беручи без відома команди зобов'язання з розробки більше ніж фізично можна встигнути, то по мірі зростання стабільності і продуктивності розробки, будуть рости і зобов'язання. По-друге, завжди знайдуться не озвучені раніше проблеми, які за не маєтком інших отримають найвищий пріоритет. Тут схема така: якщо раніше команда «факапила» стабільність і нову функціональність, то тепер замовник може порахувати що додаток повільний і записати це як «епічний факап», хоча спочатку ніяких вимог щодо цього не існувало. Або згадати якусь Pet-feature, що ламає всю наявну логіку і виставити її як must-have, а будь-які контр-аргументи порахувати непрофесіоналізмом і саботажем. Тут вже все від адекватності замовника і вашого менеджерського прошарку залежить. У таких ситуація залишається тільки послідовно аргументувати, волати до логіки або шукати більш вдячну організацію.

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

- було: ніякого формалізму, * * як і в прод, пацани швидко робили все.

- стало: купа формалізму, CI/QA-якийсь заважає швидко «релізити», пацани повільно стали кодити...

При цьому, не маючи особистого досвіду роботи в проектах різних розмірів і командах, від нього вислизає, що між «було» і «стало» знаходяться:

1. великий часовий період
2. великий зріз функціональності реалізованої за цей час
3. не виплачені борги з того що «було»

Тому, для таких персонажів важливо не стільки саме наведення порядку - для не-розробника, будь-які зміни, крім функціональних, будуть ефемерними і необов'язковими. Важливо аргументоване обґрунтування з наочними прикладами: що, як і чому. Той самий аспект професії розробника, про якого згадує Макконнелл.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Ви шукаєте проекти з подібними challenges, щоб потім вирішити?

11.18% Так шукаю, це якраз моя позиція/роль у будь-якому проекті 55

51.22% Ні, але потрапляючи в хаос - борюся в міру сил 252

12.8% Ні, обходжу за версту, чужий бардак лагодити справу не вдячне. А если попадаю, то ищу скорее что-нибудь поприличней 63.

2.44% Я той самий замовник/менеджер, пиши код, * * * ть! 12

22.36% Я сам - Хаос, из Хаоса вышедший и Хаос пораждающий, вам Меня не победить 110

Проголосували 492 користувачі. Утрималися 194 користувачі.