The Programmers` Stone (Программистский камень)

Во-вторых, у нас есть картина того, как программист оптимизировал последовательность проектных решений для получения минимального решения и управления сложностью. Поэтому нам нужно посмотреть на виды конструкций, из которых строятся программы, и убедиться, что они общедоступны. Такое руководство по стилю проекта указывает на согласованный набор соглашений об именовании переменных, стратегий обработки ошибок, примеров идиом использования API подсистем и даже стиль комментариев. Можно сказать, что управляя формой кирпичей, архитектор может задать форму здания, оставляя в то же время гибкость в руках конструктора. Структура такого кода, таким образом, гарантирует, что код канонических примеров предсказуем и элегантен. Поэтому примеры кода в руководстве по стилю управляют структурой, а структура управляет кодом. Здесь мы видим еще одно эхо "Хода конем" -- если мы используем правильные структуры, то мы можем ввести в игру необходимый и достаточный синтаксис и написать минимум текста. И наоборот, чем более запутанные берутся приемы, тем больше их нужно, чтобы переплести их вместе.

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

Управление настроением

У паковщиков есть правила ведения дискуссий, включающие подсчет очков каждого и демонстрирующие полную незаинтересованность в конечном результате в поведении и языке. Картостроители также имеют правила ведения дискуссий, но они несколько другие.

Картостроителям разрешается подпрыгивать и много кричать. Но это не означает, что они собираются убить друг друга, это означает их причастность. Вероятно, они прервутся только сходив вместе на ланч, продолжив свои выкрики по возвращении.

У каждого будет свой собственный способ говорить о свойствах проблемы, и понадобится согласовать общий жаргон проекта. Сделайте эти согласования по совместной мысленной модели и нацельте группу на созидание и оспаривание части достижений группы, а не на воздвижение стен вокруг замков из песка. Ненавидьте грех, а не грешника!

Если коллега говорит что-то, что вы не понимаете или кажется парадоксальным или нелепым, спросите себя, а что если человек пытается рассказать о части карты, которую вы видите перед собой, с совершенно другой точки зрения. Узнайте, что это значит на языке, который вас устраивает. Начните с предположения, что у него имеется кое-что интересное в голове, и попытайтесь выяснить, что это такое. Этот стиль дискуссий, о котором много думали апологеты зететики (Zetetics), вышедшие из Общества по Исследованию Паранормальных Проявлений (Society for the Investigation of Claims of the Paranormal -- SICOP), чтобы исследовать, какими могли бы быть правила доказательства существования паранормальных явлений.

Просто быть группой картостроителей с совместно используемой мысленной моделью совершенно недостаточно, чтобы начать вместе ее изменять. Как и во всех остальных случаях, мы должны явно осознать правильность того, что мы пытаемся сделать. На других этапах проекта команде потребуются другие размышления. Иногда вам захочется собрать вместе все трудности и усложнить модель. В другой раз стратегическими станут организация и упрощение. Иногда вам захочется описать свои потребности, а в другой раз вам нужно будет решить, как объяснить модель заказчику (пользователю).

Если в дискуссии у членов команды разные цели, то мало чего можно достичь. Никто не сможет сконструировать разумное описание технических моментов, если его прерывают люди, которые думают, что цель заключается в максимизации приемлемости для пользователя (maximising customer acceptability).