Пользователь
0,0
рейтинг
18 июля 2010 в 19:58

Разработка → Общие соображения по архитектуре ПО или Пособие для Главного Плотника (часть 4: про менеджмент)

Третья часть здесь

Часть четвертая, небольшая, последняя про менеджерские трюки:


Совместное владение кодом



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

Не знаю, как там у других (хотя финансовый кризис-2007 говорит, что у финансистов так же), а в нашем бизнесе чаще всего – «Мы – сборище опасных инфантильных маньяков, пишущих код, не приходя в сознание, и единственный способ убедиться, что код хоть как-то работает – каждому просматривать код каждого и иметь возможность код каждого члена команды изменить (если у того начнется сезонное обострение)». Звучит неприятно, но, увы, так оно и есть. Очень выпуклый пример, рассказанный человеком, пребыавшим в то время непосредственно в месте события.

Байка

Фирма Sun (которой теперь больше нет) делала платформу Java. И была в той платформе библиотека для создания Rich UI, называлась она AWT. Все было неплохо, однако сделать на AWT красивый современный интерфейс было можно, но на практике довольно сложно, поскольку AWT давал слишком уж низкий уровень взаимодействия с экраном. Sun наняли команду (работавшую на фирму Netscape, которой тоже больше нет), которая сделала им библиотеку Swing. У Swing есть свои проблемы, но она уже значительно лучше AWT. Проблема одна: Swing внутри устроена очень сложно, а команда, написавшая, ее больше на Sun не работает. В результате Swing существенно не развивалась и не улучшалась последние лет пять как минимум.


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

Баба-Яга против


Избегайте антипаттерна «Баба-Яга против». Если кто-то что-то делает по-своему, никого не слушает и всем недоволен, это значит, что:
1. у вас что-то придумано плохо, и ему реально неудобно;
2. он – свободный художник и «так видит»;
3. он в детстве хотел быть архитектором, а сейчас вы душите его инициативу;
4. еще какая-то ерунда.

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

Байка

В одной команде работал разработчик, который все время был чем-то недоволен, все время бурчал, жаловался, что «они все делают не так». При этом звезд с неба он не хватал. Получили ему как-то сделать форму для логина из трех полей: имя, пароль, экземпляр БД. Он сделал четыре поля. На вопрос начальника: «А почему так?» – ответил: «Ну, надо же мне как-то над собой расти». Ему высказали закономерные претензии по поводу качества исполнения работ, на что он послал начальника в пеше-эротический тур.

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

