Pull to refresh

Comments 8

Извините, вспомнилось:
картинка
image


Статья очень понравилась, давно пришёл к выводу, что нельзя никому отдавать решение о технических вещах на откуп, это наша, технарей, зона ответственности и отстаивать его, решения, необходимость — тоже вечная часть нашей работы
Есть то же самое на английском? Я бы много с кем хотел поделиться этой статьей.
Говоря о техническом долге необходимо различать личное желание разработчика улучшить некоторые места в коде и реальную необходимость оптимизации или рефакторинга, чтобы избежать дальнейших проблем при расширении и изменении функциональности сервиса.
Первое может и подождать неопределенно долго, а вот второе нужно реально делать и грамотный бизнес зачастую на это соглашается добровольно, понимая, чем это может грозить в будущем
Даже при идеальном отношении разработчиков к коду — техдолг будет копиться если систематически не выделять достаточно времени на разработку.

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

При этом девелоперы были достаточно качественные и алгоритмы были хорошие, а также clean code применялся. Но времени на обобщение не было.
А что делать, когда уже третий шаг «Интегральный анализ вариантов решения» требует времени, сопоставимого со временем исправления проблемы?
Да и вся цепочка шагов явно дороже исправления?
Но что вынуждает программиста написать плохой код? Он сам решает это сделать. Вынуждает его внутреннее состояние: «Раз вы мне не даете времени написать хорошо, то я напишу прямо г… о!» Но когда времени мало, можно написать чуть хуже, но, тем не менее, хороший и качественный код.


Знаю людей с обратной проблемой, например, я.
Писать хороший код, срывать все сроки из-за этого, хотя бизнесу нужна именно скорость в той задаче.
Статья супер, особенно понравилось про способы продажи техдолга.

Пара мелких IMHO

1) В той части где про недоверие PO. По идее, это говорит что PO не являются частью команды/оторваны от неё, что не хорошо. Если все сделано правильно, по PO должен быть первый пропонент по борьбе с тех долгом, это ему же тех долг первому и мешает «максимизировать и оптимизировать поток ценности».

2) Насчет «пишут говно на зло» — если честно за все годы практики такого не видел. Зато видел очень много, причем это совершенно интернациональное явление — в результате абсолютного «пох», «и так сойдет».
Как человек потративший немало времени на борьбу с тех долгом могу сказать что отсутствие выделенного времени это оправдание для тех кто не хочет устранять тех долг.
Всегда можно его устранять во время работы над бизнес задачей.

Но в реальности очень много программистов вышколены, чтобы побыстрее закрыть задачу бизнесу (хотя я ни разу не видел, чтобы за это существенно хвалили) поэтому выделенное время на тех долг + влияние этих задач на их премию помогает мотивировать разработчиков убирать тех долг.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.ontico.ru
Employees
11–30 employees
Registered

Habr blog