В упрощенном представлении программист - человек, который способен описать задачу на языке, понятном компьютеру. Компьютер, в свою очередь, - это любое электронно-вычислительное устройство, которое умеет выполнять однозначно определенные последовательности команд путем передачи электрических импульсов (во всяком случае, на момент написания этих строк). Однако программы в их современном понимании пишутся не столько для компьютеров, сколько для людей.
Компьютер не волнует качество архитектуры программной системы; выбор имен классов, функций и переменных; комментарии и прочие мелочи жизни. Эволюция языков программирования обязана ограниченным человеческим возможностям. Для машины вполне понятным и естественным (родным) является язык, состоящий из нулей и единиц, - двоичный код. По сравнению с двоичным кодом даже ассемблер представляется большим шагом вперед, ведь человеческий мозг не предназначен для запоминания чисел.
Современные языки программирования пытаются дать разработчикам возможность моделировать реальные предметы в форме абстрактных моделей. Например, гораздо удобнее манипулировать таким понятием, как "изображение", а не "массив пикселей".
Помните, что в большинстве случаев хороший код - это код, который легко понять (как вам, так и другим людям). Конечно, бывают исключения. В частности, может возникнуть необходимость оптимизации программы по скорости выполнения или расходуемой памяти. Однако часто преждевременная оптимизация серьезно подрывает качество проекта. Запомните: оптимизируйте только то, что гарантировано даст результат. В этом вам поможет профилирование кода. Оптимизация до проведения каких-либо измерений в лучшем случае является пустой тратой времени. Без оценки прироста эффективности вы даже не сможете однозначно сказать, что код не стал менее оптимальным, чем был до этого!
Реальность такова, что программные проекты в наше время имеют такой масштаб, что для достижения приемлемых сроков выпуска требуется хотя бы несколько разработчиков. В этом случае важность качества кода становится еще выше. Ход ваших мыслей должен быть понятен не только вам, но и остальным членам команды. Пытайтесь подавлять желание блеснуть своей эрудицией, используя слишком сложные структуры и конструкции языка, если можно воспользоваться более простым аналогом. Читая ваш код, у других должно возникать ощущение, что он - простой. Простой в хорошем смысле (не примитивный). Такой, что в другом виде его и представить нельзя. Если у вас это получится, то можете считать, что пришли к успеху.
Но не забывайте, что есть и обратная сторона коллективной разработки. Вы должны уметь читать чужой код, а это может оказаться сложнее, чем писать понятный код самому. Конечно, в хорошо организованной команде архитектура приложения должна быть построена таким образом, что каждому разработчику выделяется некий набор модулей системы, над которыми он работает. Это позволяет избежать большинства конфликтов в системе контроля версий, когда в рамках одного и того же файла возникают несовместимые изменения, внесенные разными программистами. Но будьте готовы к тому, что в любой момент именно вам придется подхватить чужие модули. Ведь никто не застрахован (любому может упасть на голову светофор).
В гибких методиках разработки приветствуется "парное программирование" и "коллективное владение кодом". Изучите эти техники. Возможно, что для вашей команды разработчиков что-то из этого подойдет.
Вот лишь несколько книг по теме, которые я не могу не упомянуть, и крайне рекомендую к прочтению:
