Радость программирования

Вчера я работал со слайдом для одной из моих будущих дискуссий о Java и объектно-ориентированном программировании и застрял в поиске убедительных аргументов в пользу прозрачности логики . Я собирался сказать, что для программистов важно уметь понимать, как все, что они делают, работает, даже если они этого не видят или никогда не хотят его видеть. Но потом я понял, что, возможно, не все так думают. Возможно, некоторые программисты предпочитают оставаться в неведении относительно большинства вещей, если код перед ними «просто работает». Отсюда и этот пост в блоге, чтобы спросить вас, на какой вы стороне.

Много лет назад я был на собеседовании в качестве кандидата. Они искали веб-архитектора, а я разговаривал с их техническим директором. Он попросил меня объяснить, что происходит за кулисами, когда мы вводим новый URL-адрес в веб-браузере и нажимаем «Enter». Я нарисовал небольшую диаграмму с регистратором домена, несколькими DNS-серверами, балансировщиком нагрузки, несколькими HTTP-серверами, несколькими базами данных и несколькими IP-реле в середине. Я думаю, что он был впечатлен ответом (хотя они тогда меня не нанимали) и сказал, что большинство веб-разработчиков не понимают большую часть этой картины. По его словам, они знали только, как работают HTTP-серверы, и мало заботились об остальных. Большинство из них даже не знали, что такое HTTP, пока код PHP делал то, для чего он предназначен.

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

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

• Энтузиазм Здесь я начну быстро, обычно с быстрого пейджера новой библиотеки, которую я собираюсь использовать. Я пролистываю документацию, игнорирую большинство из них, так как это не имеет никакого смысла, и быстро копирую и вставляю то, что они рекомендуют. Все кажется легким, и я ожидаю, что код заработает через несколько минут. И обычно это так.
• Угадывать Я начинаю вносить изменения в простой код, который я только что скопировал, и делаю некоторые предположения относительно логики, стоящей за ним. Я не знаю, как создаются продукты, которые я использую, но мне нужно на что-то положиться. Итак, я полагаюсь на то, что могу догадаться .
• Разочарование Очевидно, что большинство моих предположений неверны. Я начинаю гуглить и переполнять стеком. Ответы, которые я получаю (если я получу какие-либо), мало помогают, так как общая картина по-прежнему отсутствует, и лучшее, что я могу сделать, это исправить свой код, чтобы он работал, в соответствии с советами, которые я получаю из случайных источников , Но я продолжаю оставаться в темноте, и общая концепция дизайна до сих пор не ясна. И я все еще надеюсь решить все это без чтения полной рукописи Руководства для разработчиков.
• Депрессия Очень скоро я понимаю, что я просто обезьяна, пытающаяся запустить самолет. Может быть, он полетит, а может, мне даже удастся приземлиться. Но я все еще обезьяна, и это очень удручает. У меня нет радости в этом. Я ненавижу себя за глупость. Я ненавижу этих создателей библиотеки за то, что они не так очевидны в использовании. И я ненавижу свою работу.

Я считаю, что эти четыре этапа очень распространены для всех нас, разработчиков программного обеспечения. Однако то, что происходит потом, отличает хороших программистов от плохих. Если честно, я принадлежу к обеим категориям, в зависимости от ситуации. Что мне делать, когда я плохой программист? Я заставляю все это работать и называю это днем, все еще не зная, что происходит внутри, и почему именно это работает и не работает так, как я пытался раньше. Моя депрессия никуда не денется. Это только обостряется. Я все еще ненавижу себя, но мое программное обеспечение работает. Я перехожу к следующей проблеме, ожидая выходных.

Что мне делать, когда я хороший программист? Я углубляюсь в проблему, изучаю программное обеспечение, которое использую, загружаю его исходный код, читаю его документацию, пока не пойму, что происходит. Затем я возвращаюсь к своей части кода, исправляю ее с полным пониманием и называю это днем. Иногда я даже пишу об этом в блоге, например, для Nutch , про Liquibase или про CasperJS . Моя депрессия полностью уходит. Я больше не ненавижу себя, не ненавижу свою работу и не ненавижу разработчиков этих «глупых» библиотек. Я даже помогаю их проектам своими постами в блоге.

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

Некоторое время назад я сказал себе, что больше не буду этого делать. Я не хочу быть обезьяной, управляющей самолетом. Я хочу быть пилотом . Конечно, кривая обучения будет длиннее, но в результате… радость. Мне действительно нравится моя работа, когда я чётко и прозрачно вижу логику каждой строки кода, которую я пишу. Я точно знаю, почему я пишу им, что они делают, и что будет, если я их поменяю. Я не знаю всех деталей, конечно, я знаю, где нажать, чтобы найти эти детали. Вот что делает мою работу интересной для меня: прозрачность моей логики кодирования.

Мне действительно нравится отвечать за все, что делает мой код. Мне нравится чувствовать, что он делает именно то, что я хочу. Вы можете сказать, что я фанат контроля — может быть и так. Но именно здесь я получаю наибольшее удовольствие за последние 30 лет программирования: видеть, как компьютеры делают то, что я хочу. Если некоторые библиотеки попытаются отобрать это у меня и посадить на место пассажира, я сделаю все возможное, чтобы вернуться на место водителя. Я хочу знать, что происходит, и я хочу, чтобы это произошло согласно моей воле. Я хочу наслаждаться своей работой.

Теперь вернемся к моей конференции. Я собираюсь показать этот фрагмент кода на одном из моих слайдов (именно так предполагается использовать Spring Framework ):

Затем я задам вопрос: знаете ли вы, кто создает экземпляр класса HelloController и как этот экземпляр используется? Кто вызывает его методы, почему и когда? Кроме того, вы знаете, как изменить это поведение? Моя точка зрения на конференции будет состоять в том, что хорошая структура должна облегчить пользователям понимание ее внутренних особенностей . Потому что хорошие программисты хотят знать, что внутри. Плохие программисты, с другой стороны, в порядке, будучи летающими на самолете обезьянами.

А что насчет тебя?