Простые и сложные решения
В мире программирования каждое техническое решение — это баланс между удобством сейчас и возможностями в будущем. Это особенно очевидно на примере двух систем кодирования символов: ASCII и Unicode. Их сравнение ярко демонстрирует, как выбор между текущим удобством и будущими возможностями может влиять на разработку программного обеспечения и обработку данных.
Простота ASCII обусловила ее широкое распространение: малый размер кодировки упрощает обработку и хранение текста, особенно в условиях ограниченных вычислительных ресурсов прошлого. Однако основное ограничение ASCII — ее неспособность представлять символы за пределами английского языка.
Unicode представляет собой систему кодирования, разработанную для решения ограничений ASCII. Она включает в себя символы почти всех письменных языков мира, а также множество других символов, включая эмодзи. Unicode поддерживает несколько форматов кодирования (например, UTF-8, UTF-16), что позволяет эффективно использовать место в зависимости от конкретных нужд. Переход на Unicode открывает огромные возможности для создания глобального ПО. Однако это также влечет за собой увеличение сложности: разработчикам приходится учитывать большее разнообразие символов и особенности их отображения и обработки в программах.
Другой пример — допустим, в нашей компании мы используем небольшого бота на Python, который обеспечивает менеджерам легкий просмотр отчетности по данным из БД. Пока приложение используют с десяток человек, ничто не мешает нам сделать все методы, реализующие запросы синхронными. Такая модель проста и понятна в использовании. Но что если количество пользователей сильно возрастет? Или запросы на отчеты могут выполняться продолжительное время и блокировать остальные? Создав бота сразу с использованием асинхронных методов (или даже тредов), мы решим все эти проблемы заранее, и наше приложение будет готово к безполезненному расширению для использования. Но опять таки, в данный конкретный момент, мы теряем удобство. Асинхронный код имеет свойство “расползаться” по проекту, заставляя превращать все методы, которые так или иначе касаются асинхронности в такие же асинхронные. И наша способность легко представлять, что происходит в приложении в каждый конкретный момент также сильно ослабевает.
Выбор компромисса
Дело в том, что практический любой выбор используемой технологии в программировании подразумевает некий компромисс между удобством и возможностями. Использовать богатство системы типов Rust или простоту и прямолинейность Go. Разрабатывать приложение на языке с статической типизацией или сделать быстрый прототип на Python. Любой технической команде нужно всегда балансировать между этими двумя противоположностями. Причем, этот выбор зачастую представляет собой скорее спектр, или даже “решетку”, где каждое решение это компромисс между определенной долей новых возможностей за потрерю удобства использования.
Выбирая всегда самый удобный вариант, наша система быстро станет очень “хрупкой” - когда любое значительное изменение повлечен за собой необходимость прилаживать “костыли”, переписывать большие куски приложения и постепенному росту технического долга. Но и просто всегда выбирать самый предусмотрительный вариант тоже невозможно, особенно в условиях работы с людьми, чьи доходы зависят от нашего ПО. В погоне за фичами легко пропустить дедлайны, или усложить проект до степени, когда с ним тяжело работать другим программистам. Клиента сложно убедить, что ему лучше потратить время сейчас, чтобы получить более поддерживаемый и расширяемый продукт в будущем, ведь потеря времени для него это потеря денег. Поэтому
Выводы
Главное, что можно вынести из этих размышлений, своего рода циклическая зависимость между сложностью и удобствами. Чем больше в систему “встроено” возможностей, которые могут сделать её создание менее удобной, тем зато больше этих “бесплантых” горизонтов открывается впоследствии. Мы можем “купить” будущее удобство, прикладывая больших усилий в настоящий момент. В конце концов, при размышлении о дизайна проекта, нам нужно планировать, на каком компромиссе мы остановимся в отношении между “удобством” - “возможнстью” системы.