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

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

Старое вино в новой бутылке

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

Если бы нас спросили: «Почему вы так делаете?» или «Почему вы выбрали именно этот стек?» что бы мы ответили?

На ум приходят несколько ответов:

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

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

  • «Почему я начал делать это именно так?»
    Все наши привычки и убеждения в отношении разработки программного обеспечения начинались с здравого смысла. Может быть, мы нашли ошибку, и нам нужно было ее обойти. Компилятор неправильно оптимизировал наш код. Фреймворк заставил нас адаптировать наш стиль. Или мы просто не знали ничего лучшего в то время.
  • «Нет лучших способов сделать это (сейчас)?»
    Наши языки и инструменты постоянно развиваются, появляются новые функции и парадигмы, улучшения производительности и исправления. Даже если бы мы могли доверять компилятору в прошлом, остается ли он в силе сейчас? Исправлена ​​ли наконец ошибка, которая заставила нас сделать что-то по-другому? Когда мы в последний раз проверяли и подтверждали наши предыдущие предположения или даже сравнивали наше решение с другими?

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

Конечно, мы всегда так поступали. Это наше « нормально. » Но спрашивали ли мы себя в последнее время, хорошо ли это (по-прежнему)?

Делая это по-своему

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

// Habit-Driven-Development
char x[2048];
for(int i = 0; i < 2048; i++) {
    [i] = 0;
}

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

// Standard Library
char x[2048];
memset(x, 0, sizeof(x));

Зачем нам выполнять инициализацию самостоятельно, если существует более короткий и распространенный способ? Возможно, мы считаем, что наше решение безопаснее или даже быстрее, чем вызов memset(). И это может быть правдой в определенных условиях, тем более что микробенчмаркинг - еще одна действительно сложная проблема.

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

Будь умным, а не умным

Компиляторы способны на довольно сложные приемы оптимизации и хитрые реализации, зависящие от процессора и платформы. Знаете ли вы, что умный компилятор может даже заменить наш for-цикл на memset()?

Если бы мы провели микротест нашего кода (чего мы не делали), мы могли бы подумать: «Мой код работает так же быстро, как memset()!» хотя компилятор заменил нашу привычку более гибким и лаконичным кодом.

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

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

Нам нужно быть умными в отношении нашего кода и не пытаться быть умными.

Истина от повторения

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

Это верно как для хороших, так и для вредных привычек.

Почти правильно

Пример повторения истины - цитаты из фильмов. Все мы знаем цитаты из известных фильмов и можем их цитировать наизусть:

«Люк, я твой отец».
- Дарт Вейдер, Империя наносит ответный удар

«Сыграй еще раз, Сэм».
- Рик Блейн, Касабланка

«Тебе повезет, панк?»
- Гарри Каллахан, Грязный Гарри

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

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

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

Привычки других людей

Иногда привычки даже не наши!

Любая современная IDE обеспечивает генерацию большого количества кода для рутинных задач. Это замечательно для удобства, но является ли это наилучшим кодом для решения проблемы? Принудительные правила кодирования или автоматическая линтинг и исправление - еще один внешний фактор, влияющий на наш код.

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

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

Не начинайте с нуля

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

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

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

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

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

В поисках собственного стиля

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

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

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

Это преувеличенный пример, но это правильный выбор стиля:

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

Заключение

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

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

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

Технологии движутся вперед, и мы должны тоже.

Книжные Рекомендации

Мои статьи по теме



Соотношение сигнал / шум
В нашем коде должно передаваться как можно меньше шума по сравнению с желаемым и действительным релевантным сигналом… codeburst.io





Назвать вещи сложно
Хороший и чистый код начинается с собственных имен для всех вещей. medium.com





У вас плохие комментарии
С комментариями может многое пойти не так. medium.com