Впоратися з нескінченним нескінченним проектом

У нас є великий (1200+ годин) веб-сайт, який має велику технічну заборгованість. В основному це викликано такими (звичайними) причинами.

1. Кілька програмістів, які приходять та йдуть під час розробки.
2. Зміна технічних характеристик під час розробки.
3. Додано численні додаткові функціональні можливості (за короткий час).

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

Через технічну заборгованість ми витрачаємо МНОГО годин на виправлення чи дослідження проблем, які зазвичай знаходять своє походження в одному з наступних:

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

У нас виникають проблеми щодня, і ми намагалися виконувати наступні дії, щоб припинити це:

1. Створена технічна документація щодо імпорту, оплати та загальної роботи веб-сайту.
2. Проведіть зустріч на початку тижня - обговоріть поточні проблеми чи вдосконалення та як їх вирішувати.
3. Майте план-тест. Програміст A тест B, B тести C і C тести А. Тоді наш керівник проекту введе кілька тестів. Що стосується впливу функції, ми кидаємо її на постановочне середовище і даємо клієнту можливість перевірити себе.

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

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

Що ми можемо зробити, або що ви робите, щоб уникнути цих проблем на великих проектах?

Незначне редагування, додаткова інформація:

1. Ми використовуємо контроль версій (SVN).
2. У нас є процес розробки DTAP.

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

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

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

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

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

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

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

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

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

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

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

Деякі перевірки коду добре, але, можливо, це є частиною схеми тестування A-> B-> C-> A. (Можливо, перегляд коду в іншому напрямку?)

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

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

1) Вони, як правило, не порушують офісну політику та співвідношення сил. 2) Вони успішно створюють ілюзію контролю з боку керівництва, а не завдають удару по суті проблеми.

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

Жодна з цих речей насправді не лежить в основі проблем, і вони можуть просто знизити продуктивність, але, безумовно, підтверджують ілюзію контролю з боку керівництва.

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

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

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

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

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

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

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

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

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

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

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

Ура. Яс.

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

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

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

Дизайнерські тести, які перевіряють поведінку і не узгоджуються з вашою архітектурою. Це не дуже модно, але я б сказав, не починайте тестувати, поки не з’ясується справжня мета вашого коду. Зокрема, не починайте тестувати, поки не дізнаєтесь, що насправді хочете протестувати; ІМО погано продуманий тест гірший, ніж тест. І чим більше тестів, тим складніше змінити внутрішній код. Ставтесь до свого тестового коду як до виробничого коду; це потрібно спланувати і добре написати.

Проводьте регулярні / щоденні огляди коду: це більше про перевірку розумності, щоб переконатися, що розробник не зайшов далеко. Використовуйте ці сеанси для планування роботи на наступні дні. Можуть бути дні, коли це займе 5 хвилин або 1 годину; справа в тому, щоб тримати діалог відкритим і давати розробникам можливість обговорити свою роботу з іншими розробниками та звернутися за порадою. Зробіть кілька сеансів парування на важких частинах коду чи прототипуйте ідеї, але нехай у людей є власний час для роботи.

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

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

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

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

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

Взагалі використовуйте тестування для підвищення довіри до товару, а не як інструмент, який миттєво підвищить якість. Будьте спокійні, але наполегливі :). Можливо, спробуйте стати спритною, але тільки якщо ви абсолютно позитивно можете залучити сертифікованого прем'єр-міністра. Представляючи Agile людиною, яка не знає Agile, швидше за все, це вб'є проект.