Три вопроса, которые нужно держать в уме, создавая программы

Перевод статьи «3 questions to keep in mind when building software».

Нет неправильного пути, есть компромиссы

В разработке программного обеспечения существует интересный парадокс. Если вы сведете ПО к его сути, то увидите набор бинарных решений. Всё – либо истина, либо ложь. Но в реальности создание информационных систем редко бывает или правильным, или ошибочным.

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

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

Какую пропускную способность это дает нам?

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

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

Имейте в виду, что на этой стадии нет правильного или неправильного ответа. Вам просто нужно определить свои ожидания в отношении времени, которое, по вашему мнению, вы покупаете.

Сколько стоит реализация?

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

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

Сколько будет стоить замена?

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

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

Заключение

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


[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх