Последние 4-5 десятилетий спрос на программистов вырос в сотни раз. По некоторым оценкам их количество удваивается каждые пять лет, и в результате программист с 5-летним опытом работы имеет стаж работы в отрасли больший, чем у половины всех ее сотрудников.
Эрик Дитрих* около 10 лет провел на должностях, где его основной функцией было написание кода. Еще 10 лет были связаны с управлением программистами, их обучением, консультированием организаций, практикой оценки кодовой базы, а в наши дни и контент-маркетингом. Но во всех этих ролях он в той или иной степени писал код. И, по своим расчетам, прошел больший путь, чем 94% работающих в отрасли. Получается некое противопоставление: программист со стажем, который общается с кучей новичков в программировании.
Специально для своего блога Эрик попытался обобщить весь свой опыт в виде кратких советов, которые он хотел бы дать молодым программистам. Под катом — наиболее важные, на взгляд автора, уроки и выводы из его 20-летней карьеры.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
В этом году я все больше узнаю о платформе DEV. Это освежающе позитивный оазис в огромном море сердитых комментаторов Reddit и знатоков типа «ну вообще-то...», которым является широкий мир программного обеспечения.
Одна из интересных сторон этого сообщества заключается в том, что в нем, похоже, много начинающих. Я регулярно вижу посты, написанные новичками в отрасли и для новичков. Под новичками я подразумеваю людей, которые являются начинающими программистами, учатся в буткампах, ищут работу начального уровня или занимают должности с неудачным квалификатором «младший».
Я нахожу это приятным. Относительные новички, как правило, полны энтузиазма и воодушевлены нашей отраслью. И это воодушевление заразительно.
Но это также заставляет меня почувствовать свой статус ветерана в этой отрасли.
Вот пять советов, которыми я хочу поделиться с молодыми специалистами.
1. Дублирование знаний — наихудший вариант
«Избегайте программирования методом копипаста!»
Если кто-то еще не ударил вас линейкой по руке за копипаст кода в вашем приложении и адаптацию результата (антипаттерн «копируй, вставляй и подгоняй по вкусу»), считайте, что ударили сейчас.
Прекратите это. Немедленно. Это ужасная и неряшливая практика.
Вот проблемы, связанные с таким подходом:
Если дальнейшее изменение потребует корректировки основной логики, то вам в этом случае придется проделать дополнительную работу и модифицировать 2 метода.
Теперь в процессе таких изменений у вас удвоенный шанс внести ошибки.
Вы создали «шаблон проектирования», и теперь ваш код просит нового, избыточного метода, по мере того как ваша глобальная экспансия продолжается.
Трудоемкость изменений стремительно возрастает со временем.
И то, что вы внесете ошибки, забыв сделать изменения везде, где необходимо — это лишь вопрос времени.
В конце концов, все эти методы будут различаться ровно настолько, что вы уже не сможете разумным образом слить их вместе и исправить беспорядок, но при этом они не будут различаться настолько, чтобы вы могли избежать внесения 20 изменений каждый раз, когда кто-то обновляет правило выставления счетов.
Это беспорядок. И это — копипаст — лишь та проблема, которая лежит на поверхности.
«Копипаста» — это только начало
Настоящая проблема — это дублирование знаний в вашей системе.
Дублирование знаний в вашей системе может происходить по-разному, и корявая «копипаста» — это лишь самый очевидный и тупой способ. Рассмотрим другие примеры дублирования знаний.
Цикл for и комментарий к коду прямо над ним, объясняющий начальное значение, конечное значение и приращение.
Глобальной переменной присваивается значение в теле программы, а затем (возможно) повторно присваивается значение из файла конфигурации.
Таблица базы данных со столбцами «PretaxTotal» (итого без учета налога), «Tax» (налог) и «Total» (итого).
Широкомасштабная ERP-система, которая хранит данные о клиентах в своем модуле CRM, а затем еще раз — в биллинговом модуле.
Во всех этих случаях хорошо, если у вас есть процессы и системы для тщательного отслеживания дублируемых данных и одновременного их обновления.
В случае с бессмысленным комментарием к коду это может быть просто придирчивый руководитель команды, который заставляет вас всегда проверять наличие комментариев при обновлении кода.
Или, в случае ERP-системы, это может быть жестко сформулированная инструкция, сообщающая отделу продаж и бухгалтерии, что оба эти подразделения должны отправлять официальное электронное письмо, чтобы обеспечить синхронизацию информации о клиентах.
И, помните, это лучшие сценарии.
Худшие сценарии возникают, когда вы начинаете строить сложную логику (которую потом нужно поддерживать — см. следующий раздел) для обеспечения синхронности.
Возможно, вы реализуете триггер базы данных при каждом изменении столбца «Total», чтобы убедиться, что PretaxTotal + Tax по-прежнему равны Total. Или, возможно, вы пишете громоздкую логику проверки состояния, чтобы занести в журнал предупреждение, если значение глобальной переменной по умолчанию не совпадет с присвоенным значением в конфигурационном файле.
В самом худшем случае эти данные просто рассинхронизируются. Тогда вам, как программисту, очевидно, не стоит беспокоиться, поскольку выяснение того, почему вы никогда не выставляли счета клиентам или как вы годами завышали взимаемую с них плату, вероятно, выше вашей компетенции.
Но вы можете избежать всего этого, безжалостно искореняя и активно сопротивляясь дублированию знаний в любой части ваших систем.
2. Код — это пассив
Как разработчики, мы учимся любить код. Нам приятно писать код, и это захватывающий процесс — создавать нечто.
Более того, мы ищем для изучения новые языки, парадигмы, фреймворки, стеки, инструменты, API и библиотеки. Мы погружаемся в работу и празднуем потоковое состояние — то, в котором мы с радостью генерируем код.
И мы не одиноки в этом праздновании.
Некоторые умники даже зашли настолько далеко, что приняли в качестве показателя производительности количество строк кода, генерируемое в час. Но даже если вы не дошли до такой убийственной степени глупости, вы можете считать, что чем больше кода, тем лучше. Код — это ДНК вашего сногсшибательного приложения и бизнеса, и компании считают его ценной интеллектуальной собственностью.
Забудьте обо всем этом.
Я понимаю, почему мы смотрим на код как на актив. Но реальность такова, что код — это сплошной пассив.
Меньше — значит больше
Знаете, что может быть еще лучше, чем сделать за 10 строк кода то, что кто-то другой сделал за 100? Сделать это за 0 строк кода.
Возьмите и напишите строку кода:
printf("Hello World!"); Как вы думаете, сколько всего может пойти не так?
Будет ли этот код выполняться в среде, позволяющей вывод на консоль?
Не станет ли эта волшебная строка впоследствии проблемой?
Разве вы не должны вести журнал? Это передовая практика.
Вы хотя бы раз задумались о том, как это отразится на безопасности?
Давайте, будучи консерваторами, считать, что есть порядка 10 вещей, которые могут случиться с этой строкой кода. Итак, теперь добавим вторую строку.
Вы думаете, что это доводит общее количество вещей, которые могут пойти не так, до 20?
Я бы сказал, что, скорее всего, это приведет к 100. Считайте меня пессимистом, но я думаю, что связь между потенциальными проблемами и строками кода ближе к комбинаторной, чем к линейной.
На самом деле я несколько лет работал консультантом по управлению с очень узкой специализацией. Я занимаюсь оценкой кодовых баз на основе данных и помогаю ИТ-руководству принимать стратегические решения в отношении кодовых баз.
Поэтому я вижу, анализирую и собираю статистику по множеству кодовых баз. Если включить кодовые базы, которые я проанализировал в автоматическом режиме помимо клиентских кодовых баз, то я собрал подробную статистическую информацию о более чем 1000 из них. Затем я взял эти данные и провел регрессионный анализ в поисках корреляций.
Знаете ли вы, что больше всего коррелирует с нежелательными свойствами кодовой базы? Размер кодовой базы.
Почти все плохое в кодовых базах имеет значительную связь с размером кодовой базы, измеряемым в логических строках кода.
Я люблю код.
Мне нравится его писать, изучать, анализировать и создавать с его помощью разные вещи. Но не заблуждайтесь: это огромный пассив. Всегда стремитесь делать все, используя как можно меньше кода.
3. Старшие разработчики: доверяй, но проверяй
На своей первой работе по разработке программного обеспечения, в возрасте 23 лет, я восхищался старшими разработчиками с почти благоговейным трепетом. Пол, Рэймонд, Крис, Кен — в среднем около 20 лет опыта у каждого — я могу живо представить их всех, и я считал их навыки работы с несколькими языками программирования совершенно удивительными.
Я многому у них научился.
Я говорю об этом, потому что хочу придать должный градус тому, что собираюсь сказать дальше.
Если вы новичок в отрасли, вы, вероятно, как и я, будете считать, что каждое слово старших разработчиков в группе — это жемчужина мудрости. И многие из них будут таковыми — если вам повезет — особенно поначалу.
Но не все старшие разработчики созданы (или, в моем случае, выдвинуты на эту должность) одинаково.
Оглядываясь назад, можно сказать, что перечисленные выше люди были хорошими программистами, и я действительно научился у них хорошим вещам. Но в процессе своей карьеры я также понял, что мне просто повезло с тем влиянием, которое первоначально было на меня оказано.
На каждый офис с потрясающими, полезными старшими разработчиками приходится другой офис, населенный маленькими людьми с небольшой властью, чья основная квалификация — это не технические навыки, а умение долгое время продержаться, умудриться не быть уволенным и добиться повышения до звания «старший» или «главный».
Это явление настолько распространено, что термин, который я придумал несколько лет назад для его описания, теперь набирает сотни поисковых запросов в Google в месяц. Когда я предложил термин «начинающий эксперт» (expert beginner), он вызвал такой отклик, что первоначальный пост стал распространяться лавинообразно.
Я говорю это не для того, чтобы похвастаться. Я говорю это для того, чтобы предупредить вас, что многие старшие разработчики внешне кажутся занимающими эту должность по праву, но на самом деле это не так.
Поэтому, если вы новичок, доверяйте старшим по должности и полагайтесь на них, но не считайте, что то, что они вам говорят, является правдой или правильным. Проверьте это самостоятельно (желательно не прямо у них на глазах).
4. TDD — это оправдано, и это меняет правила игры
Когда речь заходит о чем-либо, связанном с программированием или даже техникой, мы в своей отрасли склонны сходить с ума от предвзятости, поддерживая тот или иной выбор.
Что лучше: IDE или простой редактор?
Apple, Windows или Linux?
Что вы думаете о PHP?
Табуляция или пробелы?
Поднимите любую из этих тем и посмотрите, какие соревнования по крику возникают между теми, кто имеет твердое мнение. Так что, учитывая все это я понимаю, что вступаю на похожую территорию с вопросом «TDD или не TDD».
Я хочу не проповедовать, а поделиться собственным опытом.
Около 10 лет назад я был скептиком в отношении TDD. Заметьте, я не был скептиком в отношении модульного тестирования: я принял его как полезную технологию практически с самого начала.
Но TDD? Я не был настолько уверен.
Я решил написать в блоге статью о том, почему TDD не так уж и хорош.
Но я не хотел просто написать неубедительный, грошовый материал по этому вопросу. Вместо этого я решил сделать небольшой клиентский проект (между прочим, по фиксированной цене), строго следуя правилам TDD, чтобы потом написать пост с предпосылкой «Я потратил пару недель на чистый TDD, и он не слишком хорош».
Но у судьбы были другие планы.
Мое «озарение» с TDD
Это казалось неудобным и странным на протяжении одного дня. Наверное, даже нескольких дней.
Все это занимало целую вечность. Все, что я делал, казалось громоздким и неестественным. Я просто добавлял заметку за заметкой в подтверждение того, что это ужасный способ действий.
Но потом произошла забавная вещь.
Я был настолько зациклен на этой неудобной парадигме, что в один из дней умудрился потратить 4-5 часов на написание кода, ни разу не запустив приложения, чтобы проверить, работают ли мои изменения. Обычно я запускал приложение каждые 10 минут или около того чтобы проверить, действительно ли мои изменения работают.
Осознав, что прошло несколько часов, я запустил приложение, вздыхая и ожидая, что мне придется часами его отлаживать. В конце концов, я пропустил около 30 циклов.
Но произошла странная вещь: все работало.
Все работало идеально, с первого раза, без исключения. Не было абсолютно никаких сюрпризов. Я писал код часами, не глядя на собственный графический интерфейс и не проверяя ничего во время выполнения, и все просто работало.
В итоге я написал совсем другую статью о TDD. И больше ни разу не оглянулся назад.
Я изучил эту технологию, освоил ее, преподавал курсы по ней, консультировал по ней и проводил по ней коучинг разработчиков. Но помимо этого, я изучил влияние модульного тестирования на кодовые базы и обнаружил, что это влияние однозначно хорошее.
Изучите TDD. Вы не пожалеете.
5. Доказательства — сила
В этом посте я уже упоминал о своей практике оценки кодовой базы и говорил об эмпирических данных. Давайте немного формализуем это с помощью последнего урока из моей карьеры.
Доказательства — это все.
Ревизии кода могут служить образовательными, расширяющими возможности мероприятиями. Или они могут «казнить вашу душу».
Однако, скорее всего, они окажутся где-то посередине между познавательным опытом и бессмысленными препирательствами.
Вы услышите такие слова, как «это не очень хороший дизайн» или «это неэффективно». Вы тоже, вероятно, будете говорить такое. И, скорее всего, вы будете слышать и говорить это без какого-либо подобия доказательств.
Исправьте это.
Важность доказательств
Если люди не принимают вас всерьез во время ревизии кода или любой другой формы сотрудничества в вашей команде или организации, доказательство — ваш друг. Если вы пытаетесь доказать руководству или начальству свою правоту по любому поводу, доказательство — ваш друг.
Доказательства принесут вам аргументы, уважение, руководящие роли и карьерный рост.
Вы считаете, что широкое использование глобальных переменных в вашей команде убивает вас? Не спорьте об этом — докажите это.
И под словом «доказать» я не имею в виду «найти что-то вроде поста о вреде "глобального состояния" и апеллировать ко мне как к авторитету». Я имею в виду «найти модули в вашей кодовой базе с глобальным состоянием и без него и сравнить их с частотой инцидентов в тикетах JIRA» или что-то в этом роде.
Кто-то в вашей команде потребовал, чтобы вы использовали библиотеку или API, отличную от той, которую вы выбрали, из-за якобы «лучшей производительности»? Это вас не удовлетворяет?
Докажите, что член команды не прав. Проведите реальные испытания на время.
Приучите себя проводить эксперименты вместо того чтобы громко выражать свое мнение и категорически на нем настаивать. Это сразу же дает возможность эмпирически подтвердить правильность ваших мыслей.
Возможно, вы поймете, что правы перед лицом скептицизма. А в другом случае вы, может быть поймете, что были неправы, что тоже ценно.
Но помимо этого, вы начнете вести споры так, что другие не смогут вас оспорить, создавая себе тем самым внушительную репутацию усердного и корректного специалиста. Это поможет вам преодолеть даже такие, казалось бы, непреодолимые препятствия, как противостояние «я всего лишь младший, а он — старший (начинающий эксперт)».
А если заглянуть еще дальше, то это открывает широкие возможности для карьерного роста.
Умение писать код гарантирует прибыльную карьеру. Способность писать код и использовать доказательства в ходе технико-экономического обоснования того или иного порядка действий обеспечивает головокружительную карьеру.
Пользуйтесь (или не пользуйтесь) этим на здоровье
Когда я писал этот пост, я был настроен философски. На самом деле я писал его во время перелета из Чикаго в Хьюстон, с бокалом вина в руке и отказавшись от Wi-Fi. Поэтому мне оставалось только разговаривать со стюардессами (я сижу в первом ряду, так что они здесь крутятся) и вспоминать о своей карьере.
Я полагаю, что с этими тезисами можно поспорить, если очень постараться.
Но я не предлагаю их как непреложные законы программирования или некий кодекс поведения профессионала. Я предлагаю их как уроки, которые я сам усвоил за время своей карьеры, и притом с оговоркой, что это всего лишь мое мнение.
Но, надеюсь, эти мнения помогут кому-то из вас. Так что воспринимайте их, как вам нравится, и пользуйтесь на здоровье.
