Programmer Insecurity

Programmer Insecurity/Комплексы Программиста

Перевод статьи «Programmer Insecurity/Комплексы Программиста» , выполнен сообществом компании «Заказные ИнформСистемы».

Я хотел бы о многом сегодня поговорить. Поговорить о том, что я никогда прежде не замечал, хотя вероятно, должен был заметить.

Всегда был стереотип, что программисты асоциальны:

 Q: How do you know when an engineer is outgoing?
 A: He looks at your shoes!

Но на этой неделе я обнаружил, что большинство программистов и на самом деле очень закомплексованы, причем в своей же работе! Повторюсь: ужасно закомплексованы!

Мой приятель Фитц и я долго проповедовали о best practices в разработке приложений с открытым исходным кодом — когда человек должен быть открытым и честным с работой другого, воспринимать разбор своего кода и уметь конструктивно критиковать, и, главное, активно общаться с коллегами.

Один из антипаттернов, о котором мы говорили — это люди, пишущие «кодовые бомбы». То есть, что вы делаете, когда кто-либо показывает вам огромную новую фичу в open source проекте, написание которой заняло месяцы?

У кого есть время, чтобы отрецензировать тысячи строк кода? А что, если там были неправильные архитектурные решения с самого начала? Есть ли теперь смысл указывать на это?

Сбрасывание такой «кодовой-бомбы» в сообщество, редко когда идет проекту на пользу: команда либо должна либо полностью отклонить ее, либо принять и иметь дело с гигантским мутным BLOB-ом, который трудно и понять, и править, и поддерживать. К тому же, это явно двигает проект в некотором направлении без всяких обсуждений или консенсусных решений.

И все же снова и снова я слышу истории, которые указывают на тот факт, что программисты не хотят писать код в открытую — они, видите ли, не хотят, чтобы коллеги видели их ошибки и неудачи.

Они хотят работать одни, в пещере, и только потом открыть сообществу свой «идеальный» код, как будто бы в нем никогда ошибок и не было.

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

Похоже, они охотно делятся кодом, только когда могут показать, что они «непогрешимы». Хотя, возможно это в природе человека.

Оцените несколько историй, которые я собрал:

Просьбы на конференции «Google I/O»

 Пару недель назад, когда моя команда была на конференции «Google I/O»,
 мы поставили демонстрационный стенд, посвященный сервису поддержки проектов с открытыми исходными кодами.
 Раз за разом, мы получали просьбы типа:

• «Ребят, вы можете заставить Subversion в Google Code возможность прятать определенные ветки?»
• «Парни, а можно создавать открытые проекты поначалу скрытые от мира, а потом раскрыть их, когда они будут готовы?»

По сути, они говорили одно и то же: «Я не хочу, чтобы люди видели процесс моей работы, пока она не стала идеальной»

Просьбы в список рассылки Google Code

• Почистить так или иначе svn-репозиторий на Google Code. Встречаются и разумные причины — например, случайный коммит секретных данных, или необходимость загрузить полностью историю из другого SVN-репозитория.

Но в основном, мы получаем некорректные (да, мы их отклоняем) просьбы вроде «Привет, я хочу переписать свой код с самого начала. Вы могли бы уничтожить историю?». Это значит «Я не хочу, чтобы люди увидели мой старый код, мне так за него стыдно!»

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

Код-ревью воспринимаются как личные нападения

Фитц рассказал смешной анекдот о своем друге, который перешел из мира open-source в корпоративную разработку. Перескажу своими словами:

В течение первой недели он начал рассылать дружественные рецензии на исходники каждого из сослуживцев, получая странные пристальные взляды в ответ. Наконец начальник вызвал его к себе: «Знаешь, тебе пока заканчивать с этой негативной энергией. Твои напарники говорят, ты критикуешь все, что они делают».

Мораль: рецензии кода далеки от стандартной практики в корпоративном сообществе, более того, большинство программистов не способны отделить свои хрупкие «Я» от кода, который они пишут.

Повторяйте за мной: ты это не твой код!

Использовать распределенный контоль версий — быть в пещере

Один мой друг работает над несколькими проектами, в которых используют git и mercurial. Недавно он рассказал мне следующую историю.

В основном, он работал с двумя командами над проектом.

Одна команда часто публиковала изменения… «… в результате у меня была возможность постоянно просматривать их проект в течении семестра, регулярно предлагая улучшения дизайна и предоставляя рецензии на код… …В результате этого [их проект] развивается на полном ходу и практически функционирует.

Другая группа… Я не слышал от нее и писка за последние 5 месяцев. Несмотря на множество писем и обсуждений в IRC, призывающих их обсудить их дизайн и регулярно публиковать изменения, мне не дали увидеть ни одной строчки. […]

