Архитектура программ и прибыль

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

Задача архитектора – создать архитектуру достаточно гибкую и модифицируемую, но не чрезмерно гибкую. Обе границы гибкости грозят проблемами и неприятностями.

Слишком жесткая архитектура будет дорого стоить при модификации (тут мы сильно отличаемся от строителей – в программы часто требуется добавлять новую функциональность). Например, наша программа берет данные из MS Excel 2007. Все работало замечательно, пока не вышла версия MS Excel 2010. Конечно, заказчик хочет добавить в систему поддержку новой версии и вот тут его и ждет сюрприз. Архитектор системы настолько жестко привязался к бинарному формату версии 2007, что для поддержки XML формата версии 2010 требуется фактически переписать всю систему заново. И цена этой работы получится соответствующая – как минимум больше половины стоимости исходной работы. Я думаю, вы будете примерно также удивлены, если вам скажут, что на вашу машину не ставятся зимние шипованные колеса и для того, чтобы можно было ездить зимой, нужно поменять всю машину или, как минимум, кузов и привода. "Кое-что из приборов и руль, наверное, получится не трогать, но остальное точно под замену", ‑ уверенно сообщает вам мастер на авто-сервисе.

Обратный вариант – слишком гибкая архитектура – тоже ничем хорошим не светит. Вы просили сделать вам автомобиль, а получили самолет-амфибию с возможностью ездить по дорогам. Ну т.е. ездить он, конечно, может. Но вот цена… ну и еще – чтобы по дорогам ехать нужно "немного сконфигурировать систему" – колеса привинтить, крылья отвинтить. "Не сложно, не переживайте, да и инструкция же есть. Да, вы этого не просили, но нам так было удобнее – вот будут у нас другие клиенты, а у нас уже готовы и самолет и корабль. Правда, нужно их немного доработать…" Хотя конечно, уверенности что новые клиенты будут, нет. С таким-то подходом… Меня очень напрягают программы, которые для своей работы требуют от меня совершенно не нужных мне действий, но это немного другой разговор, до него мы еще доберемся. Пока же я думаю, основную идею вы поняли – слишком гибко тоже плохо. Обычно это дорого и неудобно.

Хорошая архитектура – где-то посередине. Достаточно гибко, чтобы можно было модифицировать, но в рамках разумной гибкости, чтобы не было дорого и было удобно. Как это влияет на прибыль, наверное, очевидно.