Когда над одним и тем же проектом (кодом) работает несколько людей, процесс разработки ПО начинает значительно отличаться. С этим фактом нельзя не согласиться. Вступает в действие целый ряд дополнительных факторов. Общим результатом является понижение скорости разработки, а иногда может понизиться и качество разрабатываемого ПО.
Как же быть тогда? Ведь есть проекты, которые в одиночку написать невозможно. В этой статье я попытаюсь показать один психологический аспект работы в команде программистов. Я вас вооружу некоторыми теоретическими знаниями, благодаря которым вы сможете повысить эффективность программистов и их общий эмоциональный фон.
С чем же связано снижение эффективности и качества ПО?
Факторы снижения эффективности программистов можно поделить на объективные и субъективные.
Субъективные факторы влияния на эффективность
Отбрасывая банальную межличностную неприязнь, предположим, что в нашей ситуации мы имеем коллектив из нескольких программистов с достаточным уровнем эмоционального взаимопонимания и уважения. Тем не менее, даже в таком коллективе могут быть проблемы.
Дело в том, что программист развивает чувство собственности к коду. Ведь код — это нечто, что он создал, и это нечто осязаемое (его видно на экране монитора). Программист может воспринимать код, как предмет (это я написал этот код) и как пространство (когда у меня в редакторе открыт этот код, я чувствую себя уютно). Таким образом код может быть «моим», «не моим» точно так же, как и стул или как комната. Это мой стул, и я на нем сижу (я написал этот код). Это стул Васи, и Вася им пользуется, и мне на нем сидеть эмоционально неудобно (Вася написал этот код).
Я хочу подчеркнуть, что мы сейчас говорим о субъективной самоидентификации программиста с кодом, который он видит на своем экране.
Программист, работая, может ощущать что этот код «его» или «не его». Эта самоидентификация с кодом довольно важна. Если человек считает, что код «его», то он:
- не будет ощущать отторжения (нечто вроде «свое говнецо не так сильно воняет»)
- общее эмоциональное ощущение программиста будет приподнято. Он будет ощущать себя в зоне комфорта и «у себя дома» (подумайте как он себя будет ощущать, работая с «чужим» кодом… 8 часов в день… несколько месяцев подряд)
- у него возникнет чувство хозяина и владельца (еще примитивнее: чувство вожака, все-таки в основном программисты — мужчины). Эти чувства провоцируют мужчину к проявлению инициативы, ответственности и проактивной позиции по отношению к объекту собственности (к коду, в нашем случае)
- в «моем» коде не страшно делать рефакторинг. Нечто вроде «это моя собственность, и я делаю с ней все, что хочу»
- дорабатывая «свой» код, программист сделает ровно столько изменений в коде, сколько нужно для внесения необходимых корректировок и поддержания архитектуры кода. А вот если код был бы «чужим», то программист скорее всего постарался бы внести минимум необходимых изменений. Добавляя функционал, но не поддерживая архитектуру, он скорее всего «прилепил» бы новый функционал сбоку к уже существующему.
- людям свойственно осторожничать в чужом/новом месте: если от программиста потребуется внести существенные изменения в «чужой» код, то он потратит много времени на ознакомление с кодом (попытается сделать этот код «своим») и банально будет ощущать себя более скованным в эмоциональном плане, внося нужные изменения. В худшем случае он просто «прилепит» свой код к уже существующему (см. предыдущий пункт)
- правя «чужой» код, мы эмоционально затрагиваем его владельца. Сознательно или подсознательно, но программисты признают право собственности других программистов на участки кода точно так же, как в семье за обеденным столом негласно признается место за каждым членом семьи. Сознательно садясь на «чужой» стул за столом, вы ощущаете дискомфорт из-за оказанного эмоционального влияния на «владельца» стула.
Также, отдельно замечу, что мы сейчас говорим о правках в коде. Чтение кода и особенно использование (вызов «чужих» функций) не влияет на эмоциональное состояние программистов.
Объективные факторы
Есть еще и объективная составляющая: может быть так, что программист знает этот код, или не знает этот код. Под «знать код» я подразумеваю помнить названия функций и что они делают. Не трудно заметить, что эти знания действительно объективны — они либо есть, либо нет, и не важно как себя ощущает наш бедный подопытный программист. Для того, чтобы внести правильные изменения в код, человек должен объективно знать его.
Конкретика и постановка задачи
Что же имеем? Теоретическое идеальное состояние для проекта было бы: все программисты объективно знают весь код и все программисты считают весь код «своим». Но скажите мне, пожалуйста, может у одной зубной щетки быть 2 хозяина? К сожалению, нет. Любой программист «трогая», внося изменения в код, делает этот код более «чужим» в глазах автора кода («текущего» владельца).
Цель: каждый программист должен работать (максимум возможного времени) с кодом, который он знает, и который он считает «своим». Вот такого результата уже возможно добиться.
Решение задачи
В процессе разработки ПО объективные знания о проекте и субъективные самоидентификации программистов к коду будут меняться. Нашей задачей будет влиять на распределение знаний и чувств собственности с тем, чтобы поддерживать поставленную в прошлом абзаце цель. Чем больше программист знает о проекте или чем больше кода он считает «своим» — тем лучше. Кашу маслом не испортишь. Понижать эти вещи нам не за чем, а вот повышать всегда полезно.
Другое дело, что повышение этих факторов отнимает время у наших программистов. И тут уже встает вопрос рационализации: программисты могут тратить 2 ч в день на знакомство со своим проектом и 2 ч в день на повышение чувства собственности… Но ведь тогда у них будет лишь 4 ч в день на продуктивную работу :(.
Прежде чем мы перейдем к вопросам рационализации, давайте рассмотрим рычаги влияния. Для повышения объективных знаний о коде подходят:
- самый проверенный способ — быть автором кода :)
- любая письменная документация о коде
- устные и письменные коммуникации между программистами
Для повышения чувства собственности по отношению к коду подходят следующие методы:
- опять же, способ №1 — быть автором кода
- объективные знания о коде. Все-таки проще признать за «свое» ту вещь, в работе которой ты хотя бы разбираешься
- code reviews — когда автор кода показывает код и советуется с другим программистом, этот другой программист оказывает влияние на код (возможно даже некоторые его советы попадут в код). Своеобразно, автор «знакомит» второго программиста с кодом и возникает некоторого рода собственность «наше».
- придерживание стандартов оформления кода повышает чувство собственности «мое» среди всех членов команды, но тут есть свои оговорки (о них ниже)
Отдельный абзац о стандартах оформления кода (еще один способ повышения чувства собственности, просто слишком длинный)
Стандарты оформления кода (какие бы они не были) в основном преследуют цель унификации внешнего вида кода. Так они облегчают чтение кода, и так же они способствуют повышению самоидентификации программиста с этим кодом, даже если он его первый раз видит.
О! Написано так, как будто я писал
или
О! Смотри, а он тоже жигулевское пиво любит, и диван у него такой же мягкий как у меня дома! Мне здесь уютно!
Но не тут-то было. Код может быть оформлен идентично, но вот логика, которой следует код, будет отличаться от той, которую использовал бы наш подопытный программист (наш программист тут бы использовал while цикл, а в коде написан foreach). Эти разницы между логикой кода и логикой того, кто читает этот код, и приводят к тому, что чувство собственности в итоге не создается. Вот поэтому требования к оформлению кода не дают полного ожидаемого результата с одной стороны, с другой стороны они в определенной мере сковывают свободу программистов и добавляют еще один слой бюрократии.
Одним из решений было бы заставить всех программистов думать одной и той же логикой, насаждать одну и единственно правильную логику (или детализировать требования к оформлению кода вплоть до того, когда использовать while, а когда использовать foreach). Но ведь это утопия. К тому же, все люди разные, и зачем «клонировать» 10 программистов под копирку.
Лучше культивировать взаимопонимание среди программистов и помогать им знакомиться с логикой своих коллег-программистов. В частности, code reviews, могут весьма хорошо заставить программистов узнать логику друг друга. Волшебство code review в том, что программисту Васе достается в руки код, написанный программистом Петей, но Вася не должен ничего в нем править. Он лишь изучает труд Пети и после этого рассказывает Пете свои мысли (Вася предлагает Пете что-то изменить в обеденном стуле Пети, но сам стул не трогает). Пока Вася и Петя общаются, они успевают понять как и что обоим из них нравится. Таким образом в будущем Вася, видя код Пети, уже будет ощущать себя намного уютнее, зная логику Пети.
Вопросы рационализации
Как же найти баланс между тем, чтобы программисты продолжали развитие проекта, но в тоже время всегда работали над кодом, который они чувствуют «своим»? Ответ на такой вопрос будет очень сильно зависеть от контекста. Я вам лишь покажу 2 самых радикальных метода, и вряд ли эти 2 крайности когда-либо будут уместны для использования в живой ситуации, скорее вам нужно будет найти баланс между этими 2 противоположностями.
Способ №1. Разделение ответственности и «личные комнатушки»
Если специфика вашего проекта позволяет:
- четко разбить проект на несколько подзадач, практически невзаимосвязанных друг с другом
- иметь незаменимых программистов (если программист уйдет, то проект разрушится или очень сильно пострадает),
то дайте вашим программистам маленькие норки, где они будут единственными хозяевами ситуации. Вам нужно будет лишь четко условиться о том, как эти «норки» будут взаимодействовать друг с другом, а внутреннюю реализацию каждой норки возьмет на себя ее «хозяин» (ответственный программист).
Это довольно радикальный подход, и поэтому он обладает довольно существенными недостатками:
- у вас будут незаменяемые программисты (если хозяин норки уйдет, то сопровождать эту норку кому-то другому будет трудно)
- если все, кроме одной «норки», будут готовы, то уже завершившие работу программисты не смогут толком помочь программисту, который отстал от графика, т.к. не знают специфики «норки» и скорее лишь будут раздражать программиста
Плюсы:
- можно обойтись без документации внутри-норковых процессов. Т.к. одну норку поддерживает один программист, то он все это может удержать у себя в голове
- программисты практически не тратят время на коммуникацию
Способ №2. Форум
Форум — площадь для массового общения. Так же и ваше ПО можно превратить в площадь для массового общения, когда все будут знать все части проекта и будут очень плотно взаимодействовать друг с другом. Плюсы и минусы этого метода — это, практически, инверсия плюсов метода «личных норок».
Заключение
Помимо правильного распределения программистов и коммуникации между ними, так же еще важно брать во внимание способ менеджмента и развития проекта. Ожидается ли часто менять вектор развития и часто менять текущие задачи проекта? Зрелый ли это проект? Берите во внимание особенности ваших программистов, может быть среди них есть гений, но он просто-напросто под громадным количеством бюрократии не может разогнаться и взлететь ввысь? Насколько вы уверенны в ответственности ваших программистов и в том, что они не уйдут от вас на полпути? Думайте и решайте.
Автор: bucefal91
