2 заметки с тегом

программирование

Идеальный код

Лучшее описание, что я встретил в интернете:

Хороший код — это код, понятный младшему инженеру. Отличный код — код, понятный первокурснику computer science. Лучший код — его отсутствие.

Но, к сожалению, на работе я часто встречаю мнение: Я пишу слишком сложный код, потому, что я опытный и крутой инженер и мои коллеги его не понимают. Что делать?

Учиться писать простой код, что же еще!

 Нет комментариев   7 мес   ведущий инженер   Код   программирование

Как считать, хорошо ли работает разработчик?

В первый год своей работы разработчиком в компании я сильно переживал, что не могу состредоточиться и программировать целый день, 8 часов. Я от силы мог программировать часов 6, и кое-как писать что-то в оставшиеся часы. На следующий день я приходил и переделывал тот ужас, что написал вчера вечером. Я вечно отвлекался, открывал Хабр, ВК, что-то ещё и боялся, что разработчик из меня так себе.

Но потом я понял, что в этом сила, а не слабость. Когда меня просили сделать что-то новое, что ни я, ни кто-то другой в компании не делал, я уже знал, куда смотреть, я уже читал статью на эту или смежную тему. Или после нескольких дней мучительного подхода к задаче, я прозревал, что проблема в том, что мне нужно сделать много рутинной работы и её можно автоматизировать, и сделать гораздо быстрее. Как и все последующие похожие задачи. Оказалось, что работа разработчика — это творческая работа, а не просто написание кода.

В итоге я пришёл к чему-то такому: первые пару часов я читаю Хабр и узнаю что-то новое, часто пробую это прямо сейчас. Потом приступаю к задачам, анализирую их и выбираю те, которые могу и хочу сделать прямо сейчас, а в последние пару часов читаю переписку, отвечаю коллегам и общаюсь с ними вживую по их и моим проблемам и вопросам. И лишь в пятницу, раз в неделю, рассказываю, что получилось, что не получилось и куда я намереваюсь двигаться дальше. Таким образом, за несколько лет не возникло ни одного вопроса о моей результативности, а релизы выходили регулярно и с хорошим качеством, и мы не проседали, когда архитектура ещё не была готова к новой сложной задаче.

Однако, если смотреть со стороны, кажется, что я почти не работал. Я много сидел и думал перед компьютером, перебирал библиотеки, которые можно использовать вместо того, чтобы написать свою реализацию, читал статьи и письма. Если бы контроль был ежедневным, то не был бы доволен никто — ни начальник, ни я.

Более того, часто в начале недели было больше желания узнать новое и подумать над решением, а программировать ближе к концу. В таком ключе результат первых трёх дней был бы нулевым: ведь я ещё не написал ничего толкового!

Так что рецепт простой:

  • Спрашивать результат не чаще, чем в несколько дней;
  • Ставить чёткие дедлайны по группе задач;
  • Не контролировать число часов или строчек кода.