svcoderЕсть коллектив разработчиков, уровень очень разный:
1) думает перед тем как писать код
2) думает во время написания кода
3) думает после написания кода
4) вообще не думает что пишет.

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

Думаю все в той или иной степени сталкивались с такой проблемой. Какой из вариантов решения выбрать?
1) Учить категории 3 и 4 хотя бы до уровня 2
2) Внедрить контроль качества, когда уровень 1 контролирует уровень 2, а уровень 2 контролирует уровни 3 и 4
3) Дать уровням 3 и 4 самостоятельно достичь уровня 2 в течение полугода, иначе выгонять
4) Выгнать уровни 3 и 4

Я не читал предыдущие комментарии, поэтому буду отвечать только на поставленный вопрос.
Во-первых, надо действительно быть уверенным, что во главе коллектива стоят высококвалифицированные программисты, а не "быдлокодировщики", как вы их называете. Дело в том, что в жизни вверх по служебной лестнице рвутся именно быдлокодировщики, так как они программировать не умеют, а следовательно им это и не очень нравится. Поэтому для себя они видят выход - это быстрее подняться по служебной лестнице на административную работу. Причем этот быдлокодировщик не обязательно является плохим специалистом. Только он не является специалистом в программировании. Например, он может хорошо знать содержательную или описательную часть программы. Например, он был в проекте с самого начала, а потому лучше любого профессионального тпрограммиста, но новичка, знает, что программа делает и какие у нее слабые места, и почему было сделано именно так и не иначе. Они пользуются этим преимуществом в знании проекта и, как только видят, что пришедший профессионал-программист начинает их догонять по знанию программы, то стараются всеми способами изжить его, чтобы опять набрать новичков, которые будут естественно в начале беспомощны в проекте, так как требуется время, чтобы разобраться, что этот проект делает и как он написан.
Ежели во главе проекта действительно стоят высококвалифицированные программисты, то в этом случае вопрос решается очень просто. Организуется код-ревью. То есть быдлопрограммист пишет код, который естетсвенно в проект не включается. Затем этот код предоставляется всем участникам проекта на ревью, то есть каждый может сделать свои замечания по коду. После чего программист, чей код ревьюируется, должен либо дать аргументированный отказ от принятия замечаний, либо переделать код.
При таком подходе у быдлокодировщика есть два выхода: 1) либо самому уволиться, так как он будет себя чувствовать некомфортно: 2) либо на основе тех комментариев, которые к его коду дают более квалифицированные программисты, расти самому как программисту.:)

svcoderotziС Ваших слов ситуация в целом не очень понятна: например, ответственного за разработку нет, а за результат есть - это как - тот, с кого спрашивают за результат, он с кого спрашивает?
Очень просто - у каждого разработчика отдельная задача в рамках проекта (у кого-то сложнее, у кого-то проще), результат решения которой проверяют в отдельности.

Это явно детские рассуждения! Уж вы-то сами точно к квалифицированным программиистам не относитесь, а являетесь именно быдлокодировщиком!:)
Если бы вы были профессиональным программистом, то вы бы понимали, что в проекте не должно быть сборной солянки, то есть весь проект должен подчиняться определенным спецификациям, соглашениям о наименовании переменных, о стиле кодирования и т.д.
Во-вторых, это совершенно неправильный подход: мол, работает, и с меня взятки гладки.:) В программировании, как в отдельной специальности, важно качество кода. Плохой код тоже между прочим может работать. Только никто с ним не будет иметь дело при сопровождении и развитии.
В-третьих, давно известно, что по отдельности что-то может работать, а вместе - нет. И совершенно не обязательно не работает по причине того, что у кого-то не работает. Оно может не работать именно потому, что у кого-то работает в отдельности! Просто он написал так, что нарушил спецификации, а из-за этого у других не работает.
В-четвертых, все части проекта взаимосвязаны, и бывают ситуации, что одна подсистема проекта потребует перепроектирования проекта в целом. То есть программист сталкивается, допустим, с трудностями написания кода из-за того, что изначальное проектирование проекта была нерпавильным, или не совсем оптимальным. И чтобы ему продолжить работу, нужно другим участникам проекта пересомтреть свои задачи.

То есть проект - это коллективный продукт, а потому за него отвечает коллектив и непосредственно руководитель проекта.
А ваши исходные вопросы связаны как раз с тем, что у вас не поставлена работа коллектива. Я уже написал в своем другом сообщении, что нужно делать код ревью перед включением кода в проект. Можно устраивать и промежуточные проверки и собрания, чтобы следить за ходом развития проекта, знать, какой программист испытывает какие трудности, чтобы вовремя помочь решить эту проблему.

otziСыроежкаА ваши исходные вопросы связаны как раз с тем, что у вас не поставлена работа коллектива.Там ещё психология - похоже, что реально существующие проблемы заменены отвлечённой. Реальная проблема - как поступать, когда ты находишься в неуправляемом проекте, и при этом не имеешь достаточно полномочий что-то менять. Но эту тему ТС не поддержал.

Когда нет квалифицированного управления, то начинается бардак. То есть по аналогии когда в обществе не работает правосудие, начинается самосуд. Точно также и в колективе программистов. Когда коллективом руководит непрофессионал и низкоквалифицированный начальник, то начинается разброд и шатания, а каждый программист предоставлен сам себе. А это - почва для склок между программистами.
В той постановке вопроса, которую вы решили рассмотреть, я думаю, надо просто делать качественно свое дело и не пытаться доказывать, что твой код лучше, даже если он действительно лучший, а другие писать не могут.
Дело в том, что если такое положение дел существует, значит начальника это устраивает. А если вы попытаетесь что-то изменить, то скорей всего против вас ополчаться все те, кто пишет плохой код.
То есть как и в объектно-ориентированном программировании области компетенции должны быть разделены. Вы должны отвечать за реализацию своего классв и работать с другими объектами (членами коллектива) только через открытый интерфейс. Это в жизни очень печально, что вы вынуждены иметь дело с быдлокодировщиками Но если приходится иметь с ними дело, то значит такова политика вышестоящего руководства. А руководству нужны исполнители. Они не терпят специалистов, которые имеют свое мнение.:)