5 вещей, которые я усвоил за 20 лет в программировании

Перевод статьи «5 Things I’ve Learned in 20 Years of Programming».

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

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

Но вместе с тем все это заставляет меня чувствовать себя динозавром индустрии.

Я думаю над словами Боба Мартина, которые он сказал в каком-то подкасте или где-то на выступлении.

Спрос на программистов в последние 4-5 десятилетий растет так сильно, что каждые пять лет количество программистов удваивается. В результате программист с пятью годами опыта уже проработал в этой сфере больше, чем половина всех остальных программистов.

Статус старика

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

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

В общем, я аксакал, окруженный начинающими программистами. Осознание этого заставило меня задуматься, не стоит ли как-то поделиться своим опытом, переведя его в короткие советы. Предположим, кому-нибудь это пригодится. Что бы я мог сказать этим ребятам?

В этой статье я изложил те вещи, которые считаю самыми важными уроками, усвоенными мной за 20 лет карьеры программиста.

1. Нет ничего хуже, чем дублирование знаний

«Избегайте копипаста в программировании!»

Если вас еще не били линейкой по рукам за копирование и вставку кода в вашем приложении (антипаттерн «скопируйте, вставьте и улучшите по вкусу»), считайте, что только что это произошло.

Прекратите. Немедленно. Это ужасная и небрежная практика.

Представьте, что у вас есть прекрасно работающий метод CalculateBill(). Но вот приходит менеджер продукта и говорит, что для новых клиентов в Мексике нужно подсчитывать немного иначе. Вы копируете имеющийся метод, вставляете в другом месте, переименовываете в CalculateBillMexico() и подгоняете его под новые нужды.

Какие проблемы могут возникнуть при таком подходе?

1. Если изменение функционала потребует улучшения основной логики, вам теперь придется делать лишнюю работу и изменять 2 метода.
2. В ходе внесения изменений у вас теперь вдвое больше шансов допустить ошибку.
3. Вы установили шаблон поведения и теперь при экспансии вашей компании на новые рынки ваш код будет требовать создания все новых методов.
4. Со временем объем работ будет существенно возрастать.
5. Появление багов и случаев, когда вы просто забудете внести нужные изменения в каком-то месте, — лишь вопрос времени.
6. Наконец, все новые методы будут отличаться друг от друга ровно настолько, чтобы помешать вам собрать их обратно в кучу и устранить возникший бардак. Но при этом они не будут отличаться аж так, чтобы вам не потребовалось вносить 20 исправлений каждый раз, когда кто-то решит поменять правила подсчетов.

Все это ведет к беспорядку. А ведь это лишь поверхностный взгляд на проблему копипаста.

Копипаст это только начало

Настоящая проблема — дублирование знаний в вашей системе.

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

• Цикл for и комментарий прямо над ним, поясняющий начало, конец и шаг цикла.
• Глобальная переменная с заданным значением, которое затем (возможно) переназначается из файла конфигурации.
• Таблица базы данных со столбцами “PretaxTotal,” “Tax” и “Total”.
• ERP-система, где имена клиентов сохраняются в CRM-модуле, а затем еще раз в биллинговом модуле.

Во всех этих случаях лучший сценарий действий — наличие процедур и систем для тщательного отслеживания дублирования и обеспечения одновременного обновления дублирующихся частей.

Если речь идет о бессмысленном комментарии к коду, такой «системой отслеживания» может быть ворчащий тимлид, заставляющий вас всегда перепроверять комментарии при обновлении кода.

А в случае с ERP-системой это может быть строго сформулированная памятка, в которой говорится, что для обеспечения синхронизации информации о клиенте отделы продаж и бухгалтерского учета должны отправлять официальные электронные письма.

И не забывайте, что это все наиболее благоприятные варианты развития событий.

Все может быть гораздо хуже, когда вы начинаете строить сложную логику (которую вам придется затем поддерживать) для обеспечения синхронности.

Это может быть реализация триггера базы данных при каждом изменении столбца «total», чтобы убедиться, что PretaxTotal + Tax по-прежнему равно Total. Или, возможно, вы пишете какую-то громоздкую логику проверки состояния, чтобы логировать предупреждения, когда дефолтное значение глобальной переменной не совпадает со значением, прописанным в конфигурационном файле.

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

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

2. Код это обуза и источник возможных неприятностей

Мы, разработчики, приучены относиться к коду с любовью. Нам приятно его писать и создавать с его помощью разные вещи.

Больше того, мы все время стараемся изучать новые языки, парадигмы, фреймворки, стеки, инструменты, API и библиотеки. Мы погружаемся в код с головой и радуемся, попадая в состояние потока, когда, как нам кажется, код генерируется особенно плавно.

А некоторые менеджеры среднего звена даже считают количество произведенных строк кода мерилом продуктивности.

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

Забудьте все это.

Я могу понять, почему мы считаем код активом. Но на самом деле код это обуза.

Чем меньше, тем лучше

Знаете, что лучше, чем обойтись 10 строчками кода там, где кому-то другому понадобилась сотня? Обойтись без всяких строк вообще.

Напишите строчку

printf(“Hello World!”);

Как думаете, может здесь что-то пойти не так? Как много здесь потенциальных угроз?

