Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

Рассмотрим ситуации :

1 менеджмет-код
2 менеджмент-говнокод
3 говноменджмент-код
4 говноменджмент-говнокод

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


остается устойчивых 2 ситуации 1 и 2.

Вопрос возможно риторический, но все же.
Так что на ваш взгляд первичнее менеджмент или код ?

т.е.
получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

А>остается устойчивых 2 ситуации 1 и 2.

Очепятка, устойчивые 1 и 4.

Здравствуйте, Аноним, Вы писали:

А>...

Никто не даст точного определения, что же такое говнокод и говноменеджмент.

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Аноним, Вы писали:

А>>...

O>Никто не даст точного определения, что же такое говнокод и говноменеджмент.

Если мое мнение то
определение факта наличия говнокода зависит от проекта, у кода могут быть такие свойства как "читаемость", "тестируемость", "гибкость" и т.д. у каждого свойства есть цена, все требует трудозатрат.

с другой стороны есть затраты которые возникают если данных свойств у проекта не будет.
вот если нарисовать 2 таких кривые, то точка пересечения — оптимум укажет какие свойства у кода избыточны или наоборот требуются.
Так вот говнокодом будет код в котором много избыточных свойств или наоборот мало требуемых.


пара примеров ( ситуаций в жизни больше )

например если проект краткосрочный, одноразовый, поддержка не подразумевается, то говнокодом будет являться код который
1) пишется дольше обычного, вводятся лишние сущности/слои которые не пригодятся

если же проект например большой и долгосрочный, то говнокодом будет является код
1) плохо читаемый, плохо документированный
2) отсуствие архитектуры позволяющей осуществлять unit-тестирование
в общем который будет приводить к убыткам.


Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

Не помню уж кто сказал, что структура кода отражает структуру организации.
Склонен с этим мнением согласиться.

Все намного проще — хорошо делаешь только для себя. Это относится к любому виду деятельности, не только к программированию.

Первичны 2 персонажа: основатель компании и заказчик(и). Они, согласитесь, очень сильно влияют на то, имеет ли шанс развится говнокод/говноменеджмент и прочие занятные вещи.

Здравствуйте, Аноним, Вы писали:

А>пара примеров ( ситуаций в жизни больше )

А>например если проект краткосрочный, одноразовый, поддержка не подразумевается, то говнокодом будет являться код который
А>1) пишется дольше обычного, вводятся лишние сущности/слои которые не пригодятся

А>если же проект например большой и долгосрочный, то говнокодом будет является код
А>1) плохо читаемый, плохо документированный
А>2) отсуствие архитектуры позволяющей осуществлять unit-тестирование
А>в общем который будет приводить к убыткам.

Хм. Я как-то рассуждал вслух о чем-то подобном — http://www.rsdn.ru/forum/flame.comp/4424831.flat.aspx

Автор: okman
Дата: 17.09.11

Суть в том, что код не может оцениваться изолированно, сам по себе, а должен рассматриваться в
контексте целей, которые преследует разработка.

А>Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
А>Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
А>Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
Вопрос — хреновый это менеджмент или нет ?

Здравствуйте, okman, Вы писали:

O>Здравствуйте, Аноним, Вы писали:

А>>пара примеров ( ситуаций в жизни больше )

А>>например если проект краткосрочный, одноразовый, поддержка не подразумевается, то говнокодом будет являться код который
А>>1) пишется дольше обычного, вводятся лишние сущности/слои которые не пригодятся

А>>если же проект например большой и долгосрочный, то говнокодом будет является код
А>>1) плохо читаемый, плохо документированный
А>>2) отсуствие архитектуры позволяющей осуществлять unit-тестирование
А>>в общем который будет приводить к убыткам.

O>Хм. Я как-то рассуждал вслух о чем-то подобном — http://www.rsdn.ru/forum/flame.comp/4424831.flat.aspx

Автор: okman
Дата: 17.09.11

O>Суть в том, что код не может оцениваться изолированно, сам по себе, а должен рассматриваться в
O>контексте целей, которые преследует разработка.

