Подводные камни чрезмерной инженерии в разработке программного обеспечения
Излишняя инженерия - это термин, связанный с выполнением большего, чем требуется для достижения результата.
Многие инженеры, стоящие у руля разработки программного обеспечения (особенно архитекторы и дизайнеры), обычно обладают тем, что мы можем назвать сверхинженерным синдромом, когда они всегда хотят спроектировать или спроектировать вещи определенным образом. где он может легко удовлетворить потребности обозримого будущего.
Но как понять будущие потребности?
Разработчики программного обеспечения часто склонны приравнивать будущие требования к увеличению возможностей и возможностей программного обеспечения, когда оно может сделать вдвое или даже больше, чем запланировано на сегодня.
К сожалению, это происходит тогда и только тогда, когда предлагаемое программное обеспечение будет успешным и будет принято конечными пользователями в целом, что не относится к большинству программного обеспечения, существующего сегодня.
Будущие требования также определяются различными факторами, не зависящими от отдельных лиц, такими как динамика рынка, продукты конкурентов, отзывы клиентов, изменение правил и законов страны и многое другое .
Мы не можем точно предвидеть их и спланировать разработку программного обеспечения для них, поэтому мы утешаемся, думая о возможностях программного обеспечения как о знаменателе будущих улучшений.
Они нам действительно нужны?
Нет, совсем нет.
Вместо того, чтобы пытаться быть уверенными в завтрашнем дне, мы должны акцентировать внимание на текущих требованиях и на том, как выполнить эти требования наилучшим образом, а не инженерией.
Хорошо построить комнату с дополнительной вместимостью, но только если это можно сделать без чрезмерного инженерного ремонта, который нарушает структурную целостность здания
Когда будущие требования действительно изменятся, тогда исследуйте, может ли оно вписаться в текущий дизайн, если нет, выберите новый дизайн и поверьте мне, что это хорошая идея.
Если это звучит ужасно, но в качестве примера рассмотрим Empire Estate Building. Это здание было построено без учета требований к Wi-Fi, видеонаблюдению, проводке LAN и т. Д., Поскольку на тот момент их не существовало. Позже можно было добавить эти вещи, не внося изменений в здание.
Точно так же программное обеспечение предоставляет множество механизмов для улучшения существующего кода для увеличения емкости или добавления новых элементов. Однако мы будем делать это только в случае необходимости, а не на основании предварительного воображаемого ожидания.
Эффективная и быстрая доставка
Точно так же, как мы не можем дождаться пиццы или бургера в магазине быстрого питания, покупатели не будут ждать продуктов. Лучше отправить то, что для них более ценно сегодня, чем думать о том, что будет для них ценным через пару лет.
Когда великий Стив Джобс представил первый iPhone, у него даже не было возможности многозадачности. Я определенно считаю, что это решение мог принять только Стив Джобс. Он хорошо знал своих клиентов и понимал, что их текущие требования - это лучший пользовательский опыт, а не многозадачность.
Если бы это был какой-либо другой генеральный директор, он бы категорически отверг эту идею, потому что самый крупный конкурент в то время (например, NOKIA) доказал способность многозадачности.
Стив Джобс уловил неотложные требования и позже добавил возможность многозадачности. К тому времени iPhone уже был брендом.
Чтобы иметь «будущее», должно быть «настоящее».
Независимо от того, насколько надежно это программное обеспечение в будущем, если оно будет отвергнуто клиентами сегодня, вряд ли они будут рассматривать его в будущем.
Просто возьмите настоящий день, и тогда будущее вполне может оказаться наготове.
Спасибо за чтение….!!!!
Дакша
