Я лично знаю разработчиков, очень талантливых, способных создавать прекрасный софт без (или почти без) усилий. Благодаря этим одаренным личностям наша отрасль полна большими надеждами. Но печальная правда в том, что не каждый – ниндзя/гуру/звезда программирования. Речь о таких, как я. Я – посредственный программист. Эта статья покажет вам, как выжить в индустрии, если вы – не гений. 

Все время гуглю самые простые вещи

Множество вещей я просто не помню. Например, функции и методы из стандартных библиотек, названия пакетов, шаблонный код и так далее. Приходится гуглить, причем ежедневно. Также, я использую код из старых проектов. Иногда – даже копирую ответы со StackOverflow или GitHub. Да, это на самом деле работает – программирование по StackOverflow (StackOverflow Driven Development). 

Я такой не один. Множество программистов делают так же. Есть популярный тред в Twitter, который начал создатель Ruby on Rails.

Но почему это – обязательно плохо? В таком подходе есть несколько минусов: 

  1. Это приводит к тому, что вы копируете плохие решения или уязвимый код у других людей. 
  2. Это формирует особенный настрой: если мы не можем нагуглить что-то, тогда – “Хьюстон, у нас проблема”. 
  3. Если интернета нет, работать мы не сможем. 

Но не думаю, что это – большая проблема. Это даже может стать вашим секретным оружием.  У меня есть несколько советов о том, как уменьшить негативное влияние этих эффектов: 

  1. Используйте IDE для автодополнений и предположений, так что не придется гуглить основы языка. 
  2. Запомните, где (а не как) вы уже решали подобную проблему. 
  3. Весь код, который вы перепощиваете в проект, должен проходить через анализ, рефакторинг и ревью. Таким образом, мы не навредим проекту плохим кодом, но при этом сможем предоставить быстрое решение. 

Я пытаюсь делать все максимально просто

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

Как отличить простой код от сложного? Можно применить метод WTFs/Minute.

Принцип очень прост. Как только вы нашли в коде что-то, чего вы не понимаете – он сложный. Как его упростить? 

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

Как писать простой код изначально? 

  1. Используйте правильные название переменных, функций, классов. 
  2. Удостоверьтесь, что каждая часть вашей программы выполняет только одну вещь. 
  3. Предпочтительно использовать чистые функции, а не регулярные. 
  4. Предпочтительно использовать регулярные функции, а не классы. 
  5. Обращайтесь к классам только в моменты исключительной нужды. 

Я себе не доверяю

Некоторые программисты доказали, что способны писать очень качественный код. Например, Маргарет Хамильтон, ведущий разработчик Project Apollo (проекта, в результате которого люди впервые высадились на поверхность ЛУНы – ред.). На этом фото она стоит рядом с кодом, написанным для лунной миссии:

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

  • ошибки в языке;
  • ошибки в логике;
  • ошибки в дизайне софта;
  • ошибки в стилях;
  • ошибки в безопасности;
  • WTF-ошибки (мои любимые).

Не существует волшебной книги “Научитесь писать код без багов”. И это – нормально. Баги есть во всем софте. Кроме, разве что, этого фреймворка. 

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

  1. Пишите тесты, множество тестов. Начиная от интеграционных и оканчивая юнит-тестами. Прогоняйте код в CI перед каждым запросом на включение кода. Это защитит вас от некоторых логических ошибок. 
  2. Используйте статическую типизацию. К примеру, с JavaScript мы используем flow и mypy – с Python. 
  3. Используйте автоматизированные проверки стилей. Существует множество сервисов для этого в каждом из языков. 
  4. Используйте проверки качества. Некоторые инструменты применяют к вашему коду сложные эвристические алгоритмы, чтобы засечь разные проблемы (к примеру, тут этот класс не нужен, там – слишком сложная функция). 
  5. Отдавайте свой код на ревью. 
  6. Платите другим людям за проверку вашего кода. Когда разработчик смотрит на код впервые, ему проще засечь непоследовательности и неудачные дизайнерские решения. 

Это должно работать не только на моем компьютере

Когда моя команда работала над первым масштабным софтверным проектом почти 10 лет назад, мы выкатили его как Java-исходники, которые отказались компилироваться на целевом сервере. Это случилось за несколько часов до презентации софта клиенту. Это был провал. Как-то нам удалось поднять софт и заставить работать, но это был непередаваемый опыт. 

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

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

Я, например, всегда о чем-то забываю, создавая сервера, конфигурируя и связывая их. Столько всего приходится держать в голове. Но все это можно автоматизировать, ведь существуют прекрасные инструменты для этого, вроде Terraform, Ansible или Packer

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

Что делать? 

  1. Автоматизируйте все, что вы используете для деплоя.
  2. Используйте Docker для разработки, тестов и деплоя приложений.
  3. Используйте инструменты для деплоя. 

Даже после деплоя приложения я все еще себе не доверяю 

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

  • Sentry. Когда случается ошибка – у любого из ваших пользователей, вы получите уведомление. Работает почти со всеми языками программирования. 
  • Различные сервисы и инструменты для сбора логов для разнообразных процессов и серверов в одном месте. 
  • Мониторинг серверов. Здесь вы сможете настроить мониторинг CPU, дисков, сетей, памяти. Можно даже получить немного временной форы для масштабирования перед тем, как пользователи поломают ваш сервис. 

Вкратце, нужно мониторить свое приложение в продакшене. 

Постоянно учусь

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

В заключение – нужно понимать две важные вещи:

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

И это вообще никак не связано с вашими умственными ресурсами или образом мышления.