Только реализован в стандартной библиотеке, и узнать об этом можно только забравшись в исходники. Чего, увы, многие никогда не делают (именно стандартную библиотеку).
Кстати, у Макконнелла в 1000 страниц не так уж много повторений.
Зато мне нравится четкая структура, когда каждый оператор рассматривается отдельно. Так даже для запонимания удобнее.
Ревью кода себя окупает, и быстро начинает приносить прибыль.
Лишь малая часть этой прибыли — улучшение того кода, для которого проводится ревью.
Чуть большая часть — это уменьшение подобных ошибок у всех, кто участвовал в разборе.
И, наконец, самая ощутимая часть — то, что разработчики начинают внимательнее относиться к коду, и начинают находить не только рассмотренные ошибки, а также и другие проблемные места. А повышение квалификации разработчиков сильно влияет на качество проекта в перспективе.
Если честно, то паттерны открывают новые абстракции, которые можно комбинировать между собой и с уже имеющимся опытом. Без опыта работы изучение паттернов скорее вредно, чем полезно.
А вообще не изучать паттерны — тоже плохо, т.к. самому приходится долго искать подобное решение. Помню, до чтения паттернов я как-то изобрел «Фабричный метод». И ушло у меня на это часа 4.
Просто использовать устоявшиеся названия паттернов проще, чем объяснять решение на пальцах. Да и слыша такое модель сразу в голове выстраивается, все дальнейшее изложение становится лишним.
Если же каждый раз объяснять детально, тратится довольно много времени, плюс есть риск что-то забыть.
P.S. А вот в случае, когда говорят об MVC, а по факту модели-то там и нет — это уже необразованность вида «слышу звон, не знаю, где он». Здесь необходимо проводить просвещение. Все паттерны имеют строго заданную структуру и поведение, поэтому любое отклонение должно быть явно озвучено.
Например, в Java после добавления полноценных Enum'ов надобность в switch остается разве что при работе с внешним интерфейсом по кодам или при парсинге. И даже в этих случаях Enum может быть элегантнее switch'а.
Согласен, книга переворачивает мышление в нужную сторону :-)
Вот только перед ее прочтением необходимо хотя бы в парочке разных проектов поучаствовать, чтобы почувствовать разный код и разные подходы на собственной шкуре. Иначе это разговор о сферических конях в вакууме.
fixed.
Мне лично слабо верится, что методы длиной >10000 строк нельзя декомпозировать, сделав код более читабельным.
Хотя и ненаглядно, т.к. метка ставится перед началом цикла, а переход происходит в его конец.
В наших компаниях все равно найдут козла отпущения и уволят :-)
Зато мне нравится четкая структура, когда каждый оператор рассматривается отдельно. Так даже для запонимания удобнее.
Так что и здесь «слепить как попало» — не лучший вариант.
Лишь малая часть этой прибыли — улучшение того кода, для которого проводится ревью.
Чуть большая часть — это уменьшение подобных ошибок у всех, кто участвовал в разборе.
И, наконец, самая ощутимая часть — то, что разработчики начинают внимательнее относиться к коду, и начинают находить не только рассмотренные ошибки, а также и другие проблемные места. А повышение квалификации разработчиков сильно влияет на качество проекта в перспективе.
А вообще не изучать паттерны — тоже плохо, т.к. самому приходится долго искать подобное решение. Помню, до чтения паттернов я как-то изобрел «Фабричный метод». И ушло у меня на это часа 4.
Если же каждый раз объяснять детально, тратится довольно много времени, плюс есть риск что-то забыть.
P.S. А вот в случае, когда говорят об MVC, а по факту модели-то там и нет — это уже необразованность вида «слышу звон, не знаю, где он». Здесь необходимо проводить просвещение. Все паттерны имеют строго заданную структуру и поведение, поэтому любое отклонение должно быть явно озвучено.
Вот только перед ее прочтением необходимо хотя бы в парочке разных проектов поучаствовать, чтобы почувствовать разный код и разные подходы на собственной шкуре. Иначе это разговор о сферических конях в вакууме.
P.S. Для сложных задач 66 может быть довольно разумной цифрой, но правил вида «никогда не делайте то-то», как правило, больше одного.