В прошлое воскресенье один из них зашел ко мне с багом […] и я наконец смог увидеть код, чтобы помочь отладить его. Это мне не удалось, потому что там были 5000 строк мусорного кода, и просмотр лишь одного файла выявил две или три серьезных ошибки в проектировании и дюжину сыро реализованных мест.

Я убеждал их много раз в течение этих 5 месяцев публиковать свои изменения, так, чтобы мы (другие) могли посмотреть и предложить обратную связь, но каждый раз, в ответ была сплошная тишина.

Я не знаю, боялись ли они опубликовать это, или только не заботились об этом. Но так или иначе, учитывая код, что я видел, практический результат составляет 5 потраченных впустую месяцев.»

Прежде, чем Вы начнете возражать — да да, я знаю, что потенциально cave-hiding («разработка в тайной пещере») и написание кодовых бомб возможно и с использованием централизованной системой управления версиями, такой, как Subversion.

Но у моего друга есть интересная точка зрения:

Я думаю, что этот недостаток имеет место по крайней мере частично из-за того, что DVCS даёт легкий способ обнести себя стеной и забраться в пещеру. Если бы мы использовали svn, я думаю, что «пещерный» барьер был бы слишком высок, и я сразу бы увидел этот код.

Другими словами, да, это было бы в основном социальной проблемой. Команда запуталась в распределении кода.

Но, так как они использовали распределенное управление версиями, у них возникла видимость ложной безопасности.

«Смотрите, мы коммитим изменения в наш репозиторий каждый день … прогресс!»

Если бы они использовали Subversion, то гораздо менее вероятно, что они сидели бы над патчем из 5000 строк в их рабочей копии в течение 5 месяцев; они должны были бы показать работу намного раньше.

Мораль: даже при том, что нельзя расчитывать на технические решения социальных проблем, используемые инструменты имеют большое значение.

Это было моей главной темой ранее, когда я написал о рисках распределенного управления версиеями.

Хорошо, так, каково заключение? — Просто очевидно, что люди боятся показывать незаконченную работу.

Я знаю, что это далеко не новость для большинства людей, но я долго этого не осознавал. Я так привык подвергать свое творчество постоянной критике со стороны, что просто ожидаю того же от всех остальных.

Я рассматриваю это как норму и не могу понять, почему кто-то не хочет этого делать. Более того, растущая популярность распределенного контроля версий показывает, насколько сильно люди стремятся спрятать свой код друг от друга.

Вот классическая «рекомендация» для системы вроде git (взято из комментария в блоге): «Не надо говорить мне, что я должен сотрудничать с другими людьми в начале и публиковать мои изменения как можно раньше. Я сотрудничаю с другими людьми, но иногда хочу делать определенную часть работы в одиночку.»

Хм, ладно! Только не работай в одиночку слишком долго!

Немного отступая от основной темы, скажу почему я предпочитаю Mercurial Git-у, проделав некоторые исследования и прочитав немного об этих системах.

Git гораздо более склонен к «пещерности», а я этого не люблю.

Например, команда «git rebase» — это средство, позволяющее эффективно уничтожать целые ветки истории: очень мощное, конечно же, но это в то же время и способ стирания собственных следов. Вместо того, чтобы соединить вашу ветку с родительской, она «притворяется», что ваша ветвь всегда была основана на самой последней родительской ревизии.

Другой пример: когда приходит время отправки и получения наборов изменений, поведение по умолчанию для Mercurial состоит в том, чтобы обменяться историей с удаленным репозитарием, тогда как git в этом случае только отправляет и получает отдельную ветвь — предположительно ту, которую пользователь счел нужным сделать общедоступной.

Другими словами, git по умолчанию считает, что вся работа «пещерная», и с радостью уничтожает историю. Mercurial же по умолчанию разделяет все, и не может стирать историю.

Я знаю, этот пост получился очень длинным, но дайте мне еще постоять на трибуне из ящика из-под мыла:

• Будьте ясными.
• Постоянно публикуйте свою работу.
• Приветствуйте обратную связь.
• Воспринимайте критику.
• Дайте возможность другим людям найти ваши ошибки.
• Ваш код — это не вы сами.
• Не бойтесь ежедневных ошибок — учитесь на них (Как говорят в Google, «не беги от ошибки — ошибайся часто, быстро, и учись!»).
• Храни всю свою историю, и удачи, и ошибки.

Все эти приемы — путь совершенствования в программировании. Если вы не следуете им, вы обманываете свое собственное развитие.

Уф-ф! Теперь я чувствую себя лучше.

Ссылки

---

Репликация: База Знаний «Заказных Информ Систем» → «Programmer Insecurity»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».