Как пасти котов. Наставление для программистов, руководящих другими программистами - Дж.Ханк Рейнвотер

Какова мораль? Очевидно, она в том, чтобы не спать на работе. Но это еще не все. К сожалению, некоторые программисты не выдерживают нагрузки. Мы должны работать в высоком темпе, а с теми, кто за ним не поспевает, приходится прощаться. Это жестокая реальность. Надеюсь, у Грега все нормально, – ведь с тех пор я его ни разу не видел.

Кодовая полиция

Переместимся из XVI в XX век – как говаривал Элиотт, «Это один из вариантов конца света/Без треска, но с воем»[70]. Не стоит делать программы по этому принципу. Для того чтобы избежать этого, вам придется играть роль кодового полицейского. Если выражаться более знакомыми терминами, вам предстоит проводить регулярные критические обзоры кода, направленные на проверку соответствия архитектурной базе и принципам проектирования. Вспомним принцип, который я сформулировал в главе 2, – без регулярных проверок нельзя рассчитывать на хорошие результаты. Именно поэтому критические обзоры кода так важны.

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

Что касается недовольства вторжением в результаты своей деятельности, программистам придется смириться. Не стоит пугаться, что программисты отреагируют на такое вмешательство резко негативно. Это лишь признак сопричастности, а она, как известно, является необходимым условием создания качественного программного обеспечения. Хуже, если программист относится к вашей конструктивной критике индифферентно – из этого можно заключить, что конечный результат его не интересует. Толстокожесть техническому лидеру не повредит. Если вы слишком стеснительны, чтобы исправлять чужие ошибки, вы рискуете набить немало шишек – быть может, это вас образумит.

Следите за законностью

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

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

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

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

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

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

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

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

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

Наиболее распространенные нарушения

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

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

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

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

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

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