Завяжите шнурки и подтяните свои штаны!

Original author: John Sonmez
  • Translation
Итак, что же замедляет разработку программного обеспечения?

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

И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?

Казалось бы, положение должно улучшаться, ведь Вы уже давно в проекте, разве нет? Почему всё происходит наоборот?



В поисках ответов


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

Если бы мы знали ответы на все вопросы, то и проблем бы никаких не было.

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

И в первую очередь все начинают винить процесс. Ведь очевидно, что проблемы с процессом негативно влияют на скорость разработки.

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

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

Рассматриваются и такие варианты:

  • Парное программирование?
  • Сменим скрам на канбан?
  • Разве мы не должны определять бэклог иначе?
  • Может нам стоит использовать попугаев для оценки задач? Стори поинты? Или вообще пусть все бэклоги будут одинакового размера?
  • Нам нужно больше девелоперов? Или бизнес аналитиков?
  • Стоит ли реорганизовать команды?

Конечно, это всё замечательные вопросы, которые следует время от времени себе задавать, однако я постоянно убеждаюсь в том, что есть другая позабытая проблема побольше…

ВАШ КОД!




Давайте проведём небольшой эксперимент.

Забудем обо всех процессах, забудем о скраме и бэклогах и стори поинтах и всём-всём остальном.

Вы — Разработчик. Вам надо сделать поставленную Вам задачу, изменить кое-что в коде. Вы сидите один, нет никаких процессов, аналитиков. Только Вы и Ваша работа.

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

Наверняка у Вас будут примерно такие мысли:

1. Эта фича имплементится быстро и просто, я знаю как и куда её добавить, всё будет тип-топ!

Вот так, замечательно! Выходит, на самом деле у Вас нет никаких проблем.

2. Что-то я не понимаю, что надо сделать. Как и где это будет использовано в системе?

Хм, в таком случае у Вас, скорее всего, присутствуют кое-какие проблемы с процессом. Может быть Вам нужна постановка задачи почётче или следует задать больше вопросов. Такое случается, правда. Идеи-полуфабрикаты попадают в процесс и кому-то определённо придётся побегать и пошевелить мозгами прежде чем разработчики на самом деле смогут заняться ими.

3. Я боюсь что-то менять, это почти невозможно. Прежде чем начать, понадобится копать в других частях приложения и разбираться: что, как и почему так работает (и как оно вообще должно работать).

Как не печально, но это наиболее вероятный исход. Что-то среднее между вторым и третим пунктом, потому что у них одна и та же причина — готовый код и либо усопшая, либо «её-нет» архитектура.

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

Но подобные проблемы Вы увидите только в успешных компаниях, потому что…

Иногда необходимо бежать с развязанными шнурками


Было время, я консультировал пару провальных стартапов. И должен заметить, у них была одна общая черта (как в прочем и у большинства других стартапов): ноль проблем с кодом. Да-да, отличная кодовая база, причёсанная, ухоженная, пахнет приятно.

Я видел самую лучшую архитектуру и идеальный код в умерших стартапах.

Может быть это выглядит так, будто я противоречу сам себе. Сейчас поясню.

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

Что происходит? Они создают прекрасный код, клёвую архитектуру. Но слишком поздно. Конкуренты вырываются вперёд и двое обкофеиненных не-совсем-программистов-но-я-чуть-кодил бодро обходят Вас со своим приложением на VB6, написанным прошлой ночью на коленке. Да, может не совсем то, что хотел заказчик, но зато как оперативно!

Но что, я разве теперь утверждаю что надо написать салфеточный говнокод и быстренько сдать его, иначе провал?

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

Нет. Но я пытаюсь сказать что большинство успешных компаний в первую очередь вовремя сосредоточили свои усилия на заказчике и только затем на ПО.

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

Так, а что насчёт штанов?




Окей, к чему я всё это?

Компании-победители бегут и выживают! Однако и после 5 лет они всё ещё продолжают бежать изо всех сил и тут их некрасивые шнурки начинают развязываться.

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

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

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

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

