Мой код никого не интересует. Я был повержен в шок, когда осознал это в процессе работы программистом. Я тратил много времени на оттачивание своего кода, пока не понял, что он никого не интересует, ведь в зачет идет не сам код, а продукт. Принятие программистом этого факта приведет к повышению продуктивности и ценности его работы.
Код — это инструмент
Написание кода не является работой программиста. А является ей создание приложения для решения определенных задач. Да, код — это основной инструмент, который для этого используется, но все равно это всего лишь инструмент. Так же как работа столяра не заключается в использовании молотка или пилы — она заключается в производстве чего-либо при помощи этих инструментов.
Однако, некоторые действия могут привести к ошибочному мнению, что именно код является продуктом. Например, рефакторинг: что мы улучшаем с его помощью: код или продукт? Если ответ код — ни один менеджер не даст времени на это занятие. Но стоит объяснить, что это может исправить существующие ошибки или поможет внедрить новую возможность, и, внезапно, время на это найдется.
Приложение, прежде всего, оценивается целиком. Об этом следует помнить при написании каждой строки кода. Если продукт непривлекателен, смысла обсуждать что-либо дальше просто нет. Даже если все инструменты отлично использованы, работа провалена, если продукт получился плох.
Это не означает, что код не является чем-то ценным и не должен проверяться в контексте требований к продукту. Обеспечение безопасности и отказоустойчивости требует мастерства и использования правильных библиотек. Вот где код должен делать свою работу, остальное не должно выделяться. Чем быстрее рецензент пройдет такой код — тем более он будет удовлетворен.
Идея «Код — это инструмент» является причиной важности знаний нескольких языков и фреймворков; причиной пользы знаний математики и теории сложности, однако отсутствия необходимости в таких знаниях; причиной, по которой среда разработки может оказаться как замечательной находкой, так и самой страшной ловушкой. Все это является мерилом гибкости для программиста, которая напрямую зависит от разнообразия его инструментария.
Упор на характеристики
Возьмем, к примеру, встречу с ПМом или заказчиком. Что ты ему расскажешь? Сколько строк кода написано, сколько классов создано, как работают скрипты, обрабатываются исключения и как устроена база?
К сожалению, часто ответ на все эти вопросы «Да, именно это я ему и расскажу». А его лицо в это время ты видал? Ему скучно. Ему бы поскорей перейти к следующим пунктам. Эти детали не имеют для него ни малейшей ценности. Не то, чтобы он не понимал, о чем речь, его просто это не волнует.
Представь, что дизайнер начнет рассказывать тебе об использованных им слоях в Фотошопе, о том, как много у него там объектов, какие градиенты использованы на каких кистях и какие крутые анимационные скрипты он написал. Тебя это не интересует. Тебя интересует, можно ли уже забирать картинки.
Общаться надо на уровне состояний готовности: импортирование готово, но не хватает поддержки того и этого; приложение работает на большинстве телефонов, но на вот этом все еще подтормаживает; клиентское приложение уже работает, но функционал пока убогий. Вот что важно для менеджера или заказчика. Вот что несет для него информацию, полезную в контексте планирования дальнейших действий.
Твоя библиотека ничего не стоит
Я часто встречаю вопросы в интернете, связанные с защитой исходного кода. Программист пишет код для заказчика и использует для этого свою личную библиотеку. И вот, клиент требует исходный код всего проекта, и программист задумывается: не хочется отдавать ценный код своей библиотеки.
Сперва подумаем, зачем вообще клиенту может понадобиться исходный код. Возможно, для уверенности в возможности продолжения разработки, даже если программист внезапно исчезнет. Возможно, для проведения аудита безопасности или соответствия лицензий. Сам по себе код ему не нужен, он опять-таки просто играет роль инструмента для выполнения какой-то другой задачи.
И хотя личная библиотека может быть стоящей вещью, она не является ценностью сама по себе. Важной она будет лишь для тебя, так как она позволяет тебе работать быстрее. Собственно она может быть самой важной частью твоего бизнеса, но другой программист может отбросить ее как ненужную.
Но что, если библиотека действительно ценная? Если действительно есть уверенность, что она сама может быть продуктом. Тогда можно поделиться ей, или же даже продать, может, что и выйдет. Стоит только учитывать, что очень немногие такие продукты достигли хоть какой-нибудь успешности.
Такое упражнение вообще полезно для любого программиста. Оно приводит к осознанию того, как мало других программистов интересует твоя работа. Да взять хоть даже твой собственный проект. Чем ты руководствуешься при выборе сторонней библиотеки: тем, какой в ней классный код, или тем, какие крутые вещи она умеет делать? Ты хоть заглядываешь в ее код после установки?
Да, но...
Это что, значит, можно писать отстойный код? Нет, не значит. Для создания качественного продукта необходимо мастерство. Несмотря на то, что код никого не интересует, он все же основной инструмент для достижения цели. И хоть перфекционизм может быть проклятьем, но если неэффективно этот инструмент использовать, то задачу мы не выполним.
Возвращаясь к аналогии с плотником, грязный молоток забьет гвоздь не хуже начищенного до блеска, а вот ржавый может запросто сломаться при ударе и даже поранить.
Целью программиста является улучшение продукта, а не кода. Для максимальной эффективности нужно отталкиваться от того, что должен делать продукт и понимать, в чем заключается истинная ценность результата.
Автор: Dreyk
