Думаем, каждый согласится, что хорошо продуманную программу легче делать, легче расширять, легче тестировать; в двух словах «легче сопровождать». Простота — залог успеха. Приложение, сделанное или делающееся на скорую руку, может «умереть» от рук своих отцов если не в процессе разработки, то уже в ближайшее время после релиза, это точно!
Если приложение нацелено на работу с БД, то проектирование структуры БД является довольно важным шагом. Плохая продуманность сущностей и их отношений, процедур, функций и других объектов, может послужить большим тормозом при расширении задачи в будущем. Фактически, хорошо спроектированная БД — половина программы + экономия времени (следовательно, и денег) в будущем. Качество прямо пропорционально затраченному времени. Как говорят «Долго запрягали, да быстро ехали». Лучше потратить день, а то и два, и три (бывает, и больше), и не сделать физически ничего, но, при этом, провертеть у себя в голове разные варианты решения поставленной задачи (при этом, лучше каждый вариант запротоколировать, будет хорошим руководством в будущем и опять экономией времени для коллег). При этом, учесть плюсы и минусы каждого варианта. Постараться заглянуть вперед и оценить предлагаемое решение, понять хорошо ли оно будет работать в будущем, а не только сейчас (то есть, расширяемо ли оно, и не станет ли сковывать систему). Выполнить этакую оптимизацию из множества возможных способов.
Кстати, правильно поставленная задача также считается необходимым условием для успешного выполнения проектирования. Смотрите портфолио ВолгаПромПроект. Желательно, иметь полный расклад по предметной области. Как ни крути, но лучший программный продукт получится лишь тогда, когда разработчик ориентируется в предметной области, как рыба в воде. Конечно, времени всегда мало. Работодатель может давить на мозги, стоять над душой, заставляя, при этом, нервничать. Очень плохо, когда такое происходит. С уверенностью можно сказать, что такая программа будет иметь довольно много ошибок и много нареканий со стороны пользователей.
По работе приходилось несколько раз переписывать старый софт (из-под DOS в Windows). В довесок к программному коду, также приходилось переделывать либо разрабатывать новую структуру БД, так как старая схема оставляла желать лучшего. Конечно, вопрос о переносе данных из старой базы в новую, в этом случае, так и оставался под вопросом. Мало того, что сама схема была плохо нормализованной, так еще и сами данные не отвечали целостности.
А теперь представьте себе, что может произойти при рефакторинге типов полей; при изменении FLOAT на DECIMAL. В старом варианте могут содержаться значения с огромным колом чисел после запятой. Хотя, по условию (согласно техническому заданию) надо хранить лишь два знака после запятой. Таким образом, вы выставляете DECIMAL и в результате может получиться так, что при формировании новых отчетов на старых данных, вы получите совсем другие цифры! Пользователи будут недовольны! И этого следовало ожидать. Ошибки, заложенные в архитектуру на ранней стадии, трудно исправить, либо вообще не желательно исправлять в будущем.
Несколько слов об архитектуре проектирования
