sacryfice: ваша библиотека решает вопросы логирования? Нет? Значит и не должна. Принцип единой ответственности и все такое.
Скажем в chrome debug tools есть панелька для отладки промисов. Я же например использую промисы с async/await и у меня все эксепшены вылетают наружу. И я не хочу что бы кто-то решал за меня хочу я что бы ошибки валились в консоль или нет и каким образом это будет происходить.
Oxoron: я ничего не говорил про паттерны, я считаю что новичкам их учить опасно ибо они будут пихать их куда не попадя. Они сами собой будут выходить если постич базовые принципы.
И да, SOLID - это не методика, это принципы, следуя которым мы снижаем связанность и увеличиваем поддерживаемость. Знания фреймворка не помогут сделать проект поддерживаемым. Понимание принципов же - помогут.
Принципы SOLID появились в том или ином виде 40 лет назад, когда небыло еще ООП. Инверсию зависимостей придумали еще в 60-ых. Инкапсуляция, наследование, полиморфизм - все это можно делать и без ООП.
Знать что такое инкапсуляция без осознания того, зачем оно надо - это пустое. Почему люди решили изолировать ввод/вывод от обработки данных, почему ввели систему абстракций аля .NET, почему это важно и когда можно на это забить. Все это можно вполне себе совмещать с изучением фреймворков, но внимание должно быть сконцентрировано на важных вещах.
И да, мой поинт в том что бы человек не бездумно кодил а понимал что он делает и зачем. ООП или нет - не столь важно. Пусть человек узнает про TDD, про рефакторинг и т.д. Пусть использует тесты для обучения (реально помогает). Ну и т.д.
Если же человек сразу начнет кодить то обратит внимание он на фундаментальные знания только после того как зафакапит парочку проектов.
sacryfice: вот теперь понятно что вы хотите. Но...
во внутренней функции же исключения не происходит, зачем там что-то отлавливать? Ошибка произошла то не внутри ВАШЕЙ библиотеки, а на стороне пользователя. Ваша библиотека знать ничего не должна о ошибках во вне.
Поясните откуда появилась такая необходимость, и можно будет попробовать придумать вариант лучше.
Максим Иванов: что бы поучиться писать. Повторюсь, свои системы пишите пожалуйста для себя, а когда напишитесь своих да хотя бы пару лет с существующими поработаете, да опыта побольше наберетесь (что бы ясно представлять что такое хорошо, что не так хорошо и чего не хватает существующим системам что бы быть круче) - вот тогда вперед и с песней.
Один человек не в состоянии написать и поддерживать CMS, которая будет адекватна как для пользователя так и для разработчика. Обычно этим занимается целая команда на фултайме и за деньги. И чуваки обычно эти весьма опытны.
Wordpress такой какой он есть не потому что "так надо", а потому что на момент написания по другому бы и не вышло (давно это было). Сейчас же никто ничего с этим делать не хочет потому что... обратная совместимость с миллионами плагинов.
Oxoron: да я как бы знаю "опытных" людей с 8+ годами стажа которые все так же пописывают говнокодец потому что придерживались этой идеи что знать надо язык и фреймворки. Потому что их не отучили в детстве так сказать.
Что до легаси - легаси это когда коду пара лет, а говнокод это говнокод.
Мой поинт в том что фреймворк, как и язык программирования, это только инструмент. Инструменты надо знать что бы ими пользоваться. А если у тебя есть еще и фундаментальные знания какие-то то изучать эти инструменты становится намного проще.
Говнокод это нормально. Без него никуда. Просто без основ ООП, а точнее понимания принципов и т.д. у разработчика не удастся вымыть руки после написания оного и весь проект измажет. Everybody poops by usually doing it in one place, или "говнокод это хорошо когда он закрыт красивым интерфейсом".
Причем самое обидное что принципы эти можно изучить за пару недель... но я встречал людей которые за 10+ лет все еще не поняли что такое принцип единой ответственности и зачем оно надо.
Alexander Lashchevsky: это отличный вариант если он работает и позволяет быстро запилить такой сайт.
Поймите, все сводится к балансу между быстро и качественно. Есть проекты где написание всего с нуля оправдано (написание своего шаблонизатора я оправдать не могу никак), но это опять же не совсем с нуля. Большая часть инфраструктуры (библиотеки для работы с базами данных, с формами, фреймворки целые) берутся готовыми что бы сократить итоговую стоимость. Но это оправдано только в том случае, если проект планирует дальнейшее развитие функционала, причем очень активное. Можно взять wordpress и очень быстро сделать рабочий продукт, но добавлять в него какой-то специфичный функционал, поддерживать при определенном ритме жизни проекта может стать дороже, чем написать все с нуля.
Задача разработчика - предоставить клиенту вариант оптимальный для его задачи. То есть если человеку нужен сайт-визитка - то лучше взять wordpress (или аналоги). А если человеку нужно поднять сервис электронной продажи билетов, и при этом это сейчас концентрируются на театрах а в планах потом продавать билеты под все - тут уже лучше написать на фреймворке все с нуля.
ну тут все не так просто. "поменьше возиться" означает "сделать дешевле", что вполне себе понятная потребность. И у разработчика такое желание так же должно быть. Использование готовых и проверенных инструментов это пожалуй самый простой вариант скоращения рисков для заказчика, и делать специалить ситуацию при которой развитие системы встанет дорого - это ИМХО плохая услуга и за это можно спокойно попасть в черные списки.
Но мысль "все должно быть на wordpress" дикая, я надеюсь что ее думали не буквально.
Oxoron: потом приходится поддерживать код таких вот чуваков и просто плачешь...
Вы же понимаете что потом реальных проект такому знатоку языка и фреймворков не даш, он сможет решать только типовые проблемы, даш что-то с чем человек не сталкивался или задачу посложнее и все, пиши пропало.
TDD например новичкам как раз полезно, а опытным чувакам пользы уже меньше относительно.
Tsiren Naimanov: читая книги по .NET читатель не сможет разобраться что такое инкапсуляция. Даже если вскользь упомянут зачем это надо, фокус внимания читателя будет смещен на посторонние вещи.
Опять же, я могу судить по людям с которыми мне доводилось общаться, которые по причине того что читали только статьи/книги под какие-то фреймворки где что-то всего-лишь упоминалось вскользь (потому что автор книги предполагал что читатель уже ознакомлен с этими понятиями) лишены понимания того, почему все организовано так а не иначе. Допустим мой любимый пример когда люди не понимают в чем разница между инверсией зависимости и внедрением зависимостей. У людей эти понятия перемешаны.
По поводу "гуглить" - таки да, гуглить полезно. Но что гуглить - вот вопрос. Так же можно опять же случайно сместит фокус внимания на посторонние вещи (у меня так было с BDD помниться, потому что когда я о нем узнал из нагугленной статьи автор оной сместил мое внимание к вопросу регрессионного тестирования и рефакторинга, и суть я упустил)
С другой стороны существует масса достойной классики, есть принципы SOLID (которым по сути уже лет 40 и они не теряют актуальности, а все остальные вещи вытекают из них), GRASP паттерны, GoF паттерны... А тут предлагают почитать книжки по .NET, типа "нафиг тебе фундаментальные знания, лучше учи конкретный стэк технлогий"
Deliaz: пф... у меня и по 100 мегабайт набегает, ничего страшного когда окружение к проекту отжирает полтора гига. Вы же не храните это все в своем git.
