В первый год своей работы разработчиком в компании я сильно переживал, что не могу состредоточиться и программировать целый день, 8 часов. Я от силы мог программировать часов 6, и кое-как писать что-то в оставшиеся часы. На следующий день я приходил и переделывал тот ужас, что написал вчера вечером. Я вечно отвлекался, открывал Хабр, ВК, что-то ещё и боялся, что разработчик из меня так себе.<\/p>\n
Но потом я понял, что в этом сила, а не слабость. Когда меня просили сделать что-то новое, что ни я, ни кто-то другой в компании не делал, я уже знал, куда смотреть, я уже читал статью на эту или смежную тему. Или после нескольких дней мучительного подхода к задаче, я прозревал, что проблема в том, что мне нужно сделать много рутинной работы и её можно автоматизировать, и сделать гораздо быстрее. Как и все последующие похожие задачи. Оказалось, что работа разработчика — это творческая работа, а не просто написание кода.<\/p>\n
В итоге я пришёл к чему-то такому: первые пару часов я читаю Хабр и узнаю что-то новое, часто пробую это прямо сейчас. Потом приступаю к задачам, анализирую их и выбираю те, которые могу и хочу сделать прямо сейчас, а в последние пару часов читаю переписку, отвечаю коллегам и общаюсь с ними вживую по их и моим проблемам и вопросам. И лишь в пятницу, раз в неделю, рассказываю, что получилось, что не получилось и куда я намереваюсь двигаться дальше. Таким образом, за несколько лет не возникло ни одного вопроса о моей результативности, а релизы выходили регулярно и с хорошим качеством, и мы не проседали, когда архитектура ещё не была готова к новой сложной задаче.<\/p>\n
Однако, если смотреть со стороны, кажется, что я почти не работал. Я много сидел и думал перед компьютером, перебирал библиотеки, которые можно использовать вместо того, чтобы написать свою реализацию, читал статьи и письма. Если бы контроль был ежедневным, то не был бы доволен никто — ни начальник, ни я.<\/p>\n
Более того, часто в начале недели было больше желания узнать новое и подумать над решением, а программировать ближе к концу. В таком ключе результат первых трёх дней был бы нулевым: ведь я ещё не написал ничего толкового!<\/p>\n
Так что рецепт простой:<\/p>\n
Часто я видел такую картину: приходит новая задача на разработку нескольких страниц, программист с желанием и усердием тратит неделю или даже месяц, и разрабатывает страницы как надо. Раздел попадает к неравнодушному тестировщику и тот возвращает работу с вопросом: а как выполнить такой-то сценарий. Это обсуждается с постановщиком задачи, с разработчиком и оказывается, что никак, а сценарий важный и нужно всё переделать. Или даже раздел презентуется заказчику, а тот: ой, мы забыли о нужном сценарии, похоже, что нужно всё переделать.<\/p>\n
Когда так происходит раз за разом, разработчику легко взбеситься. Он со знанием дела и с вниманием всё реализовал, а теперь это нужно выкинуть и начать по новой, обидно же! И разговоры начинают сводиться к тому, что необходимо хорошо продумать задачу с самого начала, поставить строгое техническое задание и всё такое. В итоге, этам постановки технического задания может затягиваться на месяцы, а в итоге всё одно — что-то забыли и нужно переделывать. И это нормально.<\/p>\n
К сожалению, когда мы разрабатываем не космический корабль с очень чёткими требованиями и многолетним сроком разработки, невозможно учесть всё на этапе проектирования. И заказчик, и менеджер, и аналитик могут пропустить важные сценарии использования. И никакого способа надёжно измерить, все ли сценарии учтены, нет.<\/p>\n
Кроме этого нужно действовать с другой стороны: разработчик и архитектор должны продумать, как сделать так, чтобы на подобную задачу и на её переделку тратилось мало времени. Как сделать, чтобы разработка велась не недели и месяцы, а дни и недели? Тогда первые версии будут представляться пробными, а к последующим разработчики не потеряют энтузиазма.<\/p>\n
Короче, разработать общие правила, шаблоны страниц, поведение отдельных блоков, разработку конфигурированием, а не программированием, не рисовать макет каждой страницы; ограничить по времени как этап проектирования, так и этап разработки.<\/p>\n", "date_published": "2020-02-23T18:29:26+03:00", "date_modified": "2020-02-23T18:29:22+03:00", "_date_published_rfc2822": "Sun, 23 Feb 2020 18:29:26 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "22", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } } ], "_e2_version": 3559, "_e2_ua_string": "E2 (v3559; Aegea)" }