Классный разработчик не должен писать код, за него пишут другие…

классный разработчик

Вы не ослышались – я действительно считаю, что классный разработчик не должен писать код. Ведь на то он и классный разработчик, что понимает прописные истины:

  • чем больше кода, тем тяжелее его поддерживать;
  • чем больше кода, тем вероятнее в нем допущена ошибка;
  • чем больше делается однотипного кода, тем больше вероятность использования техники copy-paste, что стремительно отражается на качестве кода;
  • все задачи не такие уж уникальные, что их никто не реализовал хотя бы частично до текущего момента;
  • в разработчике ценится его интеллект, а не скорость набора кода;
  • и т.д.

Как же организовывает свою работу классный разработчик, чтобы писать этого самого кода как можно меньше? Для этого он применяет несколько весьма простых приемов.

1. Использует сторонние библиотеки. Для этого классный разработчик много читает и общается с другими разработчиками, чтобы знать чем богат мир open source решений. Когда он сталкивается с новой задачей, то прежде всего анализирует, не получится ли взять сразу готовое решение из существующих. Он не стесняется спросить совета своих коллег, чтобы воспользоваться еще большим объемом опыта и знаний, а также поискать немного в интернете, заодно освежив свои знания. Если найти не удалось, то классный разработчик думает над декомпозицией задачи на части и повторяет описанный план с самого начала. Java разработчик должен как минимум владеть знаниями по продуктам от Apache Foundation и Google Guava Libraries, что уже позволит писать на порядок меньше кода.

2. Отлично знает свою IDE. Современные IDE прилагают максимум усилий, чтобы код генерировался практически автоматически по нажатиям “горячих клавиш”. В Intellij IDEA есть много интеллектуальных генераций кода. Я бы настоятельно рекомендовал перечитать вот эти два блока документации, что может существенно уменьшить объем написанного руками кода: Auto-Completing Code и Generating Code. Практически все стандартные конструкции языка можно сгенерировать одним нажатием. Отдельное слово можно замолвить за автоматические рефакторинги. При рефакторинге риск ошибки особенно велик. Поэтому старайтесь как можно больше доверять в этом вопросе IDE.

3. Повторно использует однажды написанный код. Это правило действует сразу в двух направлениях. Прежде чем писать свой код, классный разработчик поищет подобное решение в своем проекте. Если он его найдет, то вероятнее всего сделает удобным для повторного использования с помощью рефакторинга, а после этого использует в новом месте. Это гораздо надежнее, потому что старые тесты гарантируют работоспособность кода, а шанс допустить ошибку становится гораздо ниже. Но не весь код стоит использовать повторно. Часто есть стандартные приемы или конструкции, которые используются повсеместно, но не могут быть легко абстрагированы от деталей. В этом случае на помощь классному разработчику приходят “живые шаблоны” – он просто создает шаблоны подобных конструкций на будущее и следующий раз создает их нажатием пары клавиш. Это сильно снижает риск ошибки и ускоряет появление рабочего кода.

После определенного времени работы на проекте, классный разработчик уже имеет наработанную базу кода и шаблонов, которые позволяют ему практически ничего не писать с нуля. А это делает его на порядок эффективнее других разработчиков. Наблюдая как работают другие, я могу вам с уверенностью сказать, что классный разработчик может работать в 2-10 раз быстрее среднестатистического. Надеюсь, вы к этому тоже стремитесь! 😉 Ваш КЭП.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Обсуждение (2)

Совершенно неправильный вывод. Хорошие разработчики, когда не находят решения проблемы, то пишут все таки свое. И, если оно получается достаточно полезным для широкого круга людей, публикуют в открытый доступ. А дальше библиотека начинает развиваться, если есть куда и нашлись энтузиасты, которые готовы ее поддерживать.

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

А в зависимостях нет никакого зла. Если ваш код модульный и вы можете переиспользовать модули – это замечательно. Чтобы не было циклов и сильносвязянных модулей используйте статический анализ кода. И будет вам счастье! 🙂

Если хорошие разработчики используют библиотеки, значит плохие их пишут? 🙂 Если вы уже решили мерить написанными строчками кода, то например я в некоторых исследованиях по их подсчёту заметил, что учитывают так же и строчки используемых библиотек. И это верно, потому что если ты решил использовать в проекте библиотеку – значит ты несёшь за неё ответственность в равной степени как и за написанный тобою код и тоже самое с переиспользованием кода внутри проекта. Это поражает зависимости, иногда это не гут.

Leave a Reply

Your email address will not be published. Required fields are marked *