Як я можу переконати керівництво боротися з технічною заборгованістю?


158

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

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


5
"робота з розробниками" "повідомляти це керівництву" Про що ви питаєте? Розробники чи менеджери? Кого поведінку ви хочете змінити?
S.Lott

45
Технічний борг схожий на фінансовий борг - набагато простіше з часом просто не накопичити його для початку. Оплачуйте всі свої технічні рахунки раз на тиждень.
Лоуренс Дол

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

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

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

Відповіді:


191

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

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

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


30
мій досвід, як правило, відповідає цьому. Технічна заборгованість очищається, коли нові функції додаються. Іноді оцінки певних «пов’язаних» виправлень / функцій підкладаються, щоб включати очищення цих речей.
Кен Хендерсон

4
+1 Ви точно поділяєте мої настрої ... окрім того, що ви висловились набагато дипломатичніше;)
Майкл Браун

7
Хороша відповідь. Я ще не бачу бізнесу, який із задоволенням підпише проект «рефакторинг», який не принесе користі для замовника, лише акуратніший код. Refactor як ви йдете.
JBRWilkinson

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

8
@ jmort253: є одна (незначна) проблема з цією інакше чудовою політикою -> неможливо проведення широких змін (тобто зміни бази даних, як сказано в ОП). Вони повинні бути чітко вирішені.
Матьє М.

48

Це так, як Ганді сказав, коли його запитали, чи буде його тактика працювати з кимось, як Гітлер. Він сказав: "Було б важко". Але я думаю, що є справедливий аргумент, що відповідь насправді - «ні». На жаль, я не думаю, що ви намагаєтесь зробити. Справа не в тому, що я намагаюся бути песимістичним, а радше намагаюся бути чесним.

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

Я думаю, що мені подобається те, що сказав Ренесіс у своїй відповіді, тому що це один з небагатьох, хто розуміє, що управління мислить зовсім інакше, ніж інженерія. І я думаю, що ми всі бачили, як компанії стають орієнтованими на дату та більш керованими проектами, а не орієнтованими на клієнтів та якість. Маючи на увазі, я маю на увазі типові компанії, а не справді ті, у кого є кишки сказати "Це буде зроблено, коли це буде зроблено" (наприклад, Apple Computer або id Software - і так, я розумію, що іноді люди не на волі застосовувати такий підхід).

Але ось у чому річ: компанії, які застосовують якісний підхід ... що ви помічаєте про них? Правильно, ними керують інженери, а не продавці, маркетологи, керівники проектів чи бухгалтери. Подумайте про HP, Apple, id, Google, Microsoft та IBM. Все розпочато і стало успішним з боку інженерів, а не продавців, хоча продавці, безумовно, зіграли свою роль, і я впевнений, що багато хто буде дискутувати про те, що Microsoft пов'язаний з якістю :) І з тих, хто пішов у гору, відійшло від керівництва інженерними технологіями. У цьому твердженні є ціла низка аргументів, оскільки існує маса технічних компаній, які врешті-решт зазнали невдач через неможливість пристосуватися до змін часу та керувати власним зростанням. Я не вважаю, що інженерне керівництво є причиною цих невдач, для мене, що " s питання навичок та ділової хватки, які не залежать від того, хто є розробником чи бухгалтером. Я думаю, загалом кажучи, що інженерна діяльність приділяється суворій відповідальності та дисципліні, що приносить користь компаніям, де інженерія є складовою.

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

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


43

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

Дозвіл без оплати - це величезна вартість, яку неможливо побачити або легко оцінити.

Перелічіть такі проблеми, як:

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

7
+1, хоча я думаю, що остання куля повинна бути "Хороші / найкращі члени команди від'їжджають"
Кен Хендерсон

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

3
@quant_dev, якщо ви бачите це як дихотомію між "швидшим" ​​та "ідеальним кодом", то, звичайно, ви так подумаєте. Немає причини, по якій ярлики не можуть бути технічно обгрунтованими, і в цьому випадку вони не вважаються технічною заборгованістю.
Ніколь

2
@Renesis "Немає причини, по якій ярлики не можуть бути технічно справними", - це просто не так.
Quant_dev

3
І іноді це взагалі не технічна заборгованість, це просто безлад: sites.google.com/site/unclebobconsultingllc/…
TrueWill

30

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

Один з способів я тримаю тиск на це кожен раз , коли мене запитують , для оцінки, і час можна було б врятувати , якби я не мав справу з конкретними питаннями технічного боргу, я включаю , що в моїй оцінці . Наприклад, " Ця помилка займе у мене 2-3 дні, щоб відстежити, але якби ми вже зверталися до цих двох інших помилок" низького пріоритету ", які були в черзі назавжди, це, ймовірно, займе менше одного. " Часто, відповідь буде йти вперед і виправляти ті інші, поки ти на це.

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

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

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


20

Ви можете спробувати аналогію кредитної картки. Запитайте їх: "Вам комфортно залишати виплати з вашої кредитної картки неоплаченими протягом тривалого періоду?"

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

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


12

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

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

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

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

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

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


