Фреймворки, и яркий пример — Симфони, это исключительно про стандартизацию. Фреймворку всё равно что вы будете писать. Его задача, чтобы ваш код был максимально похож на то, что было бы написано кем-то другим. Это именно та архитектура, которую уже знают все кто пишет на ФВ. Когда и если вы познаете всю мудрость архитектур всех ФВ и на основе этого напишете свой собственный ФВ или супер библиотеку — они никому не будут нужны. Точнее, придется переучить миллионы программистов с Симфони на ваш ФВ.
Когда вы пишите для себя — ваша попоболь от ФВ никого не интересует. Но, когда после вас ваш код придется читать кому-то ещё, он испытает ещё большую боль от изучения вашего кода, вашего уникального и неповторимого супер оптимизированного подхода с короткими названиями методов и переменными в одну букву.
Всем уже всё равно на оптимизацию. Все уже лет 10 как поняли, что написать проект можно и быстро и дешево, и даже супер оптимально. А вот дальнейшая поддержка и модернизация этого супер оптимального кода может стать не то что очень дорогой — от работы с таким проектом программисты просто будут отказываться (На всякий случай: из-за высокой сложности. С меньшими усилиями и без ощущения боли в заднем проходе, они за то же время заработают столько же, что и с супер уникальным кодом. И очень многие согласятся заработать даже меньше предложенного, избегая этого «всем известного» стресса).
Вы все такие крутые. Вы для кого это делать собираетесь? Люди знать не знают ни про Игоря, ни про Nginx, ни про стили ошибок. Они увидят вашу охуфигуительную страницу стилизованную под ОШИБКУ и подумают — Что это ошибка!… Никто не станет кликать на вашу кнопку. Никто не станет разбирать ваш транслит серым цветом на сером фоне. С таким подходом 1% обычных людей поймут что это и для чего, остальные просто закроют вашу страницу с ошибкой.
Почему воскресенье, почему не понедельник
Почему не разместить информацию о акции/происшествии на самой странице
Почему не задать единый стиль ассоциированный с событием
Под узкоспециальные задачи или ресурсоемкие процессы легко написать микросервис, отдельного «демона» или «воркер» хоть на вашем хоть на С. При этом обвязка будет написана любым из 1000 без дополнительного обучения.
У кода не может быть проблем априори. Он написан и работает ровно так, как его написали. И у вас судя по всему нет проблем на вашем рабочем месте. И «движок» ваш крут. Проблемы возникают, когда программист либо уходит из вашего проекта или приходит к вам. В первом случае с большой долей вероятности знания о вашем «движке» можно оставить у дверей на выходе. С такой же вероятностью у вас при смене работы станет важным знать и уметь в «Симфони»(в кавычках). А нового коллегу придется учить вашему «подходу» и всем оптимальным ходам.
«То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.
Когда вы пишите для себя — ваша попоболь от ФВ никого не интересует. Но, когда после вас ваш код придется читать кому-то ещё, он испытает ещё большую боль от изучения вашего кода, вашего уникального и неповторимого супер оптимизированного подхода с короткими названиями методов и переменными в одну букву.
Всем уже всё равно на оптимизацию. Все уже лет 10 как поняли, что написать проект можно и быстро и дешево, и даже супер оптимально. А вот дальнейшая поддержка и модернизация этого супер оптимального кода может стать не то что очень дорогой — от работы с таким проектом программисты просто будут отказываться (На всякий случай: из-за высокой сложности. С меньшими усилиями и без ощущения боли в заднем проходе, они за то же время заработают столько же, что и с супер уникальным кодом. И очень многие согласятся заработать даже меньше предложенного, избегая этого «всем известного» стресса).
«То что один программист может сделать за месяц, два могут сделать за два.» — фреймворки помогают делать именно за месяц или полтора. Стремятся к этому.