Вы вместе с вашими подчиненными должны работать так, как будто повязаны узами контракта. В качестве основных положений контракта при этом выступают коммерческие спецификации и ваше видение архитектуры; условия же контракта сводятся к принципам и методикам проектирования. Будучи программным полицейским, вы должны следить за корректностью разрабатываемого программного продукта, начиная от зародышевого состояния и вплоть до зрелости. Впрочем, довести программный продукт до состояния зрелости пока что не удается – при сегодняшнем технологическом уровне приложения останавливаются в своем развитии в подростковом состоянии. Ну, может быть, мы приближаемся к юношеству. Каждая компания по-своему уникальна, в каждой приняты собственные стандарты оценки зрелости продуктов[71]. Принципам оценки в программной инженерии посвящены многочисленные издания. Кейперс Джонс (Capers Jones) в своей книге «Applied Software Measurement»[72] утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью общими характеристиками.

1. Они проводят точные измерения продуктивности и качества программных продуктов.

2. Они тщательно планируют и оценивают программные продукты.

3. У них работают квалифицированные менеджеры и технические специалисты.

4. У них адекватные организационные структуры.

5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.

6. Их сотрудники работают в достойных условиях.

Из всех этих характеристик наиболее важной Джонс считает первую. Именно здесь в полную силу проявляются преимущества критических обзоров кода.

Правила вам известны. Если бы вы их не знали, объяснить ваше продвижение по ступенькам административной лестницы было бы довольно трудно. Смысл критических обзоров кода состоит в донесении вашего опыта до менее бывалых подчиненных. Критические обзоры – это вам не контрольные работы в школе, за которые в дневник ставят оценки, а потом напротив них свои подписи ставят родители. Скорее их можно сравнить с университетскими семинарами, на которых проницательные студенты стремятся выявить наилучшие идеи и забраковать неудачные. Сотрудники, демонстрирующие неспособность учиться на критике, вряд ли смогут долго оставаться в нашей профессии. Быть может, такой подход покажется вам слишком жестким, но если не вывести теоретические основы разработки на практический уровень, будет страдать качество конечного продукта.

В своем кратком обзоре основных принципов проектирования я акцентирую ваше внимание на трех аспектах: стандартах, связности и взаимозависимости. Рассмотрим соответствующие нарушения.

Везде ли проставлены комментарии? Сможет ли с их помощью новичок, не знакомый со структурой данного модуля, в нем разобраться? Предположим, вы пытаетесь проследить последовательность исправления ошибки, – можно ли это сделать по комментариям? Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля. Для того чтобы продолжить чье-то начинание, вы должны знать, почему ваш предшественник пошел именно тем путем, которым пошел. В этом вам помогут комментарии.

Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно ли, взглянув на имя переменной, с уверенностью судить о ее области действия? Отлаживать код, в котором для определения области действия предположительно неверного параметра приходится тратить по полчаса, невероятно трудно. Бывает и так, что имена процедур настолько длинны, что наводят на мысль о бесполезности или даже вредности введения длинных имен файлов в Windows. Быть может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм приходится прибегать к словарю? Между этими крайностями нужно найти баланс – кто знает, может быть, для этого вам придется провести урок грамматики и объяснить своим подчиненным, чем глагол отличается от существительного. Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утомляет; но его наличие безусловно свидетельствует о том, что они что-то извлекают. То же самое можно сказать о префиксе «set». Простота во многих случаях – синоним практичности.

Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля.

Соглашение по именованию и комментарии к коду предоставляют нам возможность употреблять в процессе написания кода единый язык. Не позволяйте своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным образом расставлять комментарии и присваивать имена. Далеко не всегда разработчики отказываются от комментариев из-за спешки – иногда они сами плохо понимают, что сделали (например, скопировав готовый код из библиотеки и понадеявшись на авось). Бывает, они копируют комментарии, сделанные автором библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в основном про комментарии забывают из-за неуверенности в результате или из-за элементарной лени. Несколькими пометками в коде ситуацию не исправить. Такие явления зачастую означают значительно более серьезную проблему, с которой столкнулся кодировщик и решать которую нужно на более высоком административном уровне.

Среди прочих распространенных нарушений стандартов – применение подпрограмм с несколькими точками выхода, а также введение ненавистного оператора GoTo. (Программистам VB эту привычку можно простить – благо в NET операторы Try, Catch и Finally включены в библиотеку.) Еще один распространенный недочет – регулярное отсутствие обработки ошибок. Некоторые убежденные в своей непогрешимости кодировщики считают обработку ошибок пустой тратой времени. Действительно, в некоторых случаях перехватить ошибку вверху цепочки вызовов вполне достаточно; в то же время неумение выявлять потенциальные источники ошибок свидетельствует об отсутствии у кодировщика навыков стратегического мышления.

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

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