Как пасти котов. Наставление для программистов, руководящих другими программистами
Шрифт:
Мы только что приступили к работе над новой программой последовательной связи, и наш отдел продаж требовал поставить ее как можно быстрее. В те времена такого понятия, как отдел тестирования, еще не существовало – штат сотрудников проекта ограничивался кодировщиками, пытавшимися всеми силами успеть к срокам, установленным отделом продаж. Грег в нашей компании трудился уже довольно долго и, надо сказать, весьма успешно, поэтому к постоянному давлению привык. По крайней мере, мне так казалось. У него даже была репутация ценного сотрудника – в основном потому, что он единственный из нас всех умудрялся сопровождать код старых приложений, которые уже не продавались.
В отделе все стояли на ушах. Платформа Windows 3.0 только что появилась, и наши старания по части разработки приложений сочетались с попытками постичь идиосинкразическую природу интерфейса прикладного программирования Windows. И, между прочим, у нас это неплохо получалось. В нашем отделе у каждого программиста было собственное помещение,
Однажды, показывая заказчикам условия, в которых мы работали, директор с вице-президентом появились в отделе разработки. Познакомившись с парой инженеров, группа направилась в кабинет Грега. Что же они увидели, открыв дверь? Грег мирно спал за столом, водрузив на него ноги. Повсюду были разбросаны пластиковые пакеты из-под еды, иногда с древними остатками самой еды, да и вообще комната представляла собой весьма унылое зрелище и вряд ли могла кому-то понравиться. Меня в тот момент там не было, поэтому я говорю с чужих слов.
А рассказали мне много интересного. Вице-президент по продажам настоял на том, чтобы уволить Грега немедленно. Директор согласился. Выбора у меня не было. Вскорости я сообщил Грегу неутешительные новости, после чего был вынужден наблюдать жалкую сцену мольбы о пощаде и последнем шансе. Я ему сказал, что это не в моей власти, что мне ужасно жаль, и еще до обеда его рабочее место очистили от мусора, а его самого выставили за дверь.
Какова мораль? Очевидно, она в том, чтобы не спать на работе. Но это еще не все. К сожалению, некоторые программисты не выдерживают нагрузки. Мы должны работать в высоком темпе, а с теми, кто за ним не поспевает, приходится прощаться. Это жестокая реальность. Надеюсь, у Грега все нормально, – ведь с тех пор я его ни разу не видел.
Кодовая полиция
Переместимся из XVI в XX век – как говаривал Элиотт, «Это один из вариантов конца света/Без треска, но с воем» [70] . Не стоит делать программы по этому принципу. Для того чтобы избежать этого, вам придется играть роль кодового полицейского. Если выражаться более знакомыми терминами, вам предстоит проводить регулярные критические обзоры кода, направленные на проверку соответствия архитектурной базе и принципам проектирования. Вспомним принцип, который я сформулировал в главе 2, – без регулярных проверок нельзя рассчитывать на хорошие результаты. Именно поэтому критические обзоры кода так важны.
70
T.S. Elliot, Collected Poems 1909–1962 (New York: Harcourt Brace Jovanovich, 1971), p. 82.
В ходе проведения обзора вам предстоит столкнуться с двумя трудностями. С одной стороны, против вас работает время; с другой – программисты зачастую слишком ревностно относятся к попыткам редактирования своего кода. В конце концов, в сутках всего 24 часа. Пытаться изменить это обстоятельство бесполезно, поэтому единственный выход – учиться использовать время рационально. О том, как наиболее эффективно распоряжаться своим временем, говорится в главе 4, посвященной организованности.
Что касается недовольства вторжением в результаты своей деятельности, программистам придется смириться. Не стоит пугаться, что программисты отреагируют на такое вмешательство резко негативно. Это лишь признак сопричастности, а она, как известно, является необходимым условием создания качественного программного обеспечения. Хуже, если программист относится к вашей конструктивной критике индифферентно – из этого можно заключить, что конечный результат его не интересует. Толстокожесть техническому лидеру не повредит. Если вы слишком стеснительны, чтобы исправлять чужие ошибки, вы рискуете набить немало шишек – быть может, это вас образумит.
Следите за законностью
Вы вместе с вашими подчиненными должны работать так, как будто повязаны узами контракта. В качестве основных положений контракта при этом выступают коммерческие спецификации и ваше видение архитектуры; условия же контракта сводятся к принципам и методикам проектирования. Будучи программным полицейским, вы должны следить за корректностью разрабатываемого программного продукта, начиная от зародышевого состояния и вплоть до зрелости. Впрочем, довести программный продукт до состояния зрелости пока что не удается – при сегодняшнем технологическом уровне приложения останавливаются в своем развитии в подростковом состоянии. Ну, может быть, мы приближаемся к юношеству. Каждая компания по-своему уникальна, в каждой приняты собственные стандарты оценки зрелости продуктов [71] . Принципам оценки в программной инженерии посвящены многочисленные издания. Кейперс Джонс (Capers Jones) в своей книге «Applied Software Measurement» [72] утверждает, что наиболее успешные компании, работающие в сфере разработки программного обеспечения, отличаются шестью
общими характеристиками.71
См. Humphrey, op. cit., p. 5.
72
Capers Jones, Applied Software Measurement (New York: McGraw-Hill, 1991), p. 1.
1. Они проводят точные измерения продуктивности и качества программных продуктов.
2. Они тщательно планируют и оценивают программные продукты.
3. У них работают квалифицированные менеджеры и технические специалисты.
4. У них адекватные организационные структуры.
5. Они пользуются наиболее эффективными методами и инструментами разработки программного обеспечения.
6. Их сотрудники работают в достойных условиях.
Из всех этих характеристик наиболее важной Джонс считает первую. Именно здесь в полную силу проявляются преимущества критических обзоров кода.
Правила вам известны. Если бы вы их не знали, объяснить ваше продвижение по ступенькам административной лестницы было бы довольно трудно. Смысл критических обзоров кода состоит в донесении вашего опыта до менее бывалых подчиненных. Критические обзоры – это вам не контрольные работы в школе, за которые в дневник ставят оценки, а потом напротив них свои подписи ставят родители. Скорее их можно сравнить с университетскими семинарами, на которых проницательные студенты стремятся выявить наилучшие идеи и забраковать неудачные. Сотрудники, демонстрирующие неспособность учиться на критике, вряд ли смогут долго оставаться в нашей профессии. Быть может, такой подход покажется вам слишком жестким, но если не вывести теоретические основы разработки на практический уровень, будет страдать качество конечного продукта.
Наиболее распространенные нарушения
В своем кратком обзоре основных принципов проектирования я акцентирую ваше внимание на трех аспектах: стандартах, связности и взаимозависимости. Рассмотрим соответствующие нарушения.
Везде ли проставлены комментарии? Сможет ли с их помощью новичок, не знакомый со структурой данного модуля, в нем разобраться? Предположим, вы пытаетесь проследить последовательность исправления ошибки, – можно ли это сделать по комментариям? Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля. Для того чтобы продолжить чье-то начинание, вы должны знать, почему ваш предшественник пошел именно тем путем, которым пошел. В этом вам помогут комментарии.
Соглашение по именованию. Следуют ли ему ваши подчиненные? Возможно ли, взглянув на имя переменной, с уверенностью судить о ее области действия? Отлаживать код, в котором для определения области действия предположительно неверного параметра приходится тратить по полчаса, невероятно трудно. Бывает и так, что имена процедур настолько длинны, что наводят на мысль о бесполезности или даже вредности введения длинных имен файлов в Windows. Быть может, они, напротив, настолько коротки, что для расшифровки имен подпрограмм приходится прибегать к словарю? Между этими крайностями нужно найти баланс – кто знает, может быть, для этого вам придется провести урок грамматики и объяснить своим подчиненным, чем глагол отличается от существительного. Я понимаю, что префикс «get» в именах подпрограмм, извлекающих данные, утомляет; но его наличие безусловно свидетельствует о том, что они что-то извлекают. То же самое можно сказать о префиксе «set». Простота во многих случаях – синоним практичности.
Комментарии должны разъяснять, почему код написан именно так и никак иначе, и как этого удалось достичь – причем основной упор следует делать на раскрытии вопроса «почему?». О том как разработчик достиг поставленной задачи, свидетельствует сам код; в то же время комментарии помогают проследить ход мыслей разработчика во время разработки модуля.
Соглашение по именованию и комментарии к коду предоставляют нам возможность употреблять в процессе написания кода единый язык. Не позволяйте своим подчиненным прибегать к «технологии безмолвия». Заставьте их должным образом расставлять комментарии и присваивать имена. Далеко не всегда разработчики отказываются от комментариев из-за спешки – иногда они сами плохо понимают, что сделали (например, скопировав готовый код из библиотеки и понадеявшись на авось). Бывает, они копируют комментарии, сделанные автором библиотеки, к которой они обращаются. Это много о чем говорит. Конечно, в основном про комментарии забывают из-за неуверенности в результате или из-за элементарной лени. Несколькими пометками в коде ситуацию не исправить. Такие явления зачастую означают значительно более серьезную проблему, с которой столкнулся кодировщик и решать которую нужно на более высоком административном уровне.