http://analizfamilii.ru/trade...

Рекомендую — не пожалейте времени на прочтение!:). Там же есть ссылки на подобное чтиво.

2 Anton Naumov, мы не разошлись во мнении:). Вы конкретизировали систему целей («...важно, что бы продукт не только работал, но был прост в поддержке и улулчшении...»), которая является generic’овой в контексте следующих (будущих) проектов либо поддержке при текущего, и является, как раз, технической целью. Конечно, хорошо покрытый и документированный код, скорее всего окажется и более подходящим под более мощное множество целей. В этом смысле такой код более «этичен». Моё утверждение можно уточнить так: примерять к коду эмоционально-окрашенные атрибуты (этичный, хороший, плохой) и определять его качество вне контекста — это не практично, исходя из постанвки вопроса в теме: можно увлечься ложными (нецелесообразными) ценностями и перерасходовать энергию-время. Так что ответить на вопрос темы «как оценить, окупятся ли дальнейшие усилия...», вне контекста, как правило, практически нет возможности. Качество — это не абсолютная, а условная характеристика кода. Либо, тогда его (качество) надо определят через нечто инвариантное вроде коэффициентов покрытия юнит-тестами и т.п. А потом сопоставлять эти показателями с расходами и прочими внешними (по отношению к коду) вещами. В любом случае, профессионалы интересны не как «сферичекие кони в вакууме» (в том числе и друг другу), поэтому и подчёркнута важность контекста. Если в контексте стоит во главе угла технический аспект, как например, возможность использования кода другими, и все готовы на сопутсвующие этому затраты, то Егор Егоров прав на все 99% — это очевидно и статистически доказано. Поскольку командная разработка — явление весьма распространённое, то такая постановка «этики» оправдана. Главное, чтобы эти сопутсвующие затраты не стали самоцелью, а для этого и нужно понимание и контекста, возвращаясь к профессионализму. По теме: стандарты должны быть, но уровень следования ним, должен быть постоянно под контролем и сопоставлением с условиями внешней среды:)

«Этичен» и «хорош» тот код, который будучи помещён в конечную конфигурацию, максимально удовлетворяет своего пользователя. При этом, если понадобится помещать код в конфигурацию другому пользователю, а вы к этому окажетесь не готовы, то это скорее «неэтичность» по отношению к себе в будущем или по другому «неэффективность» (а следовательно и непрофессионализм). Тогда в этом смысле код окажется «плохим», а команда «непрофессиональной». Это к тому что, понятие профессионализм и качество кода — вещи условные. Хотя, конечно и бесспорно, выполнение предусловий в виде best practices («стандаров»), повышают априорную вероятность быть профессиональным в указанном выше смысле. Но, думается, это НЕ необходимое и НЕ достаточное условие — это просто эмпирическое знание по множеству команд и проектов, которое НЕ обязательно сработает в каком-то конкретном случае и не обязательно является определяющим фактором в достижении целей конкретного проекта.