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

R>Или можно реализовать на production мониториг, логирование, резервирование и другие удобные для эксплуатации вещи, а не блистать интеллектом, там, где можно обойтись кувалдой.

ыхыхы
я-то согласен что всё это надо делать
но все ли разработчики это реализовали в уже существующих проектах?


R>Ну, а если заказчик уперся и не позволяет все это сделать — пусть платит за искусственно созданные неудобства (или парит мозги другим исполнителям). Если у тебя нет возможности выбора работодателя, тогда, конечно, придется работать на условиях заказчика (напрягать недюженный интеллект), но, IMHO, это не повод для гордости.

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


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

до 2005 года я вообще не знал такого выражения "паттерны проектирования", хотя открыл часть из них самостоятельно
потом лет 8 их спрашивали на собесах, я иногда их применял осознанно, поскольку готовился
сейчас их у меня почти не спрашивают, я их и забыл (бегло повторяю несколько наиболее одиозных перед собесами)
не особенно-то и жалею

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

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

R>Или можно реализовать на production мониториг, логирование, резервирование и другие удобные для эксплуатации вещи, а не блистать интеллектом, там, где можно обойтись кувалдой.

ыхыхы
я-то согласен что всё это надо делать
но все ли разработчики это реализовали в уже существующих проектах?


R>Ну, а если заказчик уперся и не позволяет все это сделать — пусть платит за искусственно созданные неудобства (или парит мозги другим исполнителям). Если у тебя нет возможности выбора работодателя, тогда, конечно, придется работать на условиях заказчика (напрягать недюженный интеллект), но, IMHO, это не повод для гордости.

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


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

до 2005 года я вообще не знал такого выражения "паттерны проектирования", хотя открыл часть из них самостоятельно
потом лет 8 их спрашивали на собесах, я иногда их применял осознанно, поскольку готовился
сейчас их у меня почти не спрашивают, я их и забыл (бегло повторяю несколько наиболее одиозных перед собесами)
не особенно-то и жалею

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