Последнее изменение: 29 октября 2010г.

Введение

Существует, на мой взгляд, несколько правил, которыми стоит руководствоваться при разработке программного обеспечения, вне зависимости от того, что разрабатывается и для кого. Здесь я исхожу из мысли, которая очевидна: программное обеспечение разрабатывается людьми и для людей. Из этой мысли и вытекают все правила, о которых пойдет речь. Я бы назвал эти правила аксиомами, ибо для меня они аксиомами и являются. Возможно, эти аксиомы и просты, но меня поражает количество людей, которые о них не знают либо не следуют им.

Итак,

Аксиома 1.

Если есть возможность воспользоваться чужим опытом – изучи ее.

Изобретать велосипед – это здорово. Это полезно для понимания процесса, для изучения нового, для занятия своего свободного времени. Подчеркиваю – СВОЕГО СВОБОДНОГО времени. Если вы делаете это для себя – дай Бог вам здоровья и терпения. Я очень уважаю людей, которые изучают новые для себя предметы путем изобретения велосипеда. Более того, зачастую в результате такого копания получаются весьма интересные вещи, которым можно найти применение на практике. Дети, безусловно, оценят четырехколесный велосипед, т.к. на нем проще учиться кататься.

Реальность же разработчика программного обеспечения такова, что разрабатывается софт для кого-то, кто за это ПЛАТИТ. И пусть даже этот кто-то платит только за уже разработанный софт (хотя чаще всего оплачивается время, затраченное на разработку), – ему не все равно, КОГДА он этот софт получит. Заказчик программного обеспечения хочет получить его как можно раньше (чаще всего – еще вчера!), и его совершенно не устроит перспектива оплачивать изобретение велосипеда.

Кроме того, тут есть еще один немаловажный аспект. Лично я не могу гарантировать, что если я и изобрету этот велосипед, он окажется столь же эффективным, как то, что сделает профессионал. Я могу не учесть каких-то тонких моментов просто в силу незнания специфики предметной области. Гораздо проще и эффективнее (с точки зрения нервов и времени) использовать то, что разработал тот, кто съел на подобных разработках десять собак.

К использованию чужого опыта относится и разделение обязанностей. Я могу самостоятельно спроектировать базу данных. Она даже будет работать, я в этом не сомневаюсь. До первой ситуации, которую я не предусмотрел. А не предусмотрел я массу всего. Почему? Не специалист.

Пример из недавнего прошлого. Рефакторинг, затрагивающий в числе всего прочего и схему базы. Все изменения продуманы и внесены в техническую спецификацию. Спецификация прочитана всей командой, архитекторами. Всё, вроде, в порядке. Даю почитать эту спецификацию нашему гуру. Через полчаса он мне выдает 4 исправления в схему. Вот тут надо добавить «not null», тут ввести ограничение, вот тут возникнет расхождение в случае каскадного удаления... И т.д. и т.п. Я себе даже вообразить не мог сразу те ситуации, в которых эти ошибки возникнут. А для него это все – как открытая книга. Он такие ошибки находит, читая текст краем глаза. И потому – использовать его опыт гораздо эффективнее, чем делать это самому. Не говоря уж о том, что на одну и ту же работу он тратит времени в несколько раз меньше меня.

Следующая аксиома вытекает из уже затронутой проблемы использования чужого опыта. Вернее, из ситуации, когда это сделать по какой-то причине невозможно. Хорошо, конечно, когда есть человек, который разбирается в вопросе, и которому можно переадресовать часть работы. Но это из области идеального мира, так бывает далеко не всегда. И человека нет, и задачу эту никто еще не решал. Или решал, но не решил. Или решение не подходит. В общем, приходится браться за дело самому.

Эту фразу я увидел в одной биолаборатории на стене. Она мне настолько понравилась, что я решил второе правило сформулировать именно так. Итак,

Аксиома 2.

Если ты не понимаешь, что делаешь – делай это тщательно.

