Автор: Эндрю Сардон
вице-президент по инженерным вопросам, Nutshell

В информатике есть две серьезные проблемы: недействительность кеша, присвоение имен объектам и единичные ошибки. - Леон Бамбрик

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

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

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

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

Хотя Брукс имел в виду сложность и то, как она связана с созданием и изменением кода, это применимо и к конечному продукту.

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

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

Ваш код - это ваша организация

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

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

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

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

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

Нет места героям

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

Иногда в команде бывает одна рок-звезда, которая, когда что-то ломается, говорит: «Как бы то ни было, я просто пойду починю». Это обычная динамика для многих команд разработчиков программного обеспечения, но наличие таких очагов поклонения героям может быть очень вредным для обмена знаниями.

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

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

Сила концентрации

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

Но самое важное, что мы делаем, - это просто сужаемся до самого важного.

Как заметил Фред Брукс, существенная сложность создается, когда пользователь говорит, что есть 30 вещей, которые программа должна сделать, и нет никакого способа обойти это. Но я бы сказал: ну, как мы можем сократить список до 30 функций, которые действительно необходимы?

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

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

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

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

Сужение того, что вы пытаетесь сделать, позволит вам улучшить то, что имеет значение, и приложить правильные усилия для уменьшения сложности. Это не просто «хорошо иметь» в хорошем программном обеспечении, это важно.

Эта история опубликована в The Startup, крупнейшем предпринимательском издании Medium, за которым следят более 271 813 человек.

Подпишитесь, чтобы получать наши главные новости здесь.