Из "97-ми вещей, которые должен знать каждый программист".
"Что бы вы ни предпринимали, надо действовать с осторожностью и рассматривать последствия" Аноним
Не имеет значения, насколько удобным кажется вам график работы в начале очередного этапа выполнения проекта. Рано или поздно вы окажетесь "под давлением". Если вы обнаружили, что вам приходится выбирать между "делать все правильно" и "делать это быстро", вы часто обращаетесь к варианту "сделать это быстро", подразумевая, что вы вернетесь и исправите это чуть позже. Когда вы даёте это обещание самому себе, своей команде и вашему клиенту, вы действительно так считаете. Но слишком часто следующая итерация приносит новые проблемы, и вы фокусируетесь на них. Такое откладывание работы называется "технической задолженностью" (техническим долгом или техническим обязательством), и она не является вашим другом. В частности, Мартин Фаулер называет это преднамеренной технической задолженностью в его систематике технических долгов, которую не следует путать с непреднамеренной технической задолженностью.
Технические долги - это как кредит: вы получаете выгоду от них в краткосрочной перспективе, но вы должны уплатить проценты на них, пока они не будут полностью оплачены. "Кратчайшие пути" в коде делают сложнее добавление новых возможностей или его рефакторинг. Они являются рассадниками дефектов и неустойчивых тест-кейсов. Чем дольше вы их держите, тем хуже становится ситуация. К тому времени, когда вы наконец исправите начальную проблему, вы можете уже сделать целую кучу не-совсем-правильных дизайнерских решений, основанных на первоначальном исправлении, что делает ваш код сложнее исправления и дальнейшего рефакторинга. Со временем проблемы и неверные решения растут, как снежный ком, наслаиваясь одна на другую. В самом деле, часто случается так, что вы действительно возвращаетесь и исправляете код, только когда всё становится настолько плохо, что вам приходится его исправлять. К этому времени исправление может потребовать так много времени и оказаться столь рискованным, что вы зачастую не можете себе этого позволить.
Бывают моменты, когда вы должны влезать в технические долги ради сроков проекта или реализации части возможностей программы. Старайтесь не попадать в такие ситуации, но если положение дел абсолютно того требует - действуйте. Но (и это большое НО) вы должны следить за своими техническими долгами и оплатить их быстро, или ситуация начнёт быстро ухудшаться. Как только вы примете решение идти на компромисс, напишите новую задачу в свой TODO-список, чтобы не забыть.
Если вы планируете погашение долгов в следующей итерации, то расходы будут минимальными. Оставляя же неоплаченные долги на поздний срок, вы получите с них проценты, которые тоже надо будет оплатить. Отслеживание долгов подчеркивает влияние технических долгов проекта на стоимость бизнеса и позволяет расставить приоритеты их погашения. Выбор того, как всё рассчитать и отследить, будет зависеть от конкретного проекта, но учитывать это вы должны.
Платите по своим техническим долгам в кратчайшие сроки. Иное поведение трудно считать предусмотрительным.
А я часто записываю в ToDo напоминалку, когда код которым не доволен. Правда проверяю эти списки нечасто.
ОтветитьУдалитьСпасибо за перевод. Хотелось бы продолжения.
ОтветитьУдалитьСпасибо за отзыв.
ОтветитьУдалитьПопробую потихоньку переводить, но эти тексты достаточно сложно переводить, поэтому это займёт время.