5
+1 Але ці 9-5 розробників, ну, ви хочете, щоб обертаються двері для них, в ідеалі з якоюсь формою прискорювача.
Увімкнення

3
@Orbling: +1. Якщо вони не піклуються, вони дійсно повинні працювати десь в іншому місці. ВЕЛИКИЙ, маючи чортів, прийшов до вас із "Я щойно мав цю ідею ...".
quick_now

3
@Orbling У певних сферах розвитку вони можуть бути корисними. Я зовсім не шанувальник "снобізму розробників", але ви повинні знайти нішу кожного, щоб вони не мали користі. Найгірше, що ви можете зробити, це припустити, що всі схожі на вас.
biziclop

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

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

12

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

Або вони знижуються, швидко .

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

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


12

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

Я не бачу рефакторинг як завдання, яке є окремим від реалізації функцій. Це невід’ємна його частина.


5
Я не міг погодитись більше: "Технічний борг - це як фінансовий борг - набагато простіше в кінцевому рахунку просто не накопичити його для початку. Оплачуйте всі свої технічні рахунки раз на тиждень"
Лоуренс Дол

7

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

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

Так, деякі з номерів будуть вуду / дзеркала ... це нормально, брудна таємниця управління полягає в тому, що вони знають, що більшість номерів, про які вони співають, - це загальна кількість BS, доки ви їм щось дасте здавалося б, конкретно працювати, щоб вони могли отримати це в голові, у вас є шанс на боротьбу.


6

Після цього пояснення технічної заборгованості, ваше керівництво повинно переконатись, що він погасить:

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

Кухня - це ваш код, їжа - ваш продукт, а їжа - це продаж вашого продукту.

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


4

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

Давайте перефразовуємо це, щоб позиціонувати себе як замовника. Стара добра рольова гра.

Припустимо, ви купували холодильник. І ви можете придбати холодильник за 1000 доларів, який працював нормально від компанії Acme Corp., або холодильник за 2000 доларів від холодильників Acme Deluxe, які зовні виглядали однаково і мали однакові технічні характеристики, але мали менші витрати на обслуговування через більш чисту внутрішню архітектуру.

Як замовник, який би ви самі купили?

І що, на думку інженерів Acme Deluxe, є кращою відповіддю?


3
Мені важко визначити вашу позицію щодо цього. Я думаю, що ваша відповідь - це "залежить від того, що хоче клієнт". Проблема полягає в тому, що не кожен замовник розуміє, що холодильник з меншими витратами збирається просочитися розтопленим, неприємним рушником із секції морозильної камери, гучним шумом і, врешті-решт, перестане працювати через 5 років, а інший буде працювати спокійно і тихо протягом 20 років і не підлягати заміні, поки власники не визнають його стилем, що перепродає його в обмін на нову модель. Все ж мені подобається поставлене вами питання. Це думка провокує. +1
jmort253

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

3

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

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


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

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

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

2

Вам слід просто перестати скаржитися на це.

Ось чому:

  1. Вони ніколи не планують використовувати програмне забезпечення довше року
  2. це просто марна трата часу, коли її планують скинути
  3. Є деякі реальні проблеми, які потребують виправлення зараз
  4. програмістам просто потрібно навчитися поводитися з обслуговуванням, навіть якщо це не завжди весело
  5. Поскаржившись, що ви краще знаєте, що потрібно зробити, це зарозуміло - хтось інший приймає рішення, і ви повинні бути щасливі з цього приводу
  6. Вони все одно довіряють вам написати хороший код

Тож найкращий шлях вперед:

  1. Коли вони дадуть вам нове завдання, спробуйте виконати його якнайкраще в даний момент
  2. Напишіть це ідеально з першого разу. Якщо вам потрібно змінити це згодом, ви помилилися з першого разу, і будь-яка зміна завжди йде в неправильному напрямку - і це можливість навчання програмістів, коли ви робите помилки.
  3. Не вимагайте додаткового часу на це, ви не отримаєте його, є терміни, які ви знаєте.

3
Я в основному погоджуюся, за винятком того, що загальновідомо, що навіть хитре програмне забезпечення має тенденцію до виживання набагато довше, ніж очікують його творці. Але ти маєш рацію, краще не скаржитися. Натомість, якщо ви бачите деякий обмежений масштабний ре-факторінг, який допоможе зрозумілість коду, можливо, варто його продовжити та внести зміни БЕЗ ВИМОГИ під час технічного обслуговування / виправлення помилок (і несе ризик зробити це).
Анджело

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

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

1

Я вважаю, що ви ніколи не брали участь у проекті переписати / замінити або навіть оновити існуючу систему.

