The Programmers' Stone (Программистский камень) - страница 33

Этот раздел целиком посвящен тому, насколько важно уметь смотреть на один уровень ниже, чем тот, на котором работаешь. Это справедливо несмотря даже на то, что сокрытие деталей реализации — это постоянная цель нашей работы. Чем лучше мы этого добиваемся, тем больше мы выигрываем, но мы еще не настолько умелы, чтобы забывать о нижних уровнях. Понимание того, где компилятор резервирует кучу и стек, позволяет нам обнаружить грубые ошибки, когда мы нарушаем модель языка. Знание имеющегося в нашем распоряжении объема физической памяти (и файла подкачки) позволяет нам писать программы, которые будут работать в ситуациях реального мира. Даже истинно виртуальные машины, такие как виртуальная Java машина, предоставляет сервисы настолько низкого уровня, что мы можем полагаться на то, что их создатели реализуют их разумно, чтобы мы могли предсказать эффективность наших операций.

В «Мифическом человеко-месяце» Фредерик Брукс (The Mythical Man Month by Fred Brooks) подчеркивает важность концептуальной целостности проекта. Наш глубокий взгляд на программирование предполагает некоторые практические пути достижения концептуальной целостности.

Во-первых, мы знаем о важности мысленных карт. Если каждый член команды разделяет внутренне согласованную мысленную карту создаваемой системы, то возможный вклад каждого будет соответствовать духу всей разработки. Если не разделяет, то не будет, поскольку руководство по стилю, достаточно подробное, чтобы позволить кому-либо сделать все правильно без знания того, что они делают, окажется гораздо сложнее в написании, чем сама система.

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

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

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