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

Rick Cook

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

Представьте, что у вас на вашем любимом автомобиле что-то сломалось или отвалилось. Точнее, то, что именно сломалось или отвалилось вы не знаете, просто автомобиль перестал выполнять свою основную функцию – возить вас из пункта “А” в пункт” Б”. Вы приезжаете в сервис-центр (на эвакуаторе), с озабоченным лицом оглашаете “сервисмену” симптомы, отдаете своего "коня" и отправляетесь ждать. Через какое-то “понятное” время (требующееся на диагностику проблемы) вам оглашают диагноз и “радуют” прогнозом на то “когда ждать выписки больного” и “сколько вам придется заплатить ветеринару”. Почему диагностика не отнимает много времени, а прогноз возможен? Да потому что во-первых: все автомобили имеют сходную конструкцию, каждая деталь которой выполняет отдельную, понятную функцию (я не про распознавание дорожных знаков и автоматическую парковку); во-вторых: то, что случилось с вашим автомобилем в 95% случаев уже случалось с другими аналогичными авто - вряд ли у нашего брата может быть какой-то эксклюзив.

К чему это я…

Если вы посетите тематические форумы по разработке программного обеспечения, то станете свидетелем невероятного многообразия возникающих у разработчиков частных проблем. Естественно, что на каждую такую проблему всегда находится решение, а зачастую и не одно…и ни один десяток, а автор вопроса, в свою очередь, выбирает то решение, которое ему ближе (читай - понятнее), но дело даже и не в этом. Проблема всегда формулируется локально – т.е. автор не уточняет в рамках решения какой подзадачи у него возникла проблема, и какую в целом задачу должен решать его гениальный код. Не уточняет, потому что не считает нужным: it is not your f…cking business, как говорится. Вы мне помогите решить “вот это”, а остальное я сам как-нибудь... В результате, человек учится тому, как средствами “голого” API по любимому всеми http протоколу хитроумно передавать описание вызова (сигнатуру) функции с параметрами на сервер и получать обратно результат ее работы. Часто в таких случаях не заботятся о безопасности, не говоря уже об отказоустойчивости и адекватной идентификации причин ошибок. Если бы проблема была описана полностью, то вопрошающему, скорее всего, посоветовали бы воспользоваться библиотеками известных производителей (например, известных всем своим стремлением сделать сложности программирования “маленькими” и “мягкими”, за что им огромный респект), потому как не стоит забывать, что если тебе в голову пришло что-то гениальное, то, с большой вероятностью, это "что-то" уже посещало голову кого-то другого до тебя…и он “этим” уже как-то распорядился.

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

Справедливо, что сравнение серийного продукта и результата разработки на заказ некорректно, но…

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

P.S.
Нужно всегда относиться с уважением к тому, что ты делаешь. Если бы кто-то собрался снимать "приквел" к фильму “матрица”, то, по моему мнению, в конце фильма к месту пришлась бы фраза: “Если вы не будете аккуратно и качественно проектировать программы, то в будущем они будут проектировать вас…”