Дизайн приложения на 5 лет

«Самое большое препятствие на пути к отличному плану — это мечта об идеальном плане».

Я согласен с тем, что разработка идеальной системы, элегантно устойчивой ко всем возможным будущим изменениям, бесполезна. Каждый успешный проект — это компромисс: создание гибкости там, где вы уверены, что она понадобится (или там, где это легко сделать в любом случае); и создание несколько быстрого и грязного кода, где вы считаете, что гибкость/изменение маловероятны. Если вы хорошо проанализируете систему и у клиента есть хорошее представление о своих потребностях/требованиях (не всегда заданных), вы получите правильный баланс, по крайней мере, большую часть времени.

Однако представление о том, что вся система будет каждые 3-5 лет заменяться какой-то более новой технологией, также является заблуждением. На каждого клиента, который хочет новейшую, новейшую, самую привлекательную систему, приходится 5 клиентов, которые боятся расстаться (или не могут позволить себе заменить) свою устаревшую систему COM/VB/MS-Access или любую другую систему, представляющую собой болото спагетти-логики. построены бессистемно без учета удобства обслуживания, гибкости или расширяемости. Вы не хотите быть тем, кто строит эту систему; если да, то вы оказываете своему клиенту/работодателю медвежью услугу.

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

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

Я работал в двух разных компаниях, у которых были программные продукты, которым около 10+ лет. Несмотря на то, что они были расширены множеством новых функций и претерпели множество косметических изменений, ядро ​​приложения практически не изменилось с момента выхода первого стабильного выпуска. Это может быть нетипично, но если архитектор достаточно опытен, система может быть построена модульной и достаточно расширяемой, чтобы обеспечить неожиданный рост.

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

Я имею в виду, что существует множество приложений, языков и шаблонов проектирования, которые думали об одном и том же и все еще используются сегодня. Мне в голову приходит ошибка 2000 года. Программисты 70-х никогда не думали, что их код будет работать 30 лет, и наверняка кто-то расширит эти значения года до 4 чисел до начала века. Мы все помним, чем закончилось это мышление...

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

Некоторые испытанные принципы, которые остаются сильными и по сей день, — это, например, нормализация базы данных, модульность кода и т. д. и т. д.

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

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

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

Данные и структуры данных (часто) должны быть законно спроектированы так, чтобы их можно было использовать десятилетиями. Ожидается, что алгоритмы, пользовательский интерфейс и все остальное будут быстро развиваться.

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

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

Я помню цитату Джеймса Ковача, кажется, в одном из подкастов .Net Rocks, где он описал нашу индустрию так:

тот, где единственная константа - это изменение

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

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

Что ж, я думаю, что идеальный дизайн полностью ортогонален, но вы просто должны признать, что он редко работает так, как вы себе представляете. Если вы никогда не читали «Прагматичного программиста», в нем много говорится о том, как защитить свой код в будущем.