Я писал код более 20 лет и руководил инженерами почти 10, поэтому могу с уверенностью сказать, что «хорошая» разработка программного обеспечения - это не преодоление или решение сложных вещей. Дело в способности их избегать.

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

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

Разберитесь в своей проблеме (ах)

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

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

- Википедия

Из этого определения мы можем легко понять, что сложность - это «что-то, состоящее из множества частей, где эти части взаимодействуют друг с другом множеством способов». Если сложность характеризуется множеством компонентов и множеством взаимодействий, возможно ли, что наша проблема на самом деле является набором множества более мелких проблем? Во многих случаях ответ, вероятно, положительный. Лучше всего начать с понимания всего объема проблемы, ее контекста и приоритета.

Дизайн, дизайн, дизайн и снова дизайн

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

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

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

Думайте маленькое, действительно маленькое

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

В Appwrite мы разделяем нашу кодовую базу на разные уровни. Первый уровень - это наш API, разработанный как MVC. Второй уровень - это библиотеки для конкретных приложений. Третий уровень - это общие компоненты, которые мы обычно можем повторно использовать в проектах, и мы в основном открываем их, чтобы другие также могли использовать и улучшать. На этом уровне мы также склонны использовать сторонние зависимости, которые соответствуют нашим критериям простоты и помогают нам создавать наши продукты. Каждый компонент в нашем стеке может иметь только одну конкретную роль и интуитивно понятный API, разработанный для людей.

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

Код для людей

Выбор правильных соглашений об именах - одна из важнейших задач нашей повседневной жизни в Appwrite. Были времена, когда мы тратили час на присвоение имени переменной, и это нормально. Как и в реальной жизни, если имя закрепилось, его сложно изменить, особенно если оно является частью вашей подписи API.

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

Документируйте все

Ваш код может быть понятным, и это здорово, но всегда ли это так для каждого разработчика? Вы пишете идеальный код в 100% случаев? По крайней мере, для меня ответ - нет. Добавление нескольких текстовых строк в верхней части ваших функций, небольшого файла readme, нескольких примеров для ваших API, ссылок на веб-сайты, на которые вы ссылались, или руководства для вашего будущего члена команды может принести только пользу.

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

Эльдад Фукс

Я создатель, основатель и генеральный директор Appwrite.io. Мы создаем комплексную платформу, которая предоставляет разработчикам все инструменты и API-интерфейсы, необходимые для создания любого современного программного обеспечения, используя имеющиеся у них знания.

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