Что делать, если вы посредственный программист

1
14600
Добавить в избранное

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

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

Давайте разберемся, как быть, если вы посредственный программист.

Постоянно гуглите простейшие вещи

Бывает трудно запомнить многие вещи: функции и методы из стандартных библиотек, порядок аргументов функции, имена пакетов, шаблонные конструкции и так далее.

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

Вы такой не один. Есть популярная ветка в твиттере, которую начал создатель Ruby on Rails, Дэвид Хейнемейер Ханссон:

Привет, меня зовут Дэвид. Я не могу написать алгоритм сортировки пузырьком на доске. Я постоянно подглядываю код в интернете. Я не умею в загадки.

Однако у постоянного обращения к поиску есть некоторые последствия:

  • Вместе с кодом вы копируете плохие архитектурные решения и уязвимые места.
  • Формируется определенный склад ума: если что-то не получается нагуглить, то «Хьюстон, у нас проблемы».
  • Нет интернета – работа стоит.

Но это все не такая большая проблема. Есть некоторые вещи, которые помогут вам справиться:

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

Делайте просто

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

Чтобы определить, насколько хорош код, существует шуточная единица измерения: wtf/min.

wtf-minРевью кода: хороший vs плохой

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

Как делать вещи простыми с самого начала:

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

Не доверяйте себе

Некоторые программисты пишут по умолчанию высококачественный код. Например, Маргарет Гамильтон, главный инженер программы Аполлон.

margaret-hamiltonМаргарет Гамильтон и ее код для лунной миссии

Но если вы не гений, не стоит верить всему что вы написали. Всегда есть вероятность, что вы допустили какую-то неприятную мелочь в коде, а иногда и полностью что-то сломали. Среди неприятностей могут быть:

  • Логические ошибки.
  • Синтаксические ошибки.
  • Архитектурные просчеты.
  • Стилистические ошибки.
  • Дыры в безопасности.

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

И все же, как защитить проект? Есть несколько решений:

  • Пишите тесты. Много тестов. Начиная с интеграционного тестирования, заканчивая юнит-тестами.
  • Используйте статическую типизацию. К примеру, вам поможет mypy для Python или Flow для JavaScript.
  • Используйте автоматизированные проверки стиля кода. Для каждого языка и редактора кода существует множество плагинов.
  • Используйте инструменты для проверки качества кода. Существуют различные плагины для редакторов кода и инструменты в IDE, которые укажут вам на проблемы в коде: слишком много логики в одной строке, нет необходимости в классе, слишком сложная функция и так далее.
  • Просматривайте свой код. Особенно перед отправкой в мастер-ветку. А иногда и после.
  • Просите других людей посмотреть ваш код. Если есть возможность сделать это бесплатно – пользуйтесь ею. Свежий взгляд быстрее и вероятнее найдет ошибки и нестыковки там, где вы их не видите.

Решение должно работать не только на вашей машине

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

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

Даже когда приложение развернуто, перепроверьте себя

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

  • Sentry. Когда у кого-то из пользователей случится проблема – вы будете оповещены. Можно связать с почти любым языком программирования.
  • Сервисы вроде PaperlogApp помогут собирать логи различных серверов и процессов в одном месте.
  • Grafana поможет мониторить состояние сервера. Можно следить за нагрузками на сервер и предупредить те моменты, когда поток пользователей станет критичным и сможет обвалить сервер.

Другими словами, даже если все работает отлично, вам необходимо следить за состоянием приложения после деплоя.

Постоянно учитесь, если вы посредственный программист

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

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

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

Успехов!

Хотите получать больше интересных материалов с доставкой?

Подпишитесь на нашу рассылку:

И не беспокойтесь, мы тоже не любим спам. Отписаться можно в любое время.




Добавить комментарий