Со стороны это всё выглядит очень позитивно. Они краснеют, выкладываются на полную для того чтобы продолжать бежать с прежней скоростью, но спущенных штанов и развязанных шнурков вполне достаточно для того чтобы бег превратился в неуклюжую быструю ходьбу. Старушка с грузиками на лодыжках даёт им фору, но они всё ещё слишком заняты, чтобы сделать передышку и подтянуть эти штаны! И с прошлого раза ещё не наверстали!

И тут они начинают думать. Что же делать? Как решить проблему, не сбавляя скорости и не подтягивая лишний раз штаны? Начинается импровизация. Они пытаются прыгать. Кому-то в голову даже взбредает идея что нужно больше ног… =)

Я думаю, Вы уловили мысль. На самом деле, нужно всего лишь…

Остановиться, завязать шнурки и подтянуть наконец свои штаны!


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

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

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

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

Возможно, Вы начнёте с нуля. Возможно, придётся объединить все свои силы, чтобы привести всё в порядок. В любом случае, Вам придётся остановиться. Хотя может быть кто-то пробовал завязывать шнурки на бегу? =)

Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились. Только не игнорируйте свои штаны, в которых Вы путаетесь на каждом шагу, сделайте что-нибудь страшное!

Прим. перев.: я не переводчик, я такой же как и все, поэтому вышел более-менее вольный перевод. Старался передать ироничность статьи. Об опечатках и недочётах пишите, пожалуйста, в личку. Спасибо за внимание и хорошего дня!
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 40

    +3
    Это грустно но правдиво.
    Именно поэтому в сфере программного обеспечения больше нет и скорее всего в ближайшее время не будет качественных продуктов. Причем это утверждение касается и веб аппликаций тоже. Почти. все что касается коммерческого софта ущербно. Но к счастью есть еще конкуренция со стороны opensource, хотя опенсорс проектам требуется гораздо больше времени на раскрутку, так что не все так плохо.
      +3
      Ерунда, извините :) Качественных вещей в природе нет, все ломается. И всё испортили не жадные программисты, так миру устроен.
        +5
        :) Холодильник «Днепр» мои родители купили когда мне было 6 лет. Теперь мне 40, а он РАБОТАЕТ у них на балконе.
        www.google.com/search?q=%D1%85%D0%BE%D0%BB%D0%BE%D0%B4%D0%B8%D0%BB%D1%8C%D0%BD%D0%B8%D0%BA+%D0%B4%D0%BD%D0%B5%D0%BF%D1%80&hl=en&client=firefox-a&hs=59H
        И речь не о программистах.
          +1
          Мне кажется, Донбасс сделали в качестве послания в будущее, только вместо бестолковых глиняных таблиц и сапфировых дисков — вещь, которая хранит вечную потребность человека, и потому будет вместе с ним до конца.
        0
        Это смотря с какой позиции смотреть на качество. Если с точки зрения кода, возможностей быстро добавить ресурсы и аккуратно вставить новую фичу, то да. А с точки зрения удовлетворения быстро меняющихся потребностей пользователя (программы же для юзеров пишутся, не так ли?) до определённой степени разрастания проекта говнокод будет более качественным. Потом он превратится в кашу, в которой сам чёрт ногу сломит, и добавить новую фенечку для пользователя или найти баг будет уже крайне трудно.
        +27
        Двое мужиков стоят пилят дерево тупой пилой. День пилят, второй пилят, третий…
        Мимо проходит третий мужик и говорит:
        — Пацаны, вы бы пилу заточили…
        — Некогда, мужик, пилить надо!
          –4
          На мой взгляд, некорректное сравнение. Тупая пила будет долго пилить прямо со старта, и «остропилы» заведомо проиграют. А здесь за счёт ущерба качеству кода повышается стартовая скорость.
            +3
            Сорри… «Тупопилы» заведомо проиграют.
              0
              Никто не выиграет и не проиграет. Просто тупопилы сделают хреновый продукт. Стоимость поддержки и дальнейшего развития которого будет выше чем стоимость его первичной разработки.
                0
                В сравнении тупопилы не сделают вообще ничего или будут делать с самого начала медленнее, чем все остальные — просто потому, что пила тупая. А в статье шабашники сначала будут работать и давать нужный рынку результат быстрее профессионалов, пока «штаны не сползут».
                  +1
                  Давайте предположим, что в анекдоте сначала пила была острая :)
              +1
              корректным оно станет, если добавить что когда-то начали пилить они острой пилой
            +3
            Почему же никто не читает теги? Теги очень даже полезны в том случае, когда хочется узнать о чем же статья не читая саму статью.
              +1
              Тогда понадобится очень много тегов =)
                0
                Избыток тегов лучше чем их недостаток, надо просто размещать их в порядке убывания важности
              +2
              Прелесть разработки в том, что можно практически не останавливаться. Править баги, добавлять фичи, в общем бежать вперёд можно параллельно с рефакторингом, лишь иногда делая короткие остановки для синхронизации старого кода и отрефакторенного. Посмотрите на автогонки типа Формулы-1: автомобили останавливаются чтобы сменить резину, но их ждёт команда, у которой всё готово для этой замены, и она происходит за считанные секунды. Все решения приняты в фоне процесса собственно гонки, процесс замены отработан практически для автоматизма.
                +1
                Если долго жить без рефакторинга, то мелкими порциями уже будет почти невозможно выправить. Придётся-таки остановится на крупный.
                  0
                  Ключевая фраза в моем первом комменте «можно параллельно», вплоть до найма сотрудников которые только рефакторингом и будут заниматься. Собственно сейчас примерно этим и занимаюсь, да ещё в более извращенной форме.
                    0
                    Ну тады соглашусь
                0
                Нашел ответы на некоторые свои вопросы… Спасибо за перевод.
                  0
                  Рад, что Вы нашли время на прочтение =) Спасибо
                  0
                  Очень интересная точка зрения, а метафора так вообще отлично вписалась. Спасибо за перевод.
                    +2
                    Если команда не сидит сложа руки, а важные задачи правильно приоритезированы, то вероятнее всего процесс не виновен.
                    Вот отсюда следует, что как бы процесс — это чтобы команды не сидела сложа руки и задачи были приоретизированы и все. Но это не так.

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

                    Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились.
                    Вот именно что такой подход даст возможность выжить конкретному руководителю, который высоким темпом работы сейчас прикрыл свою некомпетентность. Проект все равно проиграет.
                    Профессиональная работа — это поддержание устойчивого шага в ходе проекта и создание условий для его контролируемости. А бежать вперед подтягивая штаны — это не из разряда «я всех обгоню», а из разряда «доползу до финиша, куплю новые шмотки, буду выступать за другой клуб, а старые доносит кто-нибудь другой».
                      0
                      И в первую очередь все начинают винить процесс

                      Полностью с этим соглашусь.

                      Занимаюсь консультированием IT-компаний и за 3 года понял, что когда винят процесс, то в 90% случаев лучше сначала взглянуть на код.
                        +1
                        Если у вас не хардкорный технологический стартап, то у вас в принципе не должно быть кода, который бы был недоступен для осмысления большинством разработчиков.
                        То есть все проблемы с кодом — это на самом деле проблемы в организации работы. В том числе, отсутствия стратегического видения будущего проекта и как следствие — неправильной степени гибкости, заранее выбранной для проекта.
                          0
                          Может стратегическое видение было, но благодаря отзывам пользователем изменилось.
                            0
                            Нет, процесс сам по себе мало что дает. Кроме разве что выделения/невыделения времени на постоянный рефакторинг.

                            Если время выделяется, то всё упирается в квалификацию разработчиков. Т.е. в умении делать рефакторинг, подбирать имена, отражать смысл задачи в коде. Говнокод же появляется не сам по себе, а пишется разработчиками.

                            Хотя и процесс, если совсем неадекваты в управлении, может существенно тормозить. Например, если есть недоверие разработчикам и требуют утверждения каждого шага. Тогда разработчик попросту простаивает, ожидая встреч, утверждений.
                              0
                              Когда я работал там, где каждый шаг требовал утверждения, то я только и занимался рефакторингом, да экспериментами. Отрефакторил один кусок, послал его на утверждение, рефакторишь второй, временами переключаясь на решение той же задачи вообще исходя из других положений типа платформы, парадигмы (тогда я и заболел ООП головного мозга с очагами ФП), сценариев и т. п.
                            +4
                            Один из вариантов — иметь 2 команды.
                            Насколько я понимаю — такой подход практиковался в Интеле и Майкрософте
                            Один несет другого на горбу, тот в это время переобывается и подтягивает штаны
                          • UFO just landed and posted this here
                              0
                              Хм. Одного не могу понять — что делать тем компаниям, где кодовая база уже есть, рефакторить полностью нужно, ибо многие простейшие баги с точки зрения юзера (заказчика) уже не пофиксишь кроме как серьезными изменениями, но времени все равно нет — так как регулярно присылаются новые требуемые фичи, по которым есть таймлайны, и если заниматься ими (что предполагается заказчиком в первую очередь), то на рефакторинг уже просто не осается времени… Уже не в первом проекте, приходя, вижу такие вот проблемы — когда то, что можно было починить легко и бысто, починено, остальное надо ничить долго и с серьезным рефакторингом, а времени объективно нет.
                                0
                                Что делать? — бежать оттуда… ахаха…
                                Ну а на самом деле выделить ряд изменений по рефакторингу, которые принесут максимальный профит в виде уменьшения стоимости поддержки. А потом продать эти изменения заказчику или руководству. С цифрами понятное дело.

                                Но если заказчиком фиксируется стоимость разработки и время, то на качество всем насрать — совершенно нормальная ситуация. Ненормально если бы они при этом выставляли какие либо требования к качеству решений.
                                  0
                                  Если прибыль позволяет, то нанимать людей, чтобы времени на рефакторинг хватало. Если даже увеличив количество разработчиков в разы уложиться во объективно требуемое время не получается (про девять женщин я в курсе если чо) сначала сделав рефакторинг, а потом чинить, то мозговой штурм о будущих интерфейсах, а дальше параллельно чинение (даже не знал, что такое слово есть, думал спелчекер подсветит :) ) и рефакторинг. Чинение исходя из результат штурма, рефакторинг по приведению имеющейся базы к нему.
                                    0
                                    Тут прикол в чём… Как раз в тех самых 9 женщинах. А точнее то, что времени на то, что можно делать параллельно с разработкой новых фич — есть. Но рефакторинг уже нужен для всего ядра. А это значит — что наактывать новые фичи во время рефакторинга нет смысла — ибо само ядро поменяется, логика его работы. Как и фиксить баги (какие-то уйдут рефакторингом, возможно появятся новые :) ). То есть на время этого рефакторинга нужно остановить весь продакшн.
                                    При стандартном обязательстве выхода новой минорки месяца в 2-3, а потенциального времени на тотальный рефакторинг в месяц, выглядит всё проблематично — ведь после такого рефакторинга приличиное время придётся заниматься регрешн тестированием, выявлением что поломали, а что нет. То есть практически все изменения в новой версии и будут тем самым рефакторингом. А это уже отдел продаж не даёт — ибо (с)пользователь этих изменений почти не почувствует, ему давай новый функционал или исправление большого числа багов.
                                  0
                                  Такое часто бывает когда продукт(проект) сильно вырастает и меняется на столько что он перестает быть тем чем планировался быть(чем проектировался). Очень часто заказчики заказывают одно — получают это, и понимают что лучше сделать по другому, и не программную часть, а сами процессы, иногда даже принципы и структуры предприятий меняются, когда заказчики получают данные и понимание. Кроме того с течением времени все быстро меняется, техника, технологии, структуры, объемы и т.д.
                                  Так что в этом случае действительно нужно остановиться и завязать шнурки, а лучше сменить на обувь без шнурков или даже скорее вместо того чтобы бежать — пересесть на велосипед и ехать быстрее, потом автомобиль, самолет… ракету… Ведь задача не в беге ради бега в обуви со шнурками, а нужно преодолевать бОльшие расстояние за меньшее время… в нашме случае это наверно меньше кода — больше и лучше выполняемых операций… эволюция, как-то так.
                                    0
                                    Да, автомобиль лучше тем, что там нельзя «с развязанными шнурками» — то бишь, типа «без горючего и ТО» продолжать ездить. А уж ракету без многократных проверок даже на стартовый стол не пускают пока.
                                      0
                                      Ну, автомобиль можно залить какой-нибудь бурдой («танки грязи не боятся и можно хоть подсолнечным маслом заправлять») и ездить без ТО до первого инспектора (некоторые умудряются годами без остановок ездить).

                                  Only users with full accounts can post comments. Log in, please.