Як мені можна платити за зменшення технічної заборгованості?

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

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

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

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

Мені просто страшно того моменту, коли ми вирішимо реалізувати нову функцію, яка вимагає багато змін у застарілому коді. Це просто може шокувати замовника: навіщо вам потрібно 8 годин для зміни цих піктограм? Замовника просто не хвилює, що в коді є 500 місць, які мені потрібно змінити. І я також повинен спочатку знайти усі ці 500 місць.

Будь-які ідеї?

Крок 1: Зупиніть роботу з неоплаченою понаднормовою роботою.

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

Крок 2: Робіть замітки

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

... код справді важко підтримувати.

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

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

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

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

Дозвольте це зробити для всіх оцінок, які ви даєте. Тоді, магічно, з часом технічна заборгованість зникне, і вам заплатять за це.

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

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

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

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

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

Вам потрібно показати керівництву, як рефакторинг та покращення продукту в іншому випадку принесуть користь компанії.

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

Отже ... ви повинні переконати керівництво, що запропоновані вами зміни допоможуть компанії:

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

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

Звичайно, йому довелося загорнути його в автомобільну метафору, щоб його аудиторія могла ставитись до цього.

"Одна штука за раз" - Джонні Кеш

Здається, ви можете стягнути плату за клієнта за час, який зміни "повинні" взяти, і все-таки вийти НАПЕРЕД у довгостроковій перспективі.

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

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

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

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

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

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

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

І не забувайте враховувати кращі інструменти. Resharper - чудовий інструмент рефакторингу, який підключається до Visual Studio.