А>>Что касается говноменеджмента, то мое мнение что говнокод есть следствие говноменеджмента. Когда нет четких требований к "свойствам" кода, нет контроля за соблюдением данных свойств.
А>>Таким образом систематический говнокод является лакмусовой бумажкой для определения говноменеджмента.
А>>Проект содержит не только код, множество других артефактов, но о них мы тут не говорим.

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

Ну тут условия задачи не полные , поэтому ответ собственно очевиден в двух вариантах,
если кусок хлеба не зависит от качества проекта, т.е. целью становится сделать нечто разовое, за короткий срок, и дальше будет гарантированная прибыль. То это подходит к случаю 1) , т.е. в данном случае свойства кода минимальны должны быть, максимально функционально по ТЗ.

Но есть и обратная сторона медали, если после того как кусок хлеба будет получен и нужно будет сопровождать проект, то конечные затраты из-за отсуствия нужных свойств кода могут вылиться в то что придется отдать 2 куска хлеба за то чтобы это поддерживать, если изначально условия такие , то лучше остаться с 0 куском хлеба и найти другой проект, чем потратить N лет и в конечном счете лишиться куска.
Тогда п2 будет хреновым менеджментом.

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?
А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

Это очень актуальный для меня вопрос. По своему печальному опыту могу сказать, что говноменеджмент, конечно же, первичен.

У меня в проекте было так, что говноменеджер на протяжении нескольких лет делал следующее:

1) так умудрялся давать задания и устанавливать сроки, чтобы ни одна задача не была сделана как следует, не второпях и не в виде "залепухи". Естественно, чем дальше, тем становилось хуже, так как проблемы и баги в коде только накапливались, но о причинах увеличения сроков на выполнение заданий говноменеджеру объяснять было, естественно, бесполезно;

2) тестирование говноменеджер необходимым не считал, то есть тестирования фактически не было. Естественно, в коде копились целые "системы" багов, компенсирующие друг друга, и при попытке фикса одного бага, часто при решении несвязанной задачи, программист неожиданно получал сразу несколько ужасных багов в разных местах;

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

Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.

Здравствуйте, okman, Вы писали:

O>Рассмотрите такую ситуацию — есть две конторы, конкурирующие за какой-нибудь госзаказ и
O>инвестиции в будущем. Первая делает свой продукт добротно, по канонам, вторая стремится обогнать
O>конкурента и побыстрее выпустить рабочую версию, жертвуя качеством. В результате получается
O>баганутый код, где-то непричесанный, где-то просто ужасный, но в конечном итоге цель достигается и
O>вторая контора получает таки заказ, обеспечивая себя куском хлеба на пяток лет.
O>Вопрос — хреновый это менеджмент или нет ?

нет, но и приёмка хреновая

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Рассмотрим ситуации :

А>1 менеджмет-код
А>2 менеджмент-говнокод
А>3 говноменджмент-код
А>4 говноменджмент-говнокод

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


А>остается устойчивых 2 ситуации 1 и 2.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?

А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

Доктор ТуамОсес: "Ты хоть сам-то понял, что написал? "

Здравствуйте, Аноним, Вы писали:
А>Рассмотрим ситуации :
А>1 менеджмет-код
А>4 говноменджмент-говнокод

Вообще есть еще такие вещи как внешнее и внутреннее качество продукта. Внешние качество продукта имеет явные и очевидные метрики. Внутреннее качество очевидных метрик не имеет, но одна из важнейших на мой взгляд это скорость модификации кода и количество багов, которые всплыли в результате нового кода из-за ошибок в старом. Эту ошибку можно было бы получить и без нового кода, но не было такого кейса.
Собственно если менеджмент не понимает состояние внутреннего качества, будет говнопродукт. А одна из главных задач менеджмента это и есть соблюдение этого баланса. И когда говорят, что у нас нет времени писать все хорошо, значит ваши программисты не того уровня. тут вспоминается старик Брукс и описанная им разница в производительности хорошего и плохого программиста.

