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

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

Ключ № 1: Станьте учеником ремесла

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

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

Ключ № 2: подумайте о цели, прежде чем писать код

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

Невероятно полезно обдумать конечную цель, прежде чем приступить к работе. Если я начну писать код без четкого видения цели, я автоматически попаду в безграничную проблему и настрою себя на извилистую задачу. Нет ничего плохого в том, чтобы извиваться само по себе, но когда вам нужно целенаправленно работать над временной шкалой, сначала подумайте об эндшпиле. Вы пишете код для десяти клиентов или для десяти миллионов клиентов? Что произойдет, если ваш уровень управления внезапно решит, что этот прототип будет запущен в производство? Собираетесь ли вы развертывать на AWS, Azure или что-то еще?

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

Ключ № 3: знайте аудиторию своего кода

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

Мое мнение состоит в том, чтобы лучше всего объективно взглянуть на аудиторию, которая будет иметь дело с кодом, и писать с учетом этой аудитории. Ваша аудитория — клиент или коллега? Собираетесь ли вы в значительной степени полагаться на ORM, когда остальная часть вашей команды является гуру SQL? Собираетесь ли вы использовать фреймворк Play, когда ваша команда является экспертом Spring? Угловой против Аурелии? Python против Go против Ruby?

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

Например, однажды я руководил проектом по переписыванию C#-приложения среднего размера. Команда разработчиков C# хотела добавить важную часть бизнес-логики в стек C#, что является понятным и естественным стремлением, учитывая их область знаний. Однако из плана проекта я понял, что бюджет на техническое обслуживание был очень ограниченным, и в результате команда, ответственная за это обслуживание, должна была иметь легкие навыки C# и большие навыки SQL. Поэтому я решил поместить критически важную бизнес-логику в хранимые процедуры SQL, где я знал, что ее будет легче отделить, поддерживать, оптимизировать производительность и т. д., хотя мой мозг разработчика приложений хотел сделать это в стеке приложений. Если бы состав проекта был другим, возможно, решение было бы другим. Интересно, как можно применить закон Конвея во время проектирования, не так ли?

Ключ № 4: Практикуйте программирование без высокомерия

Когда я говорю «высокомерие» в этом контексте, я имею в виду классическую ловушку: думать, что ваш код в чем-то лучше или что он ясен и очевиден просто потому, что вы его написали.

Однажды мне пришлось модифицировать код, написанный несколькими годами ранее. Я помню, как подумал про себя: «Ох, кто это написал?? О да, это был я». Дело принято. Я, наверное, думал, что это отличный материал, когда я его изначально продюсировал. Высокомерный? да.

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

Ключ № 5: просмотрите код вместе с другими

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

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

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

Резюме

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

У вас, несомненно, есть некоторые из ваших собственных жемчужин мудрости, которыми вы можете поделиться, и я буду рад их услышать!