Лучше потратить больше времени на разработку, работать медленнее, проверять каждый шаг – но быть уверенным, что реализация не содержит ошибок. Особенно, когда цена ошибки может быть высокой. Почему я упоминаю об этом отдельно? Я, к сожалению, видел слишком много прямо противоположных подходов. Как правило, от непонятного стремятся избавиться всеми силами. Реализовали, спихнули – и ладно. Уф, можно дух перевести. И хорошо еще, если такая реализация не станет причиной серьезных проблем. А ведь кому-то это еще придется поддерживать... Впрочем, об этом дальше.

Третья аксиома вытекает из того, что программное обеспечение разрабатывается людьми. А люди могут совершать ошибки. Это печально, конечно, но это – данность. Изменить это мы не в состоянии, потому надо учиться с этой данностью жить. А кроме ошибок программистов могут быть еще и ошибки на более высоком уровне – у тех, кто ставил задачу. Чего-то не учли, на что-то заложились. Да и просто ситуация на рынке может поменяться. В общем, речь идет о внесении изменений в программное обеспечение. Я еще не видел такого софта, который, будучи написан однажды, не потребовал бы каких-либо изменений.

Итак,

Аксиома 3.

Программный код должен читаться легче, чем писаться.

Почему именно так. Код пишется один (в скобках прописью – ОДИН) раз. Как правило – одним разработчиком. То есть до момента готовности первой версии этого кода (когда он был написан, протестирован до какой-то степени, включен в общий проект) с кодом работает его автор, который имеет свой стиль программирования и свой образ мышления, что намного более важно. Когда потребуется внести изменения в этот код – не знает никто. И совсем не факт, что изменения в код будет вносить его первоначальный автор. (В экстремальном программировании – скорее всего это будет НЕ автор!) И сколько изменений потребуется – не знает опять-таки никто. Один раз изменили, второй раз изменили. Каждому из тех, кто вносит изменения, приходится разбираться с уже существующим кодом. И чем дальше – тем сложнее это будет делать, потому как у каждого из предыдущих разработчиков свой стиль и свое мышление. А потому – если все разработчики не будут придерживаться этого правила, то, рано или поздно, КОД СТАНЕТ СОВЕРШЕННО НЕПРИГОДНЫМ к поддержке.

Не существует однозначного рецепта, как написать легко читаемый код. Это приходит только с опытом – с большими проектами, с углублением в чужой код. Я могу лишь сформулировать некоторые соображения, которые могут облегчить жизнь разработчику.

Как правило, приходится выбирать между «сделать быстро», «сделать просто1» и «сделать грамотно». Первого чаще всего хочет начальник, второго – собственная лень. По моему мнению, эти два варианта в мало-мальски серьезной разработке должны исключаться. Ибо «быстро» – это ЯВНО в ущерб качеству. «Просто» – не столь явно, но скорее всего – тоже в ущерб качеству. Только проявиться это может позже, уже на стадии внесения изменений, когда каждое изменение будет даваться с огромным трудом.

«Сделать грамотно» практически всегда оказывается сложнее и занимает больше времени. Но, во-первых, грамотно спроектированный код читается ОЧЕНЬ легко. Во-вторых, внесение изменений является тривиальным занятием, ежели эти изменения можно предсказать заранее и заложиться на них. А часть изменений действительно достаточно просто предсказать, в этом я уже неоднократно убеждался.

На этом сайте есть еще две статьи, в той или иной мере касающиеся проблемы легко читаемого кода. Легкая читаемость кода для меня лично в большой степени является синонимом качества кода. Этому вопросу посвящена статья Качественный код – слагаемые. В немалой степени читаемость кода также связана с использованием констант. Этот вопрос обсуждается в статье Изменчивые постоянные, или «что такое 122?»

И напоследок. Призываю вас писать грамотно. Ибо этим вы облегчите жизнь в будущем, не только другим, но и, возможно, себе. На мой взгляд, дело того стоит.



1. Хочу конкретизировать слово «просто». Я не призываю писать сложный код. Я всего лишь имею в виду тот факт, что грамотный код в подавляющем большинстве случаев сложнее того, который придет в голову сразу. И делать сложнее, когда можно сделать проще, – вот это-то как раз и лениво. В качестве иллюстрации можете почитать вот этот фрагмент статьи о модульном дизайне: Как это бывает в жизни. Он как раз о том, как получается, когда делают просто, «в лоб».