Здравствуйте, Аноним, Вы писали:

А>Все мы знаем что более чем в 80% случаев создается говнокод, даже если разработчик может писать хорошо. Причины разные, отсуствие мотивации, сжатые сроки и т.д.
А>Примерно также более чем в 80% случаев сама разработка плохо организована, из-за наличия говноменеджемнта.

А>Рассмотрим ситуации :

А>1 менеджмет-код
А>2 менеджмент-говнокод
А>3 говноменджмент-код
А>4 говноменджмент-говнокод

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


А>остается устойчивых 2 ситуации 1 и 2.

А>Вопрос возможно риторический, но все же.
А>Так что на ваш взгляд первичнее менеджмент или код ?

А>т.е.
А> получается говнокод из-за говноменеджмента или наоборот говноменеджмент появляется из-за говнокода.

Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

Здравствуйте, 5er, Вы писали:

5er>Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
5er>Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

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

Здравствуйте, bkat, Вы писали:

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

Подтверждаю!

Здравствуйте, okman, Вы писали:

O>Никто не даст точного определения, что же такое говнокод и говноменеджмент.

Говноменеджер: "Почему опять нихрена не готово?!"
Говнокодер: "У меня работает!!!"
Говнотестер: уволен/не нанят, в целях сокращения расходов.

Здравствуйте, bkat, Вы писали:

B>Здравствуйте, 5er, Вы писали:

5er>>Первичной, по моему мнению, является архитектура, от которой зависит 'плавучесть' проекта.
5er>>Потопить проект с базовой хорошей архитектурой не так-то и просто ни тем, ни другим.

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

Ваш ответ подразумевает создание архитектуры. Т.е. начальный этап. Здесь важен конкретный человек или
группа людей с конкретным опытом и видением перспективы.
Я не об этом. Что дальше?

Приходилось наблюдать развитие проектов 10+ давности, которые
живут, развиваются и продаются до сих пор. Люди, которые начинали эти продукты уже
давно трудятся в других местах. Управления как такого нет, т.к. новый менеджмент меняется
каждые пару лет просто физически не успевая вникнуть во все нюансы.

Да, есть распределение задач, реализация новых фич и т.п. Но в целом фундамент остается
неизменным.

Конкретный управленец или исполнитель в состоянии подпилить сук на котором сидит (ту часть, которую делает),
но в целом система остается незыблемой из-за принципов, заложенных в ее архитектуру при ее создании.

В итоге человек внутри проекта подпитывает ее новыми фичами, но сам
по себе отходит на второй план. Его вполне можно заменить без критического ущерба.

Здравствуйте, <Аноним>, Вы писали:

А>3) говноменеджер навязывал свои технические решения и любые рацпредложения программистов давил на корню. Сам говноменеджер, хоть и писал сайтики на асп-нете, в программировании — полный ламер, не знающий элементарных вещей.

А>Мой вывод, основанный на печальном опыте, таков, что говноменеджер может сделать говнокод, имея даже команду самых лучших программистов.

Лучшие програмисты не допустят навязывания безграмотных технических решений.

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

Я с большего согласен, и добавлю несколько соображений.

* Кроме менеджера есть ещё множество переменных окружения, ведущих к плохому коду. Представьте, что вы унаследовали сташный codebase.

* Хороший менеджмент — не гарантия хорошего кода. Представльте, что в условиях крайне ограниченного бюджета, с командой из джуниоров, менеджер ухитряется держать проект достаточно прибыльным, клиента достаточно довольным, и команде даже местами бонусы перепадают. Но при этом фигурирует ожидаемый говнокод. Был бы менеджер лучше, если б стал горой за качество кода, и потерял бы клиента и/или нанёс ущерб работодателю?

* Вместе с тем, есть разработчики, хронически неспособные производить говнокод. Как на них не дави, в какие условия не ставь, они будут делать качественно. Может, не попадут в ожидания менеджмента и как-бы всех подведут по срокам. Может, не вписавшись, "проголосуют ногами" из такой конторы. Но не выдадут говнокод.