Семь раз отмерь, один скомпилируй

Читаешь код, напичканный красивыми решениями, и диву даёшься. После недели непрерывной отладки оказывается, что нагромождение сложнейших конструкций даёт десяток ошибок на пути исполнения. Работает это всё только потому, что ошибки каким-то хитрым образом компенсируют друг друга. Не обрабатываются, а именно компенсируют. Да и то только до той поры, пока за компьютер не сядет какой-нибудь дотошный пользователь. На бумаге всё получается красиво, а на практике хочется повеситься.

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

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

Сначала подумайте. Потом подумайте ещё раза три. Потом нарисуйте то, что вы придумали, потом на недельку положите это в стол — и уже потом пишите. А еще читайте Макконнелла. Даже если вы знаете его наизусть, всё равно читайте.

Я позволяю себе давать советы, потому что знаю: если им следовать, то мне и таким людям, как я, которые доделывают за программистами дырки в заборах, будет удобнее и проще работать. Ошибки всё равно будут, это нормально. Но их исправление не будет сопровождаться желанием засунуть некоторых программистов в газенваген.