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

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

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

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

Возвращаясь к перечню отличительных черт различных пород программистов, приведенному в главе 1, замечу, что с его помощью удобно выявлять и другие нарушения, допускаемые вашими подчиненными. Этот список можно продолжать бесконечно в зависимости от конкретного кадрового обеспечения [73] Специалистам по VB я рекомендую труд James D. Foxall, Practical Standards for Microsoft Visual Basic (Redmond, WA: Microsoft Press, 2000). Что касается других языков, выбор литературы обширен; взять хотя бы классическое издание по С – Steve Maguire, Writing Solid Code (Redmond, WA: Microsoft Press, 1993). Дополнительную литературу см. в библиографии. . Я лишь хочу заметить, что, исполняя роль кодового полицейского, вы обязаны фиксировать имена тех, кто нарушает правила.

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

Есть ли возможность по результатам анализа кода составить диаграмму блоков, демонстрирующую иерархии объектов? Выглядят ли отношения на такой диаграмме логичными, или же стрелки, напротив, расставлены бессвязно? Можно ли определить родословную объектов? При проведении критического обзора кода без таких вопросов не обойтись. Ваша задача – выявить слабые места и добиться их усиления. Не пытайтесь, впрочем, править код самостоятельно – ведь когда сроки поджимают, появляется искушение сделать все самому. Не забывайте, что, доверив исправление проблем сотрудникам группы, вы добьетесь гораздо более серьезного результата. Этот процесс, конечно, может затянуться, но вы ведь понимаете: если нет времени решить задачу сразу и правильно, то времени на то, чтобы переделать результат, тем более не останется.

Заметив нарушения, вы должны приостановить процесс кодирования, пока нарушители не исправят ситуацию. Чем дольше нарушения будут игнорироваться, тем выше вероятность того, что код придется отправить прямиком на помойку [74] См. Hunt and Thomas, op. cit. – авторы обозначают хаотичность в разработке программных продуктов изысканной метафорой: «не надо жить с разбитыми окнами». Я более чем уверен, что эта книга обязательно должна занять достойное место в вашей библиотеке, – уж очень она хороша. . Когда разработчики обнаруживают халтуру своих коллег, они невольно опускаются до того же уровня – это человеческая природа, ничего не поделаешь. Если владение оружием предполагает употребление обоих рук, то грамотное проведение критических обзоров кода требует пресечения деятельности нарушителей за счет авторитета руководителя.

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

Философия без практики бесполезна. Видение и действие должны сочетаться гармонично, как рука и перчатка. Иначе говоря, действуйте по своим убеждениям. Многие люди, не исключая программистов и руководителей, знают, как нужно делать, но тем не менее не делают этого. Существует ли верный метод экстраполяции теоретических знаний на практику, способный предотвратить разрушительные последствия бездействия? Никакого секрета здесь нет – скорее, возможен некий диалог, способный убедить вас слезть с койки (то есть отказаться от праздности) и приступить к действию. Быть может, перечисление последствий бездействия, исходя из сформулированных в этой главе принципов, вам поможет.