В тот раз все закончилось увольнением. Но, говоря по совести, меры приняли слишком поздно, ситуация была сильно запущена. То, что можно было вылечить антибиотиками, вылечили ампутацией.
Denis Tsyplakov @Semenych
карма
182,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (18)

  • +4
    Прочитал все четыре статьи, не жалею о потраченном времени. Спасибо
    • –1
      имхо раз одна за другой идет нужно было постить в обратном порядке =)))
    • 0
      Все 4 добавил в избранное, чтобы прочитать вечером, не успеваю сейчас :)…
  • +1
    ничего себе скорость постинга )
  • +1
    Вот вам в коллекцию баек:

    Не нужно делать программу слишком уж «на вырост». Будучи аспирантом, как-то за совсем небольшие деньги сваял я для одной фирмы небольшое веб-приложение на php и perl. Фирма принимала платежи за мобильную связь, оператор входил в мою программку через php-шный веб-интерфейс, вбивал платеж, а perl-овый демон шел с диллерским паролем к оператору и проплачивал. Ну, я думал, у них пара-тройка точек. Ну, десять. А еще я был перфекционистом и любил параллельное программирование. Все запросы на оплату засылались оператору параллельно. Сначала все было хорошо, но когда они решили, что все работает и внедрили это НА ВСЕХ точках… нет, моя программа работала четко… но сервер оператора стал падать по десять раз на дню, не выдерживая такого количества сессий :))
    • 0
      Как-то пришлось писать импортер в одну CRM написанную на Java. Набор данных довольно большой оказался и я сделал несколько потоков из PHP, в результате чего их сервер начал притормаживать. Пришлось писать в саппорт с просьбой ввести API для batch-запросов, на что они в виду возросшей нагрузки согласились. Благо, что все приложение проектировалось с IoC и изменения вносились очень аккуратно и быстро.
  • +1
    Эх, всё на одном дыхании, в четвёртом часу ночи перед днём рождения. Спасибо за такой слог и интересную тему!
  • +2
    Прочитал все. Очень хорошо написано. Обычно такие складные повествования только у иностранных авторов. Я так сразу вспомнил «The Pragmatic Programmer: From Journeyman to Master» от Andrew Hunt, которую уж трижды перечитывал.
    • 0
      Эта книга лежит у меня на столе сейчас. Там второй автор есть — Дэвид Томас.
    • 0
      Шикарная книга.
  • 0
    это было сильно, приходите еще :)
  • +2
    Спасибо за статьи, на хабре в последнее время действительно стало мало интересного. Плохо только что я из-за этого слишком засиделся за компом, давно спатки пора. :) Возможно я сейчас слишком сонный и просто не въехал в суть, но мне кажется, что четвёртая часть весьма спорная и неоднозначная, чего не скажешь про предыдущие три.

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

    Во-вторых, правда в том, что мы одновременно и «взрослые, высокопрофессиональные специалисты, каждые делает свою работу и отвечает за нее» и «сборище опасных инфантильных маньяков, пишущих код, не приходя в сознание». Польза от того, что одни маньяки просматривают, а то и меняют код других — весьма сомнительна, и чаще всего это приводит к сильным конфликтам, вред от которых для команды и проекта намного сильнее, чем польза от исправления чужого кода. Далее, что касается «единственный способ убедиться, что код хоть как-то работает – каждому просматривать код каждого», то это вообще чушь. Code review и прочее парное программирование действительно помогает обнаруживать множество ошибок на ранней стадии разработки, но основной способ убедиться, что код работает, и не «хоть как-то», а достаточно корректно — это тестирование. Если все работают над достаточно небольшими модулями/приложениями/сервисами, изолированными простыми и стабильными интерфейсами, то модули элементарно протестировать на корректность просто проверив их работу через интерфейс. И в этом случае действительно более-менее по барабану, что наш маньяк наваял внутри этого модуля/сервиса — разве что он жрёт слишком много общих ресурсов вроде памяти/проца, но это легко обнаруживается при мониторинге системы.

    В-третьих, проблему «бабы яги против» можно решить архитектурными мерами, а не управленческими — как я уже писал выше, к примеру, разработку небольшого сетевого сервиса с чётким простым интерфейсом можно без проблем поручать одному разработчику, и внутри своего сервиса он может ваять что ему угодно (в разумных пределах, разумеется, но ведь речь идёт как бы о «взрослых, высокопрофессиональных специалистах», так что ничего совсем уж дикого он не натворит).

    Резюмируя: в ситуации, когда команда разработчиков пишет код, который будет скомпилирован в один бинарник — Вы абсолютно правы. Но альтернативные архитектурные подходы, например сервис-ориентированная архитектура, в корне меняют ситуацию и описываемые Вами проблемы становятся не актуальны.
    • 0
      ну на самом деле там надо было больше и более внятно писать.
  • 0
    Спасибо огромное, давно не получал такого удовольствия от чтения статьи (:
  • 0
    Да уж, редко когда в последнее время на Хабре попадается возможность осознанно нажать на звездочку с целью потом перечитывать материал при необходимости еще не раз. А тут четыре части сразу, и одна другой краше.
    Колоссальное вам спасибо.
  • 0
    Ничего не остается как присоединиться с благодарностью.
  • 0
    Браво и спасибо. Очень интересно. Пожалуй это лучшее что я читал за последний месяц.
  • 0
    Одна из лучших статей, прочитанных мной за последнее время (среди «отечественных», пожалуй, лучшее). Спасибо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.