Це кілька найскладніших проектів, які успішно завершуються. Деякі проблеми, з якими ви зіткнетеся:

  1. Правила бізнесу втрачаються в часі.
  2. Документація та реалізація повністю не синхронізовані.
  3. Те, що ви бачите як помилку, користувачі бачать як особливість.
  4. І навпаки, багато "функції" користувачі розглядають як дефекти.
  5. Ви не отримаєте користувачів, які купуватимуть - вони розцінюватимуть ваше «виявлення фактів» як «дуренів, що задають дурні питання», вони вважатимуть зусилля тестування марною тратою часу, наполягатимуть на додаванні нових функцій, таким чином подовження проекту буде вже поза графіком.
  6. Швидше за все, вихідний код не відповідає 100% виконуваному виконуваному файлу.
  7. Поки ваш департамент возиться навколо рефакторингу розвитку, який бізнес насправді хоче, це не робиться.
  8. Цілком ймовірно, що ваш повторний факторинг буде включати "чистіші вдосконалені інтерфейси", таким чином перетягуючи інші проекти у вашу багну запізнення та неспроможні тести.
  9. Після того, як проект буде консервований (майже понад 50% цих зусиль повністю провалюються), ви втратили всю довіру - вам потрібно буде переїхати до іншої компанії в іншому місті, щоб знайти когось, готового слухати і вас.
  10. Якщо проект "вдасться", всі згадають, який це був кошмар - ви будете .......

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

У фразі "Якщо вона не зламана, є багато мудрості, не виправте".


1
"Я вважаю, що ви ніколи не брали участь у проекті переписати / замінити або навіть оновити існуючу систему" - Неправильно, 7 років.
Спустошена планета

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

1

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

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

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

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

Менеджмент стоїть за завданням, оскільки вони мають належну довіру до своїх розробників, що, я розумію, є рідкісною розкішшю.

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

Удачі!


1
як це відповідає на запитання: "Як ви повідомляєте це керівництву, щоб зацікавити їх у сортуванні технічної заборгованості?"
гнат

1
@gnat: Як більшість "відповідей" відповідають на це питання безпосередньо? Дивіться, наприклад, відповіді Джеймса Андерсона, tp1, або будь-які відповіді вгорі з найбільшою кількістю голосів. Але, щоб відповісти на ваше запитання, я запропонував альтернативну аналогію, яку може використовувати ОП. Мені здається, ви просто не згодні з моєю думкою з цього приводу. Це добре, але немає підстав для спростування.
Метт Кашатт

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

1
Тоді рекомендую прочитати його ще раз. Описуючи розмову з начальником, щодо методу покриття технічної заборгованості, закладаючи кошториси на майбутні роботи, не відповідає на запитання: "Як ви повідомляєте це керівництву, щоб зацікавити їх у сортуванні технічної заборгованості?" або. Тим не менш, я не відмовився від голосування, оскільки це додало до розмови. Отже, все, що вам вдалося зробити, - це глумлення думки з питання, з яким ви погоджуєтесь без істотних причин. "Програмісти" повинні бути місцем, де ми можемо вести бесіду. Не все є бінарним.
Метт Кашатт

1

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

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

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

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

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

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

Дорожні карти дійсно корисні, і, можливо, 13-е питання тесту Джоеля має бути "Чи є у вас дорожня карта?"

Ось відео першої години нещодавнього сеансу дорожньої карти Red Hat Linux .


1

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

Основні чинники досягнення угоди про досягнення:

  • Існуючий код був у вже не підтримуваному ланцюжку інструментів (MicroPower Pascal), який працював лише на майже непідтримуваній платформі розробки (PDP11-23).
  • Пошук розробників, які могли працювати над інструментами та цілями, ставав майже неможливим.
  • Цільова техніка більше не була доступною, якщо були потрібні запасні частини, а виробник все більше неохоче надавав послуги з ремонту.
  • Проблеми в коді були наслідком легко ідентифікованого незадоволення клієнтів та прямих витрат на обслуговування.
  • Додавання нових функцій або навіть виправлення помилок ставали майже неможливими через обмеження цільового обладнання, що призводило до необхідності переробляти інші області, щоб забезпечити простір під час вирішення проблем.
  • 8-годинний час створення та тестування будь-яких змін було дорогим.

У звіті детально викладені проблеми, кошторис поточних витрат та запропоновано 3 варіанти:

  1. Заморожте там, де ми були, можливо, навіть не виправлені помилки найближчим часом.
  2. Оптимізуйте код лише для простору, не зважаючи на ремонтопридатність, вказуючи, що той, хто намагається підтримувати оптимізований код, повинен бути розумнішим, ніж той, хто робив оптимізацію.
  3. Повторно впроваджуйте, визначаючи і ремонтопридатність як високі чинники, у галузевому стандарті, широко вивченому мові (ANSI C), на новому, низькій вартості, обладнання COTS (PC-104), з декількома постачальниками, доступними в будинку розроблена інтерфейсна карта, яка дозволить їй працювати з рештою існуючим обладнанням. Додавши обмежений набір нових функцій у складі розробки, таких як енергонезалежне сховище, сторожовий таймер для автоматичного перезапуску у несправному стані, деякі пристрої виходили з ладу кілька разів на день та вимагали скидання послуги за 40 фунтів для скидання , краща діагностика в процесі.

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

У випадках із менш екстремальним технічним боргом я схильний приймати те, що я називаю партизанським рефакторингом:

Якщо виникає проблема з конкретним модулем:

  1. Напишіть набір тестів, які демонструють проблему, яка також може вийти з ладу без рефакторингу
  2. Рефактор як частина розробки вказує на те, що тести все ще не вдається.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.