(Эта запись изначально размещалась на веб-сайте Mind Foundry)
Как разработчики программного обеспечения, мы призваны принимать решения. Я бы даже сказал, что большая часть нашей работы вращается вокруг этого, от именования до выбора технологий, от выбора наиболее подходящих соглашений до определения наилучшего командного процесса. Таким образом, принятие решений настолько глубоко и тонко укоренено в нашем ремесле, что мы часто забываем о его последствиях. Что я хочу исследовать сегодня, так это способность довольствоваться нижней частью спектра, то есть выбирать самый простой вариант и почему вы должны уделять ему больше, чем мимолетные размышления.
Простота — это не наивность
Когда я начинал работать инженером-программистом, мир, безусловно, казался мне черно-белой панорамой. Я знал, что некоторые проблемы требуют конкретных решений, и я не хотел идти на компромисс. В качестве примера я хочу рассказать вам одну историю.
Прежде чем меня наняли в Mind Foundry, мне пришлось пройти всестороннее собеседование, разработанное для того, чтобы убедиться, что каждый в команде подходит. Я вылетел в их штаб-квартиру в Оксфорде, чтобы начать этот процесс, и очень надеялся произвести хорошее впечатление. Первым упражнением был тест на кодирование. К сожалению, я не могу вспомнить мельчайших подробностей проблемы, для решения которой меня призвали, но я помню, что мое решение было вычурным и довольно претенциозным: оно использовало trie, нишевое префиксное дерево поиска. Хотя я был счастлив, что выбрал идеальную структуру данных для работы, я внутренне паниковал и надеялся, что моя реализация будет работать так, как ожидалось. Как многие читатели, вероятно, знают, графовые алгоритмы круты, но требуют большой точности для правильной работы: стресс во время собеседования — не совсем идеальный сценарий кодирования. Однако, к моему удивлению, игрушечная программа работала должным образом даже в крайних случаях. Я снова мог дышать! Тогда один из интервьюеров задал мне простой вопрос: «Почему вместо этого вы не использовали сет?». Набор — это простая структура данных, которую каждый разработчик изучает в первые годы своей жизни. Я был ошеломлен. Я убедил себя, что мой выбор дал правильный инструмент для работы, несмотря на его обременительные умственные способности. Я хотел покрасоваться и искал подходящее, но сложное решение.
Вспоминая после нескольких лет работы в Mind Foundry, я понимаю, почему мне задали этот вопрос. Иногда поиск более простого решения позволяет нам сосредоточиться на других проблемах. Хотя это может быть и не оптимально, но снижает умственную нагрузку, ускоряет разработку, облегчает другим людям понимание нашего мыслительного процесса и позволяет расширять возможности в будущем. Это ключевые выводы, на которых я хочу сосредоточиться в следующих абзацах.
Меньше умственной нагрузки
Хотя поначалу это может показаться неинтуитивным, умственная нагрузка может стать проблемой для разработчиков. Это может показаться нелогичным: в конце концов, разработчики должны выполнять интеллектуальную работу — переводить естественный язык в код. Однако есть много вопросов, требующих внимания: взаимодействие с пользователем, правильность, проверка данных, обработка ошибок и пограничных случаев и т. д. Это всего лишь примеры из множества проблем, которые необходимо постоянно решать вместе. Вот почему поиск более простого решения может быть выгоден для скорости и эффективности разработки. Это высвобождает энергию мозга, которую можно направить на решение других потенциальных проблем. Выбор того, куда направить более глубокий интеллектуальный фокус, — это еще одно решение, которое мы призваны принять, и, в конечном счете, это просто еще одна форма принятия решений.
Более простое решение, вероятно, будет иметь другие недостатки. Например, чтобы отображать актуальную информацию в пользовательском интерфейсе, можно выбрать подход с коротким опросом: интерфейс будет запрашивать данные на удаленном сервере каждые несколько секунд. Это расточительно, но легко реализуемо. Это может привести к проблемам с производительностью, но любой разработчик, даже самый младший, может понять, что делает код, и использовать его. В то время как потоковые решения или push-запросы могут решить одну и ту же проблему лучше, они требуют большего опыта и участия; и платформа может быть недостаточно зрелой, чтобы оправдать этот выбор. Компромиссы неизбежны.
Более быстрая разработка
Работа в команде требует координации. Соблюдение сроков важно для поддержания доверия между компанией и ее клиентами. Вот почему иногда рекомендуется выбрать более быстрый маршрут. Как и во всем, недостатки неизбежны. Одной из цен, которые мы платим за более быструю доставку сегодня, может быть технический долг: компромиссы, которые необходимо будет решить в будущем, чтобы снизить потери от наших прошлых решений. Многие разработчики боятся идти на компромиссы, но технический долг не следует рассматривать как пугало, которое нужно держать все время на расстоянии вытянутой руки. Наоборот, это часть процесса разработки. Мы всегда должны рассматривать его как переменную и работать над его уменьшением всякий раз, когда внешнее давление ослабевает: между релизами, в период затишья или при изменении требований.
Например, может быть полезно развивать такой образ мышления. на стадии «зеленого поля» нового проекта. Всего несколько дней назад моя команда рассматривала возможность внедрения модели издатель-подписчик для реализации системы распределения очередей задач. Но поскольку затраты на настройку и обучение потребовали бы от нас существенной задержки MVP, мы выбрали простое решение для опроса, которое могло бы послужить временным решением на данный момент — с оговоркой, что мы представим более сложное решение. когда необходимо.
Понятность
В Mind Foundry мы гордимся тем, что создаем решения ИИ, которые легко объяснимы, поэтому мы можем доверять им в приложениях с высокими ставками. Мы применяем аналогичный подход к нашему коду. Чем больше инженер-программист работает в команде, тем больше он ценит понятный код. Теперь вопрос о чистом и понятном коде может привести к всевозможным дискуссиям, которые можно расширить, процитировав множество книг. Здесь я только хочу обратить ваше внимание на то, как простота может способствовать чистоте кода. Многие профессионалы оказывались в ситуации, когда более сложное решение казалось идеальным с точки зрения хитрости, производительности или правильности. Нам по-прежнему необходимо учитывать, как наш вклад воспринимается коллегами и членами команды с разным уровнем опыта. Например, может быть заманчиво поразмыслить над внутренностями выбранной вами технологии, но если это мешает другим разработчикам понять, что вы делаете, то это не соответствует цели.
Начинайте с малого, откладывайте осложнения
Я работаю в Mind Foundry уже более трех лет и за это время усвоил много ценных уроков как в личном, так и в профессиональном плане. Один из них заключается в том, что нам нужно остерегаться чрезмерной инженерии. Это может быть заманчиво. Однако иногда лучше проявить смирение и сдержанность, выбрав сначала кажущееся более простым решение; и только когда все утрясется и система заработает исправно, тогда улучшать то, что было построено ранее. Начав с небольшого архитектурного элемента, вы также сможете лучше понять, как он взаимодействует с другими движущимися частями сложной системы.
Чтобы еще больше сжать все, что я написал до сих пор, в известной самодостаточной аббревиатуре, я процитирую один из моих любимых принципов дизайна: KISS, или Keep It Small and Simple. Эта краткая мудрость, используемая в качестве компаса и воспринимаемая с долей скептицизма, проведет вас через опасности и сложности современной техники.
Автор
Николо Андронио — старший инженер-программист полного цикла. Он занимается проектированием, обслуживанием и развитием технологических стеков, лежащих в основе нескольких продуктов MindFoundry. От пользовательского интерфейса до взаимодействия с пользователем, от оптимизации базы данных до архитектуры программного обеспечения, хранения больших данных, интеграции и развертывания кода машинного обучения, а также качества кода, внедрения передового опыта и наставничества. Он гордится тем, что знает всю систему вдоль и поперек и каждый день совершенствует ее. В свободное время он любит заниматься творчеством, создавая миры, персонажей и истории в качестве мастера игры Dungeons & Dragons.
