Я знаю, что сейчас проповедую хору, но хорошего программиста от плохого отличает эффективность. И первое, что приходит на ум, когда мы слышим слово «эффективность», — это время, потраченное на реализацию той или иной фичи. Например, когда один разработчик делает что-то за три дня, а другой — за шесть, то небольшое количество арифметических вычислений показывает, что первый разработчик в два раза эффективнее второго, не так ли?
Нет! Этот критерий будет правильным только в краткосрочной перспективе и совершенно неверным в долгосрочном развитии.
Правильный способ проверить производительность разработчика — посмотреть, как он справляется с несколькими типичными (повторяющимися) задачами. Каждое следующее задание того же типа должно занимать все меньше и меньше времени. Вы можете попробовать вывести некую формулу сокращения времени выполнения очередной задачи и использовать ее для оценки и сравнения эффективности разработчиков в вашей команде. Так называемый коэффициент эффективности разработчика. Ну, например, каждое следующее задание одного типа должно занимать в два раза меньше времени, чем предыдущее. До определенного момента, конечно.
Стать более эффективным
Можно было бы много говорить о том, как добиться повышения эффективности и ускорить процесс разработки. На этот раз мы предложим вам пару аналогий для размышления.
Помните поговорку о заточке топора и вырубке леса? Ту, где абстрактному разработчику некогда точить топор, потому что он слишком занят рубкой дров.
Проблема очевидна, но решение не всегда так просто. Здесь есть обратная сторона — преждевременная заточка топора. Топор нужно затачивать тогда, когда ясно, что затраты на заточку топора окупятся скоростью вырубки леса.
И чтобы проверить это, вам нужно:
- Узнайте скорость вырубки леса тупым топором. Для этого нужно выполнить задание хотя бы один раз перед любыми оптимизациями. До тех пор нет необходимости реализовывать отдельную библиотеку и вводить дополнительные абстракции.
- Разберитесь в характеристиках топора, узнайте, что будет после заточки. Изначально написанное встроенное решение, построенное в рамках текущей архитектуры, полностью даст понять, что и где можно потом заменить и провести рефакторинг.
- Знай, когда в следующий раз тебе нужно будет точить топор. Невозможно сразу полностью отшлифовать весь код, но в этом и нет необходимости. Гораздо лучше каждый раз при рефакторинге заботиться только о конкретной задаче. Ваша цель — сократить время разработки именно этой задачи в следующий раз, скажем, в два раза.
Есть еще одна похожая популярная идиома. В нем говорится что-то вроде: «Лучше целый день строить самолет, чтобы долететь до места назначения за пять минут, чем целый день пытаться туда бежать». Но идиомы «топор» и «самолет» описывают разные случаи. Идиома «топор» рассказывает о разных задачах одного типа, а идиома «самолет» — о рутинных процессах внутри одной задачи.
Первоначально опубликовано в Riter Agile Blog.
Что читать дальше:
