Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам? S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Напоминает страдания о здоровой натуральное еде пещерных людей, в противовес современной "искусственной"
Здравствуйте, sharpman, Вы писали:
S>Здравствуйте, Poopy Joe, Вы писали:
PJ>>Напоминает страдания о здоровой натуральное еде пещерных людей, в противовес современной "искусственной"
S>Ты в макдаке питаешься? Может и детей там кормишь каждый день?
Выбирая между червяками из под камней и макдаком, я, разумеется, выберу макдак.
Точно, "карго-культ" тоже в голове крутился, но как-то упустил возможность присобачить его к своему высказыванию.
И еще одно объяснение: повлияло прогрессирующее разделение труда.
Если раньше один человек мог делать довольно крупные куски инфосистем, то нынче появились специальные должности, у которых в качестве основной должностной обязанности может быть прописано это самое "созидание сущностей". Не будут же попавшие на такую должность лица своей основной обязанностью пренебрегать!
Здравствуйте, velkin, Вы писали:
V>Читал книги про различные гибкие методологии, там авторы рассказывали как они к этому пришли. Сначала они делали всё "по учебнику", а потом у них в голове щёлкнуло, что они могут делать всё быстрее, так как знают все процессы разработки от начала и до конца.
И потом начинается — а как эта фича работает? А почему при изменениях X рухнул Y? А что у нас на проде?
Здравствуйте, sharpman, Вы писали:
S>И хвост виляет собакой. "Клиент хочет" как погоняло сраммастера. В конечном итоге, обычно, вместо хоть немного продуманной архитектуры — полный JIRAдец
Вообще-то хотелки заказчика и роль скраммастера никак не пересекаются.
Здравствуйте, L_G, Вы писали:
L_G>Можно сформулировать такой важный принцип: при необходимости лучше создать сущность более низкого порядка, чем сущность более высокого порядка.
Хороший принцип! А где ты его взял и где можно про него почитать?
Или может есть аналогии какие нибудь например из математики?
Здравствуйте, sharpman, Вы писали:
S>Вопрос к могиканам: какие действия в разработке вы рекомендуете, в противовес "современным" подходам?
S>Ведь ранее трава зеленее была однозначно, и интерфейсы статичнее... Излейте душу, перед тем, как оставить этот грешный айтимир! Аминь
Современные подходы лучше, т.к. не отменяют "старые", а расширяют и дополняют, растягивая треугольник "быстро, дешево, качественно". Т.е. быстро и некачественно можно делать дешевле, ибо фреймворки. Для "дешево и качественно" появился опнсорс, ускоряющий тестирование. "быстро и качественно" тоже эволюционирует серьезными темпами.
Хайпожорство и поиск авторитетов вместо использования собственной головы — это возрастное и лечится только с опытом.
DP>Хороший принцип! А где ты его взял и где можно про него почитать?
Боюсь, что сам придумал, непосредственно в процессе написания того поста.
Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него).
Если создание любой сущности — зло, то (при необходимости совершить это действие, но возможности выбора в неких рамках) лучше совершить меньшее зло, нежели большее.
К мысли подтолкнула, среди прочего, работа с легаси-кодом с признаками массивного оверинжиниринга.
Здравствуйте, L_G, Вы писали:
DP>>Хороший принцип! А где ты его взял и где можно про него почитать?
L_G>Боюсь, что сам придумал, непосредственно в процессе написания того поста. L_G>Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него). L_G>Если создание любой сущности — зло, то (при необходимости совершить это действие, но возможности выбора в неких рамках) лучше совершить меньшее зло, нежели большее. L_G>К мысли подтолкнула, среди прочего, работа с легаси-кодом с признаками массивного оверинжиниринга.
Не создавать лишнюю функцию, фигачить все одну, чтобы не плодить сущности...
Здравствуйте, L_G, Вы писали:
DP>>Хороший принцип! А где ты его взял и где можно про него почитать?
L_G>Боюсь, что сам придумал, непосредственно в процессе написания того поста. L_G>Но это просто расширение принципа "бритвы Оккама" (или очевидное следствие из него).
+1 да, наверно это Оккама
еще напоминает Дэвид Уилер "We can solve any problem by introducing an extra level of indirection." "... except for the problem of too many levels of indirection"
Или как его часто переиначивают "любую архитектурную проблему можно решить добавлением дополнительного слоя абстракции, кроме проблемы большого количества абстракций"
PJ>Не создавать лишнюю функцию, фигачить все одну, чтобы не плодить сущности...
Ты сам написал слово "лишнюю", и оно здесь ключевое.
Необходимость отдельной функции, в том числе, может определять принцип DRY. Also SRP, etc.
Еще, например, соблюдение принципа самодокументирующегося кода может привести к замене комментария в середине большой функции на выделение в отдельную функцию кода, к которому относился комментарий, и назначении этой функции такого имени, что комментарий становится излишним. Лично я —
за такой подход.
Здравствуйте, sharpman, Вы писали:
S>Самый лучший способ довести что-то до абсурда, это применять это без обдумывания. S>Лучше на основе бюрократических процедур.
S>Как и вышло с аджайлом. Сейчас уже не обьяснить, что аджаил родился совсем не таким, и S>только благодаря припадочным рукойводителям он стал истеричным и шизофреничным
Это да. Вот, например, в предыдущей конторе, где я работал был у нас проект с одним из клиентов.
Сначала взялось за этот проект прогрессивное поколение со своими аджайлами, скрамами, хермесами и прочими модными словечками.
Сначала одна команда помыкалась — все в говне оказалось, потом другая команда пришла и сказала, что предыдущие забыла использовать TOGAF, поэтому все так плохо выглядит.
Ладно, взялись они и тоже все в итоге сдохло.
Потом пришла команда со "старичками", которые все эти модные процессы и словечки не знали. Сделали все как надо и все заработало как надо.
Вот к сожалению это и получается так, что понапридумывали умные дядьки хорошие процесса, а всякие эффективные менеджеры их переложили под себя совершенно не понимая, что они делают и как.
В итоге полный хаос и заваленные проекты. А если проекты не завалили, то зачастую, потому что люди, которые "внизу" работали не по процессами, которые им были предписаны, а просто нормально работали.
Потом менеджерам премии за успешный проект, а тем кто ниже — "нихера".
Здравствуйте, sharpman, Вы писали:
L>>Странно. TDD, который мне доводилось использовать, серьезно помогает делать изменения в программе. S>Ты, наверное, путаешь с юнит-тестами
