Как пасти котов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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