Перевод статьи «TODO: Make These Useful».
fun getUser() {…} // TODO this could b better
return result; // TODO: See if we need this
fun calculateFaceCount() {…} // TODO save stuff
// TODO: proper sorting
Уфф! Что, черт побери, это означает?
Если вы уже некоторое время занимаетесь программированием, вам наверняка встречались эти метки: TODO. Это программистское сокращение фразы «это нужно сделать позже».
Но вы замечали, сколько вам попадалось совершенно бессмысленных TODO, понятных разве что тому, кто их написал? Комментарии, начинающиеся с TODO, имеют дурную привычку не иметь контекста, быть короткими, непонятными и, что хуже всего, — вечными.
Так зачем же мы продолжаем их писать? Потому что у нас, программистов, хорошие намерения сопровождаются недостатком времени. Я не выступаю в защиту «костылей», но разработчикам часто приходится жертвовать качеством кода, чтобы вовремя выпустить продукт*.
Прекратите писать TODO. Но если вы уверены, что без этих четырех букв в вашем коде не обойтись, мы вам расскажем, как сделать их максимально эффективными.
*Ну ладно, иногда люди бывают просто ленивыми, но я не буду исходить из этого предположения. Лучше я буду считать, что все стараются сделать, как лучше, а всякие внешние факторы заставляют идти на компромиссы. Советую почитать по этой теме книгу Сидни Деккера «The Field Guide to Understanding Human Error». Кроме того, в любой отрасли всегда были и будут злонамеренные лица, но я верю, что их все же меньшинство.
Тебе это не понадобится
Комментарий, начинающийся с TODO, довольно часто относится к какому-нибудь функционалу, который, по мнению разработчика, понадобится в будущем.
Скажем, вы собираете интерфейс для доступа к базе данных. Вам нужно написать функционал для вашей конкретной задачи. Но вы предполагаете, что в недалеком будущем вам понадобится заменить или обновить этот функционал. Поэтому вы начинаете писать эту функцию…
Стоп.
Не нужно создавать то, что вам не нужно прямо сейчас. Вы не знаете, понадобится ли оно вообще, но работа над этим потенциально ненужным функционалом затормозит вашу работу над текущей задачей и помешает сосредоточиться на главном.
«Тебе это не понадобится» (YAGNI) это один из принципов экстремального программирования. Руководствуйтесь им.
Весна покажет…
Если что-то действительно должно быть реализовано, этот пропущенный функционал сам вам на глаза попадет. При этом TODO — не слишком полезный маркер для обозначения работы, которой нет в вашем плане.
Скажем, разработчик Сэм пишет код, создающий новый объект для представления каждый раз, когда пользователь прокручивает ячейку списка*. Разработчик понимает, что это может повлечь за собой перерасход памяти и проблемы с производительностью. И он пишет запретное примечание:
TODO: Recycle view objects
У разраба Сэмми хорошие намерения, но он написал ужасный TODO. И вот почему.
Этот код работает с меньше чем 10 тыс. пунктами списка. Но даже если их будет больше, чтобы получить проблемы с производительностью, вам придется прокручивать до самого конца списка, причем на каком-нибудь старом устройстве. А кто в реальности будет скроллить до самого конца 10 тысяч результатов поиска?
Давайте опустим тот факт, что этот TODO не имеет никакого контекста и, следовательно, его не поймет никто, кроме автора. Остановимся на самом факте существования этого комментария. Вероятность того, что разработчику действительно нужно будет выполнить этот TODO, довольно мала.
Предположим, пользователям все-таки очень нужно прокручивать до конца список из 10 тысяч наименований. Вы об этом не узнаете, пока пользователь вам не напишет. А когда он напишет, эта задача будет должным образом внесена в бэклог и, соответственно, выполнена. То есть, если что-то по-настоящему нужно сделать, если это что-то на самом деле влияет на пользователя, вы об этом точно узнаете. А ваш TODO попросту бесполезен, его вообще не должно быть.
*Большинство современных фреймворков справляются с этой проблемой за вас, но давайте представим, что они этого не делают! В конце концов, еще совсем недавно это было реальной проблемой.
Делайте все правильно изначально
Самая большая проблема, связанная с TODO — их стремление пережить разработчиков, которые их написали. Мне встречались TODO — ровесники всей кодовой базы, в которой они пребывали. В общем, если вы не сделаете что-то правильно сразу, вы, вероятно, не будете это переделывать никогда. Командам сложно заниматься техническим долгом; то, что не задевает пользователя напрямую, редко получает высокий приоритет.
В то же время делать что-то правильно сразу не так плохо, как может показаться. Если вы действительно цените свое время, вы предпочтете с первого раза придерживаться верного пути.
Скажем, справиться с задачей на скорую руку займет у вас два часа. А пойти более длинным, но при этом более правильным путем займет три. Вы можете сэкономить один час сразу, но когда повторно вернетесь к этой задаче, вы потратите три часа, чтобы сделать все правильно. Итого, на выполнение задачи пойдет пять часов. А это, ясное дело, хуже, чем сразу потратить три.
Смысл в том, чтобы делать все правильно с первого раза. Это лучше как для вас лично, так и для вашей кодовой базы. Но черт бы побрал эти дедлайны!..
Записывайте всё и относитесь к делу со всей ответственностью
Ладно, предположим, вы действительно уверены, что у вас совершенно нет времени сделать дело правильно. Или у вас возникла идея, которую непременно нужно реализовать позже.
Тогда хотя бы сделайте свои TODO эффективными. Вам поможет привязка каждого TODO к соответствующему пункту в бэклоге. Мы в нашей компании для подробного описания юнитов работы пользуемся карточками. И когда пишем TODO, всегда помещаем в комментарий ссылку на карточку:
{…} // TODO: www.trello.com/123456
А в самой карточке или тикете даем как можно больше контекста относительно необходимых изменений. Приводим ссылку на текущую работу, которую выполняли, когда писали TODO. И пишем тикет, как для любой обычной работы, чтобы им мог заняться кто угодно из команды.
TODO-комментарии имеют тенденцию оставаться в коде навечно и никогда не получать высокий приоритет. Поэтому, если вы уверены, что какая-то работа непременно должна быть сделана, относитесь к ней соответственно. Донесите до нужных людей, что эта задача должна получить приоритет. Не допускайте, чтобы TODO, написанный год назад, так и не был обработан.
Для этого следует стандартизировать ваши приемы работы с TODO. У разработчиков не должно возникать проблем с их написанием, поиском в коде и внесением в план работ. Все ваши TODO должны быть хорошими. Обычно это означает включение их в вашу обычную работу и возврат к старым (плохим) TODO — чтобы подчистить их.
Обратите внимание: я не призываю вас игнорировать технический долг, срезать углы или прекратить обдумывать улучшение вашего кода. Очень часто в TODO делают заметки о каких-то хороших идеях. Беда в том, что если их не документировать правильным образом, эти хорошие идеи так никогда и не воплощаются.
Опасайтесь этих страшных четырех букв: они засоряют вашу кодовую базу.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]