Петтери Сулонен, ведущий дизайнер программного обеспечения Avaintec
Писать код легче, чем читать. В частности, относительно легко написать код, который запускается и работает, но его трудно понять. Это потому, что компьютер рассматривает код как инструкции, в то время как люди думают в терминах идей — целей, средств, структур, которые взаимодействуют и сочетаются друг с другом для создания чего-то, что служит какой-то полезной цели.
Следствием этого является то, что по мере того, как программное обеспечение начинает накапливаться, оно оказывается запертым за отдельными людьми. Только человек, написавший код, знает, о чем он думал, когда его писал, а поскольку код написан так, что его мыслительный процесс не может быть легко реконструирован путем его чтения — или вообще вообще — переключение кого-то другого на работу на этот кусок кода дорого. Люди становятся пленниками кода, который они написали. По мере того, как эта динамика набирает скорость, вся команда становится более жесткой. Вы не можете заставить Андреа работать над проектом Kerbodyne, хотя ее навыки идеально подходят, потому что только она понимает Rockomax, хотя Набиль в данный момент свободен. На практике это будет означать, что Андреа будет назначена на Кербодин, но она будет постоянно возвращаться к Рокомаксу, который рассеивает ее внимание, снижает ее производительность и качество ее работы и делает ее несчастной — не говоря уже о Набиле, который сидит там и смотрит. в коде Rockomax чувствует себя действительно глупо, потому что он не может понять его, хотя он должен работать над ним.
Однако самым большим проигрышем из всех является проект Rockomax — Набиль будет вносить дополнения и изменения, не понимая, как они вписываются в единое целое, и не решаясь удалить то, что больше не нужно, а значит, кодовая база Rockomax раздуется, станет больше. энтропийный, еще труднее понять, медленнее и глючнее. Повторите этот цикл несколько раз, и вы получите большую кодовую базу, которую просто невозможно понять человеческому разуму, с отдельными кодерами, грызущими края в небольших областях, которые они знают эмпирическим путем.
«В конце концов, каждая программа становится рококо, а затем превращается в руины».
- Алан Дж. Перлис
Люди плохо справляются с многозадачностью. Конечно, у некоторых это получается лучше, чем у других, но всегда есть издержки, связанные с производительностью и качеством, и часто именно качество в конечном итоге оказывается дороже. Несколько удивительно, что команда, которая может легко переключать людей между проектами или продуктами, не обязана этого делать — во всяком случае, не так уж и много.Если, Каким-то образом Набиль мог реконструировать мыслительный процесс Андреа, когда он прыгал в проект Rockomax, что освободило бы Андреа для работы над Kerbodyne, и оба были бы продуктивны, счастливы и могли бы сосредоточиться на том, что они делают, несмотря на случайные вопросы.
Освободите свой код, остальное приложится
Как выразился Перлис в своей эпиграмме, естественная траектория каждого фрагмента кода ведет к рококо, а затем к руинам. В конце концов, это, вероятно, неизбежно — все, что складывается, непостоянно, как выразился другой знаменитый эпиграмматик, Будда. В долгосрочной перспективе каждый автомобиль будет ржаветь. Однако так же, как можно приложить усилия, чтобы поддерживать работу столетнего автомобиля, можно приложить усилия, чтобы не дать энтропии завладеть кодовой базой. Сила, которая блокирует код за отдельными программистами, — это энтропия, которая делает борьбу с энтропией ключом к гибкости команды. И наоборот, желание освободиться из тюрьмы энтропийного кода является мощным стимулом для дальнейшего отталкивания рококо.
«В уме можно отображать только сложную информацию. Подобно видению, движение, поток или изменение взгляда важнее статической картинки, какой бы прекрасной она ни была».
- Алан Дж. Перлис
Код — это не просто инструкции для компьютера. Это также — в больших проектах, возможно, в первую очередь — выражение идеи. Люди изобрели языки программирования для себя, а не для компьютеров: компьютер вполне доволен выполнением микрокода, переключением транзисторов в банках памяти. Оказавшись выше уровня «привет, мир», программист больше не должен писать для компьютера; она должна писать для людей. Точно так же, как при написании эссе, романа, стихотворения или пьесы, ее намерение должно состоять в том, чтобы выразить свои идеи другим людям настолько ясно, элегантно и понятно, насколько это возможно. Стиль имеет значение. Грамматические соглашения, форматирование и пунктуация имеют значение. IFI ПУСКАТЬ ПУНКТУАЦИЮ И БЕЛЫЕ СКОРОСТИ ОТ МОЕГО ПИСЬМА И СЛУЧАЙНАЯ МОЯ КАПИТАЛИЗАЦИЯ СТАНОВИТСЯ РАСШИРЕННО СЛОЖНЫМ.
От порочного к добродетельному циклу
Естественная траектория программы к рококо и щебню проистекает из цикла обратной связи. По мере того, как фрагмент кода, который вначале, возможно, немного труден для понимания, модифицируется под давлением и разными людьми, он с каждым разом становится немного сложнее и труднее для понимания. Незаметно проходит критическая точка: теперь уже невозможно работать над этим без активного участия оригинального автора. В какой-то момент он пересекает невидимый горизонт событий, где становится непонятным даже для первоначального автора, и с ним можно работать только эмпирически, внося коррективы, а затем проверяя, что произошло. На тестирование и отладку тратится все больше и больше усилий, но цикл уже не остановить. Система набирает скорость, входит в атмосферу и в конце концов распадается эффектным шлейфом плазмы и подпрограмм.
У этого порочного круга есть зеркальное отражение: благотворный цикл, в котором различные методы и стимулы усиливают друг друга, чтобы поддерживать программу на высоте. Это требует изменения мышления с самого начала.
- Сначала пишите код для людей, потом для компьютеров. С самого начала часть кода должна быть написана для других людей. Это не делается, когда он работает, не дает сбоев или безопасен; это делается только тогда, когда кто-то другой может прочитать это и реконструировать мыслительный процесс того, кто написал это в первую очередь. Именование, стиль и соблюдение общего соглашения даже важнее, чем эффективность, производительность или соблюдение функциональных или нефункциональных требований: если код понятен, можно повысить эффективность и добавить функциональные или нефункциональные функции. но если это не так, это становится на порядки сложнее.
- Сначала общайтесь горизонтально, потом вертикально. Ежедневно делитесь тем, что вы делаете, с другими членами команды, как на формальных контрольных точках, таких как ежедневная схватка, так и, что, возможно, более важно, неформально. Если вы чувствуете, что застряли, как сверстник за помощью. Если код, над которым вы работаете, был написан для людей, вам не нужен автор, чтобы разгадать его: вам просто нужно время, терпение и, возможно, вторая или третья пара глазных яблок. И наоборот, строгие вертикальные задачи или роли, особенно если они воспринимаются как препятствие для помощи друг другу, усиливают блокировку автора.
- Поддерживайте неустанное давление со стороны коллег в отношении качества. Код, который не соответствует согласованным стандартам, недопустим. Людям для этого не нужна угроза наказания или жесткие санкции: достаточно, если достаточное количество людей в команде просто скажет «это не нормально», увидев несоответствующий фрагмент кода. Мы социальные приматы, и если в команде есть четкие социальные нормы, подчеркивающие качество, ясность и стиль, большинство из нас приложит все усилия, чтобы соответствовать им.
Достаточное количество может варьироваться. Одного редко бывает достаточно. Двое могут быть, если они пользуются уважением команды. Больше хорошо. Все лучшие. - Полировка вещей – это не роскошь, это необходимость. Слишком часто программисты говорят, что у них не было времени дорабатывать что-то после того, как они запустили его: вместо этого оно было просто отправлено через контроль качества и запущено в производство в том состоянии, в котором оно есть, /** НЕ ДЛЯ ПРОИЗВОДСТВА, ТОЛЬКО ДЛЯ РАЗРАБОТКИ. ! **/ комментарии и все такое. Это классическое копеечное, глупое мышление, потому что время будет найдено, когда оно сломается, что неизбежно произойдет — даже хорошо написанный код делает это. И эта срочная работа займет намного больше времени, когда произойдет неизбежное.
- Передавайте вещи: нечасто, ответственно и с достаточной поддержкой, но передавайте вещи. Если вы никогда не сдадите вещи, неизбежно последует авторская блокировка. Очень немногие программисты достаточно дисциплинированы, чтобы писать для себя в будущем, уделяя такое же внимание ясности и стилю, как когда они знают, что пишут для своих товарищей по команде, особенно если упомянутые товарищи по команде любят придираться к качеству. И наоборот, энтропия, турбулентность, рококо и руины последуют, если люди перескакивают с задачи на задачу и планируют проект быстро и неконтролируемо или пытаются работать над несколькими вещами одновременно.
Передача вещей
Передача требует времени и усилий. Человек, который возьмет на себя управление, должен будет проникнуть в кодовую базу, изучить ее, возиться с ней и медленно реконструировать лежащие в ее основе идеи. Как бы ясно ни был написан код, для этого ему потребуется поддержка оригинального автора. Это время и усилия необходимо учитывать при планировании передачи: получатель должен сразу же приступить к работе над кодовой базой, но первоначальный автор должен быть готов ответить на вопросы и разъяснить свои мысли. Передача — решающий этап, который замыкает цикл и начинает создавать по-настоящему гибкую команду. Чем более понятным для человека будет передаваемый код, тем менее болезненными будут передачи, а регулярные передачи будут усиливать необходимость написания удобочитаемого кода.
На пути к действительно гибкой команде
Регулярная контролируемая передача кода, написанного для людей, будет постепенно распространять знания в команде. Со временем все больше и больше участников будут работать и знакомиться с постоянно расширяющимся разделом кодовой базы, и перемещаться по нему будет все легче и легче. Этому есть предел — в конце концов, человеческий разум нельзя бесконечно расширять, — но этот предел гораздо выше, чем вы могли бы ожидать. Возможна по-настоящему гибкая команда, члены которой относительно легко перемещаются по кодовой базе и где со временем все становится проще, а не сложнее. Мы, команда разработчиков Avaintec, уже много лет усердно работаем над достижением этой цели, и результаты стали ощутимыми. Мы можем перераспределять ресурсы между продуктами и проектами, не совсем безболезненно, но, по крайней мере, не вызывая значительного снижения производительности и энтропии каждый раз, когда это происходит. Все, что для этого потребовалось, — это перейти от написания кода для компьютеров к написанию кода для людей и несколько лет практики.
