Перейти к основному контенту

Блог Дмитрия Колосова

Написал пост – улучшил блог

Когда делаешь свою тему для блога (или движок, что ещё хуже), нужно всегда помнить о балансе между улучшениями самой темы и написанием новых постов (эдакий improve-write balance). И, как в случае с work-life балансом, перекашивает постоянно и почему-то всегда в одну сторону.

 

В последнее время я занимался темой, почти забив на посты. Сделал все фичи для версии 1.1, расписал всё под 1.2, где будет тёмная тема и прочее. В какой-то момент притормозил и поставил себе планку, которую худо-бедно получается поддерживать – публиковать хотя бы одну запись в неделю.
 

Контент – главное в блоге, но без улучшений темы тоже никуда, особенно когда начинаешь с нуля. Конечно, всегда можно воспользоваться готовым решением и забить на всё это (привет, Эгея), но это не мой путь. Я всё же немного контрол-фрик (или не немного ¯\_(ツ)_/¯).

Если с большими фичами вроде той же тёмной темы требуется действительно выделять особое время для разработки, то в случае мелких фич может быть оправдан подход: пишем пост – внедряем улучшение.

Например, в посте про тачбар мне понадобились нормальные подписи к изображениям. В Hugo есть поддержка по умолчанию, но со стандартными стилями для html-элементов. Для темы пришлось доработать.

Или вот с этим постом – явно никаких новых фичей для поста не нужно, так что можно взять общее улучшение, например, пометить черновики иконкой. Локальная работа с контентом станет чуть лучше.

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

Подход в целом универсален и подходит для любого проекта, где можно чётко разделить процесс и улучшения процесса. Не ходя далеко, в процессе разработки это разработка непосредственно фич для бизнеса и технические задачи: рефакторинг, устранение техдолга, обновление зависимостей и т.д. Перегнёшь приоритеты в любую сторону и потом не оберёшься проблем. Причём, в обоих случаях будет журить за низкую скорость разработки :)