Не важно работает человек за зарплату или нет. Программируя на себя не станешь лучшим программистом, чем работая в компании. Работая одиночкой или в мелкой компании подцепляешь всякие негативные стереотипы. Сегодня разработка программных продуктов уже более-менее отработана, не то, что 10-15 лет назад. В любом хорошем управляемом проекте есть проектная документация. Проектная документация делается и со стороны заказчика и со стороны разработчика. Заказчик пишет как он понимает то, что ему нужно, разработчик, со своей стороны описывает как он это собирается реализовывать. Поддерживаемые протоколы, взаимодействия и т.д. Детализация на уровне функциональных блоков, списков поддерживаемых функций, протоколов, форматов входных выходных данных, ошибочных ситуаций и т.д. Документация по отдельным проектам на 3-4 календарных месяца достигает иногда 300 или более страниц. (При длительных проектах как правило на каждого разработчика приходится по документу страниц в 150 - 300). Что касается разработки отдельных конкретных модулей, тут глубокой документации как правило не делается, не видел проектов, которые бы сумели сделать на этом уровне документацию, отражающую действительность.
Вместо документации на сам код, сегодня применяется юнит-тестирование и интеграционное тестирование, а также Continuous Integration сервера. В функциональность Continuous Integration сервера входит автоматический билд системы при изменении исходников в системе контроля версий, автоматическом прогоне юнит тестов, интеграционных тестов, если таковые автоматизированные имеются. Но это еще не всё.
Кроме того, чтобы проводить юнит тесты существуют, к примеру библиотеки типа Mockito, позволяющие для любого даже пустого интерфейса создавать mock-объект и задавать принудительно возврат нужного результата операции внутри метода или например выбрасывание исключения и т.д.. Есть также возможности создавать spy - объекты на основе существующих объектов, для изменения только некоторых методов, есть возможность проверить а вызвался ли такой-то метод такого то объекта с указанными параметрами с сколько раз....
Но тесты еще не все. Без грамотного отображения их результатов в них не было бы смысла. Существуют такие программные продукты как Cobertura для Java, позволяющие отображать на веб-странице покрытие исходного кода тестами. Причем отображать не просто покрытие абы как. А вплоть до каждого ветвления и каждой строчки.
Кроме всего выше перечисленного для промышленных языков программирования сегодня существуют IDE, включающие в себя мощнейшие средства для автоматического рефакторинга исходного кода. Что тоже помогает. А знание и применение паттернов проектирования, наконец, дает вам возможность быстро на лету схватывать любой вменяемый современный код.
Кроме средств для автоматизации тестирования существуют еще статические анализаторы кода и анализаторы стиля, в том числе и позволяющие автоматически форматировать исходники в соответствии с определенными конвенциями... И т.д. и т.п.
Кроме юнит тестирования и интеграционного тестирования, существует еще функциональное тестирование и приемочное тестирование. На тесты пишется отдельная документация иной раз превышающая по размерам девелоперскую. Все это тщательно согласовывается с заказчиком, а для тестов применяются другие технолологии. Но это уже в Q&A и глубоко в этой сфере я уже не кручусь.
Многих подобных технологий 10 лет назад не существовало. Сегодня наличие упомянутых средств, а также далеко продвинувшуюся вперед программисткая наука, сформулировавшая явно принципы dependency inversion, применившая на практике dependency injection..., разобравшаяся наконец более менее в том, что такое OOП, а также развивающая новые языки программирования в том числе функциональные и т.д. Все это вместе сделало промышленную разработку совсем другой.
Уже не секрет, как писать код так, чтобы не пришлось его переписывать. Переписывание происходит только при изменении функциональных требований или протоколов со стороны заказчика или при необходимости оптимизации отдельных частей проекта. Все это управляемый и предсказуемый процесс, называемый рефакторингом. При правильном покрытии тестами вероятность внесения в код побочных эффектов существенно снижается.
Наличие "говнокода" в проекте это сегодня не правило, а признак плохого управления проектом. Практика показывает, что средства для получения качественного кода сегодня есть и эти средства вполне по силам к внедрению в большинстве проектов и на моей памяти я видел в том числе и вполне некоммерческий проект, применяющий все средства автоматизации сборок, покрытия тестами, стилями, со вполне вменяемым менеджментом даже... Проект этот назывался
http://jtalks.org, разрабатывали они что-то для форумов на базе javа. Я в курсе, просто из-за того несколько моих коллег работающих в одной комнате в этом участовали. Проект кажется закончился удачно, если судить по сайту
http://javatalks.ru, на котором результаты применили, как я погляжу. Проект судя по всему продолжается, на сайте можно посмотреть что там применяется
http://jtalks.org. Часть средств разработки для проекта была предоставлена бесплатно
http://jtalks.org/display/jtalks/Our+Sponsors, после начала проекта соотстветсвующими компаниями разработчиками. Проект был инициирован на форуме javatalks.ru за счет исключительно кармы нескольких модераторов и активных участников.