• Будет ли этот код запускаться в среде, позволяющей вывод в консоли?
• Не станет ли эта «магическая строка» источником неприятностей в дальнейшем?
• Нужны ли здесь логи? Это лучший подход к написанию кода.
• Задумывались ли вы когда-нибудь о вопросах безопасности этого кода?

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

Думаете, теперь количество возможных проблем увеличилось вдвое?

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

Я несколько лет выступаю в роли консультанта в очень специфической отрасли. Я занимаюсь data-driven оценкой баз данных и помогаю ИТ-руководству компаний принимать стратегические решения относительно кодовых баз.

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

Знаете, что больше всего коррелируется с нежелательными характеристиками кодовых баз? Их размер.

Почти все плохое в коде имеет заметную взаимосвязь с размером кодовой базы, измеренном в количестве строк кода.

Я люблю код.

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

3. Разработчики-сеньоры: доверяй, но проверяй

На своей первой программистской работе (мне было 23 года) я восхищался разрабочтиками-сеньорами и буквально благоговел перед ними. Пол, Реймонд, Крис, Кен — у каждого из них было в среднем около 20 лет опыта. А их умение работать с несколькими языками программирования я считал совершенно удивительным.

Они научили меня очень многому.

Все это я говорю, чтобы некоторым образом смягчить то, о чем скажу дальше.

Если вы новичок в этой отрасли, то, скорее всего, как и я в свое время, будете считать каждое слово сеньоров жемчужиной мысли. И многие их слова (если вам повезет) таковыми и будут, особенно на первых порах.

Но не все разработчики-сеньоры одинаковы.

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

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

Этот феномен настолько распространен, что придуманный мной несколько лет назад термин «эксперт-новичок» теперь появляется в поиске Google по нескольку сотен раз за месяц. Когда я ввел этот термин, он настолько совпал с опытом людей, что исходный пост стал просто вирусным.

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

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

4. TDD имеет право на существование. Этот подход меняет правила игры

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

• IDE или легковесный редактор кода?
• Apple, Windows или Linux?
• Что вы думаете о PHP?
• Табы или пробелы?

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

Учитывая вышесказанное, я признаю, что по сути делаю то же самое, поддерживая одну сторону в споре о целесообразности TDD.

Но я не проповедую, просто хочу поделиться собственным опытом.

Около 10 лет назад я относился к TDD скептически. То есть, в полезности модульного тестирования как такового я не сомневался. Но разработка через тестирование? Здесь я не был так уверен.

Я решил написать пост в блоге о том, почему TDD это не так уж хорошо.

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

Но у судьбы были другие планы.

Мой «Ага!»-момент в работе с TDD

В первый день работать было странно и неудобно. Собственно, даже в первые несколько дней.

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

Но затем произошло нечто интересное.

Я настолько сфокусировался на этой странной парадигме, что однажды умудрился провести 4-5 часов за написанием кода и при этом ни разу не запустить приложение, чтобы посмотреть, работает ли мой код. Обычно я запускал приложение каждые 10 минут или около того, просто чтобы проверить, работают ли внесенные изменения.

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

Но — удивительный факт! — все работало.

Все без исключений прекрасно работало с первого раза. Абсолютно никаких сюрпризов. Я писал код часами, не обращаясь к GUI и не проверяя ничего в запуске, а все оказалось в рабочем состоянии.

В итоге я написал совершенно другую статью о TDD. И больше не вернулся к прежним подходам.

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

Научитесь вести разработку через тестирование. Вы не пожалеете.

5. Доказательства решают все

Я уже упомянул о своей работе в оценке кодовых баз и об эмпирических данных. Давайте сформулируем это в качестве моего последнего урока.

Доказательства это ваше всё.

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

Вы будете слышать отзывы вроде «это плохой дизайн» или «это не эффективно». Также, вероятно, вы и сами будете говорить подобные вещи. И скорее всего, в обоих случаях не будет никаких доказательств озвученной точки зрения.

Исправляйте это.

Важность доказательств

Доказательства важны как при проверках кода, так и для того, чтобы доказать что-то руководству. С помощью доказательств и фактов вы сможете побеждать в спорах, заслужить уважение окружающих, пробиться на лидерские позиции и подняться по карьерной лестнице.

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

И под «докажите» я подразумеваю не просто найти чей-то там пост. Найдите модули в вашей кодовой базе с глобальным состоянием и без оного, и сравните их, например, по количеству тикетов в JIRA.

Кто-то в команде настаивает, чтобы вы использовали не ту библиотеку, которую вы выбрали, а другую, и ссылается на производительность? Если вас это не устраивает — докажите, что коллега не прав. Запустите тесты.

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

Но, помимо этого, вы начнете вести споры иначе, чем другие люди, а это создаст вам репутацию усердного и корректного человека. Это поможет вам на равных спорить даже с более опытными разработчиками.

И если заглянуть еще дальше, это поможет вам в вашей карьере.

Умение писать код гарантирует прибыльную работу. Умение писать код и использовать доказательства для обоснования действий (как по технической части, так и в бизнесе) гарантирует стремительную карьеру.

Итоги

Я полагаю, что со всеми моими советами при желании и должном усердии можно поспорить. Но я не предлагаю их в качестве непреложных законов или какого-то кодекса поведения. Это лишь уроки, которые я сам извлек за время своей карьеры и которыми я предлагаю вам воспользоваться. Надеюсь, они вам помогут.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]