Team Lead
0,0
рейтинг
21 сентября 2012 в 02:45

Администрирование → Красной таблетки не существует

*nix*

О чем это


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

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

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

Я не сделаю, возможно, в этом посте никаких открытий. Но сэкономлю вам пару лет, если вы решитесь поверить моему опыту.



Проектирования нет


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

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

Но это не работает. У людей не уживается в голове одна простая мысль: идеального не существует. Любой дизайнер, программист, специалист, глядя на свои работы годичной давности, найдет много ошибок — ибо вырос профессионально. Значит, всегда можно улучшить любой результат. Однако те же самые люди будут с пеной у рта убеждать вас, что вот сегодня они познали дзен и сделают сразу правильно.

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

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

Об эволюционном проектировании (и о мертвом традиционном) серьезно рассуждал даже Мартин Фаулер

Методологии нет


Здесь я буду краток. Мы попробовали фиксированные итерации, пробуем канбан. Так как я программист, помимо PM — могу подтвердить, что все методологии действительно сводятся к пиши-код-блять.рф.

И чем меньше лишних действий вносится в процесс — тем лучше. Ежедневные обязательные разговоры — минус (мы общаемся вечером и все чаще on-demand). Плэнинг покер — нафиг: как правило, в моих проектах очень много сложных зависимостей, и смоделировать их и точно представить нельзя; а значит, оценки будут только отнимать время и довлеть, когда ты их на себя взял. Вместо этого — простые прикидки: сделать сразу, сделать за час, за день, и тд, то есть порядок.

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

Также хочется отметить дерготню. У нас есть регламент (с его внедрением непросто, но мы не сдаемся) о часах тишины: минимум 4 часа в день программист должен работать безо всяких средств IM, потому что ничто так не бесит, как вопросы переключиться.

В общем, пока я не видел универсальной методологии. Когда учился в вузе и был курс управления проектами, нам сватали RUP. Потом изучал Agile. На практике первое просто для IT, быстроменяющегося рынка и отрасли, просто мертво. А второе — секрет полишинеля. Все рассказывают, что уж они-то точно знают все секреты и могут поставить разработку. Но все чаще на рынок выходят говнопроекты, и делается все очень медленно. Зато конторы по консультациям процветают. Удивительно, да? Вместо того, чтобы самим делать проекты, они делают бабки на тренерской работе.

Кроме единиц, как некоторые, кто там 5-10 лет в Гугле или IBM рулил разработкой, в основном эти ребята ИМХО даже близко не должны подходить к консультациям, если только в портфолио нет реально крутых своих проектов.

А что есть?


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

Есть только люди. По мнению доктора биологических наук Сергея Савельева, которое он изложил в книге «Изменчивость и гениальность», мозги у людей отличаются в разы (отдельные структуры до 40 раз). Грубо говоря, у всех мозг уникален. И вся задача состоит только в том, чтобы отобрать к вам на работу самых гениальных, заточенных именно для нужной работы. Потому что определенные большие структуры в мозге будут тянуть человека делать то, к чему у него дар. Поэтому у лучших людей всегда кайф от работы — но не потому, что они выбрали такую работу, а потому, что изначально были созданы для нее и всего лишь правильно угадали.

Поэтому я ищу тех, кому нравится его деятельность — это признак одаренности (временами гениальности), и что человек верно выбрал свой путь (а не насильно, ради денег, изучил Java или там Photoshop, и занимается тем, чем не одарен).

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

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

Кто хочет тратить деньги, время и свои усилия на красные таблетки в виде Agile, или думает, что щас умные программисты все спроектируют, а дизайнеры нарисуют — ок, вперед! Можно проектировать до третьего пришествия, и пытаться до четвертого выстроить идеальный burndown chart, в то время как 10 хостов бесятся от неверно выбранных user stories на вашем проекте.

Желаю вам не тратить время на фигню, а скорее сфокусироваться на поиске и удержании лучших из лучших!

Эпилог


Пост посвящается тем самым единицам, тем программистам, менеджерам проектов и дизайнерам, и всем специалистам, которые трудятся на совесть и делают реальную работу, а не ИБД, как многие их коллеги. Такие, как вы — это элита IT и движущая сила мира. О вас хорошо сказал Айзек Азимов в своем рассказе «Профессия».

[...], и тот, кто не желает смириться с этим, и есть человек, которого мы ищем. Быть может, это жестокий метод, но он себя оправдывает. Нельзя же сказать человеку: «Ты можешь творить. Так давай, твори». Гораздо вернее подождать, пока он сам не скажет: «Я могу творить, и я буду творить, хотите вы этого или нет». Есть около десяти тысяч людей, подобных тебе, Джордж, и от них зависит технический прогресс полутора тысяч миров. Мы не можем позволить себе потерять хотя бы одного из них или тратить усилия на того, кто не вполне отвечает необходимым требованиям.
@Cord
карма
403,5
рейтинг 0,0
Team Lead
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

  • +60
    Вот! Вот, наконец, статья от нормального программиста.

    И эпилог шикарный. Я буду творить, и мне насрать на тех, кто учит меня, как это делать правильно. Вспомним знаменитую притчу про Моцарта и симфонии, кстати.
    • +3
      А расскажите притчу?
      • +32
        Я нашел сходу две, если что

        Первая
        Как-то раз Верди, уже убеленный сединами и знаменитый на весь мир, беседовал с одним начинающим композитором. Его собеседнику было восемнадцать лет. Он был совершенно убежден в собственной гениальности и все время говорил только о себе и своей музыке.
        Верди долго и внимательно слушал молодое дарование, а потом с улыбкой сказал:
        — Мой дорогой юный друг! Когда мне было восемнадцать лет, я тоже считал себя великим музыкантом и говорил: «Я». Когда мне было двадцать пять лет, я говорил: «Я и Моцарт». Когда мне было сорок лет, я уже говорил: «Моцарт и я». А сейчас я говорю просто: «Моцарт!».

        Отсюда: pritchi.omkara.ru/pritcha816.htm

        Вторая
        Однажды молодой композитор пришел к Моцарту. Он хотел знать, как развить свой талант.

        — Думаю, нужно начать с простых композиций, — посоветовал Моцарт. — Песен, например.

        — Но вы ведь сочиняли симфонии еще будучи ребенком! — запротестовал молодой человек.

        — Да, это так. Но я ведь не ходил к кому-либо за советом о том, как развить свой талант.

        Отсюда: krendelek.ru/content/doc/parable/anthony-de-mello/page4
        • +6
          Шикарно, особенно вторая притча, и жизненно спустя N веков!
        • +9
          Один иудей обратился к ребе с вопросом — надо ли брить бороду? Ребе ответил, что надо. Иудей поблагодарил, и ушел, но по дороге задумался.
          — Как же так? Ребе сказал, что надо брить бороду, но у него самого она не сбрита. Весь в непонимании он вернулся к ребе с вопросом.
          -Ты сказал мне, что надо брить бороду, но у тебя самого она не сбрита. В чем тут дело?".
          Ребе ухмыльнулся.
          -А я не у кого не спрашивал, брить мне ее, или нет.
        • +2
          Я имел в виду вторую, правда читал ее чуть в других словах:

          «Какой-то юноша спросил Моцарта, как писать симфонию.
          — Вы еще слишком молоды. Почему бы вам не начать с баллад? -сказал Моцарт.
          Юноша возразил:
          — Но ведь вы начали писать симфонии, когда вам не было еще и десяти.
          — Да, — ответил Моцарт, — но я ведь ни у кого не спрашивал, как их нужно писать.»
  • +2
    Сильно
    • +6
      Особенно нравится это:
      • +3
        Мне ещё вот это нравится.
        • +2
          У меня карма отрицательная, парсер съел теги.
          • +2
            Да я понимаю, что парсер. Просто не смог удержаться)
    • +2
      О тренингах — напоминает книги о том, как заработать. Чего ж эти бараны сами не воспользуются знаниями?

      А вот насчет разницы в сорок раз структур мозга — совсем не понятно. Разве структура не может отличаться на проценты? Куда уж выше 100% (т.е. полностью)?
      • 0
        У мозга много структур, 40 по 100% получается 4000 % :)
        • 0
          Что-то тут не так… но доходы, действительно, раз в 40 отличаются.
      • +2
        Они и зарабатывают. На тех, кто покупает книги.
      • 0
        1 мм против 5 см, к примеру.

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

        • 0
          Я не верю в это (до конца). Сам учился в музыкальной школе. До нее — даже петь не выходило. После хора и вокала научился (вроде). :)
          • 0
            способности могут быть в зачатке.

            но если их __физически__ нет, то развить нельзя
            • 0
              Я не раз слышал (в том числе и от уважаемых мной музыкантов), что петь можно научить кого угодно (хотя лучше это делать всё-таки в детстве). Людей совсем без слуха не существует — чтоб человек пел, надо лишь развить то, что и так есть.
              • 0
                Вопрос в том как. Имхо, гены и среда до начала любого обучения оказывают воздействие на то, каких высот можно достигнуть. Проще говоря, у людей неравные стартовые возможности в любом начинании и при одинаковом вложении труда у кого-то результат будет всё равно лучше.
  • +2
    Всё правильно кроме вот этого:

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

    тема раскрыта в «Peopleware».

    Если те самые гениальные разработчики, которые в 10 раз продуктивнее среднего говорят вам такое, их тоже не нужно «слушаться»?
    • 0
      > И если вы послушаетесь их бесконтрольно

      это значит, что пустите дело на самотек, не будете применять никаких Метрик и т.д.

      я только это имел в виду.
      • 0
        Добавлю, что я выделяю от недели до нескольких месяцев на рефакторинг. Но все обычно по определенному вектору
        • +5
          Как вам точка зрения о том, что рефакторинг необходим только как часть решения очередной задачи, не чтобы все исправить, а исправить только части имеющие отношение к конкретной задаче. Задача может относиться как к багу, так и к новой фиче.
          Я давненько забросил заниматься рефакторингом ради рефакторинга. Т.о. и рефакторинг как бы есть, и месяцы на него тратить не нужно.
          • +1
            Вроде небольшая (для заказчика :) ) фича может потребовать либо переделки всего с нуля, либо нагромождения костылей во всех слоях.
            • 0
              Заказчик — вообще основной источник рисков для проекта. Было такое на последней работе. «Field in form should be calculated and editable» — как-то пропустили. А поле вычислялось по сумме по БД. Пришлось для «editable» сумм городить отдельные таблицы.
              • 0
                Ну, тут явно ваш фэйл, заказчик не в конце разработки же вставил «and editable» :)
                • 0
                  Фэйл был нашего ПМ, который трахал моск всякой левой фигнёй, что нервировало и отвлекало от дела… Но всё равно — ставить задачу по системе, использующей БД, не используя ни одного термина из области БД, а только в терминах UI — это источник рисков…
                  • +1
                    Сижу и думаю, а чего у нас такого нет… Потом вспомнил, что пототип дает полное представление о том, какая именно структура БД понадобится.
            • 0
              Ум, как сумма осознанного опыта, даден разработчикам и проектировщикам, как раз, чтобы максимально избежать подобных эксцессов :)
              • 0
                Ошибки такого рода допускаются в основном на более ранних этапах разработки чем проектирование: анализ и постановка задачи, сбор требований и т. п. Да, некоторые вещи опытные разработчики делают на автомате, заботясь, зачастую даже неосознанно, о будущем поддерживании системы, но всех возможных сценариев развития системы не предусмотришь.
                • 0
                  Действительно случаются ситуации, и то что эти ситуации случаются не часто, я считаю нормой, когда тот или иной модуль приходится переписывать, однако давненько я не встречал «переделок всего с нуля» и «нагромождения костылей во всех слоях».
                  С другой стороны, если заказчик требует некий юзер стори которого не было на этапе постановки задачи, то в лучшем случае заказчику светит компромис.
                  • 0
                    Недавний пример — внезапно всплывает требование, что незашифрованные персональные данные не должны покидать клиент в принципе, то есть даже имея полный доступ к серверу персональные данные должно быть невозможно (в терминах криптографии) получить, ключа расшифровки на сервере быть не должно.
                    • 0
                      Вся логика перемещается на клиента? Нецензурная лексика? :)
                      • 0
                        Слава богу не вся, большинство логики работает с id клиента, но вот чисто интерфейсные штуки типа автодополнения фамилии тоже нецензурную лексику вызывают.
                        • 0
                          Фамилии можно и в словаре на сервере хранить. Они не являются идентифицирующим личность данными, потому что людей с одинаковыми фамилиями немало. Даже связка ФИО не идентифицирует личность.
                          • 0
                            Номер паспорта точно идентифицирующая.
                            • 0
                              Это да. Добавление даты рождения к ФИО сразу делает данные идентифицирующими, хотя это все еще не на 100% подтверждает личность.
                              • 0
                                Там полные данные: ФИО, дата рождения, номер паспорта, кем и когда выдан, адрес регистрации.
                                • 0
                                  Словарик можно сформировать не только на основании пользовательских данных :)
                            • 0
                              В любом случае, это исключительная ситуация. Во вторых, если работа ведется с персональными данными… я бы плохо спал, если честно, потому, как контролирующие органы в разных регионах со своими тараканами, и ГОСТовским шифрованием их не всегда можно уговорить. Хотя, с хорошим юристом можно все.
                              • 0
                                Страшна не работа с данными, не их накопление и обработка, а возможность продажи.
                                • 0
                                  Это не моя забота, этого пусть боится заказчик.
          • 0
            Не согласен. Изменения в архитектуре сложны, и учитывают динамику роста определенных векторов/осей ответственностей.

            И потом, это просто вкайф — сделать проект лучше :) Когда результаты визуальные в порядке )
            • 0
              Не согласен, т.к. фраза «динамика роста определенных векторов/осей ответственности» имеет слишком широкую смысловую расплывчатость и не может быть мною корректно формализована.

              И потом, это неизбежно, да, ведь разработчик с каждым днем становится профессиональнее, однако рефакторинг ради фана экономически неэффективен. Лучше по-моему поставить задачу так, чтобы рефакторинг понадобился, и фан и польза :) Я совсем не против, рефакторинга, я обожаю удалять код, и если в начала проекта рост строк кода 1-2к в неделю, то к концу проекта добавление функционала, каким-то магическим образом не приводит к увеличению количества кода, напротив, иногда, кода становится меньше.
              Золотая середина, я наверное постиг дзен? :)
    • +14
      Те самые «гениальные» тихо отрефакторят всё за ночь без вашего ведома на свой страх и риск, а на утро будут счастливые, как младенцы, спать перед монитором
      • +7
        Говорю вам как программист повидавший виды в разных компаниях мира. Альтруизм — дело неблагодарное, неприбыльное, изматывающее и, наконец, несуществующее. Сегодня он «без вашего ведома на свой страх и риск» «отрефакторил все за ночь», а завтра пойдет искать другую контору, потому что на этой его не ценят и в нем не нуждаются.
        • +5
          Совершенно верно, так и будет.
        • 0
          Но код останется отрефакторенным :) Но вообще говоря такой альтруист может очень долго менять компании. В вакансиях очень редко встречаешь рефакторинг в перечне основных обязанностей разработчика, что означает, что менджмент не считает его важным элементом процессов разработки и/или поддержки и с большой вероятностью рабочее время на это выделяться не будет. Увы :(
        • +2
          Думали, альтруист, а чувак скиллы прокачивал…
        • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А наутро будут с красными глазами дебажить :)
    • 0
      Слушаться.

      Они не парятся «метриками». Но сделают это наиболее быстро и наиболее качественно. От метрик никакого толку. Есть объем работ, который надо сделать. Есть путь, как это сделать наиболее оптимальным способом.

      Хотите замедлить работу или тормознуть совсем — вмешивайтесь в их работу, не пускайте на самотек и говорите, что им делать.
  • +5
    «Я могу творить, и я буду творить, хотите вы этого или нет».
    Вот оно!

    ps Хотите вы этого или нет, а я это себе в профиль поставлю.
  • +2
    Полностью согласен с автором, а еще не малое влияние на процесс и как следствие — результат оказывают социально-психологические взаимосвязи. Например, если в команде все крутые специалисты, которые начинают «выеживаться» и т.п. друг перед другом, то процесс будет приторможен и малопродуктивен, а результат будет хуже чем у менее профессиональной, но более дружной команды…
    • +2
      Чаще идет конфликт между тимлидом (как правило знающим компромисс между качеством и сроками) и «гением», утверждающим что в калькулятор следует заранее заложить возможности расчета орбит небесных тел с учетом релятивистских эффектов.
      • 0
        Основное и самое интересное слово, которое я у вас тут увидел — «заранее». Почему «заранее»? Потому, что нет уверенности, что получится незаранее — тогда, когда реально будет надо. Поэтому делаем не тогда, когда надо, а тогда, когда можно. Что, в общем, есть признак слабости. Всякое «заранее», как и прочие разновидности ориентации на то, что можешь, а не на то, что хочешь, есть признак слабости.

        Но, с другой стороны, физически можем мы обычно больше, чем хотим;-)
        • 0
          Если говорить не о реализации фичи заранее, а о создании архитектуры, способной без проблем эту фичу подключить, то «заранее» вряд ли можно назвать слабостью. Другое дело, что нужно выбрать из всех возможных фич те, которые будут почти гарантированно.
          • 0
            с помощью рефакторинга архитектуру можно скорректировать, в некоторых пределах.
            • 0
              Чтобы с помощью рефакторинга архитектуру можно было легко скорректировать (на самом деле в достаточно широких пределах) она должна быть покрыта тестами как можно полнее (на крайний случай должна легко покрываться тестами). Для этого архитектура должна быть тестируемой. По-моему, проектировании заранее заведомо легко тестируемой архитектуры, пускай без (пока) намерения писать тесты, как раз тот случай, когда «заранее» не слабость, а сила. Вернее даже превращение слабости, невозможности (объективной или субъективной — не суть) предсказания путей развития проекта, в силу, возможность на этой невозможности не зацикливаться.
        • 0
          Слабость причем? Обычно люди рассуждают о том, что им не хватает. О силе-слабости?

          «Ты кричишь как бездомная
          — Да здравствует дом!
          Я кричу как безумный
          — Да здравствует лужа!»

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

          Это лирическое отступление. А вообще, делать всё вовремя — это дзен. И не только заканчивать вовремя. Но и начинать вовремя. Возможно это признак профессионализма? Когда человек лишен беспокойства и ждет нужного момента. Правильно распределяет для себя задачи и отталкивается только от того, что нужно.
  • +2
    Подпишусь под каждым словом!
  • –7
    Очень интересно, но совершенно не практично.
  • +6
    Обычно быстро говнокодом невозможно написать (имхо).
    Юра Малинов хорошо об этом сказал.
    • +11
      Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.

      На первых стадиях — легко. Что проще — сделать один God Object или сделать 15 интерфейсов и 2 слоя абстракции, чтобы потом их удалить, когда узнаешь, что предметная область-то совсем иная? Я против God Object и любитель DI, SOLID, IoC TDD etc, но если ты прорабатываешь задачи, делая скелет на скорую руку, ты всегда будешь быстрее.

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

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

        Хардкод не самоцель, но обычно именно нежелание написать «неправильно», чтобы было не жалко переделать, и ограничивает скорость разработки людей.

        Я не стесняюсь написать числа прямо в коде, текстовые строки и тд; потому что знаю — рано или поздно я заменю это на константы. И таких вещей очень много.
        • +5
          Тут есть один тонкий момент. Когда пишешь один, можно особо и не стесняться, но когда в команде, это уже накладывает определенные рамки. Помня о том, сколь часто самому приходится вскрикивать: «Да твою мать!», пугая окружающих, когда натыкаешься на очередной «шедевр», подложенный тебе заботливым другом, сам стараешься не подводить товарищей подобным образом, даже если сильно торопишься.
          • 0
            Для этого есть разделение труда.

            Но, честно признаюсь, с этим не все гладко, и это действительно непростой вопрос. Терпимость к чужому коду — важное качество для командной работы. Даже к хорошему :)
          • +1
            Это неизбежно, как смерть и налоги (ц). Все мозги разные.
        • 0
          Слава Богу, в Java/Eclipse есть такие вещи, как чекстайл и рефакторинг. Хардкоры можно побороть потом, с минимальными усилиями. И архитектуру выправить.
      • +4
        Быстро и правильно — я таких пока не встречал, но они где-то есть, я точно знаю.

        Не знаю, из таких я встречал только кодогенераторы. Обычным смертным, сколь бы гениальны они не были, всегда приходится балансировать между быстро и правильно в зависимости от конкретной ситуации.
      • +1
        Элементарно. На поздних стадиях разработки проекта можно писать быстро и качественно, за счет уже сделанного инструментария.

        За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно.
        • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ну почему невозможно? Возможно, просто параллельно работает код разного качества с костылями на стороне старого для связи с новым.
          • 0
            При этом, если вы переписываете говно-ядро, то вам необходимо обеспечить обратную совместимость — задача не очень тривиальная и иногда не позволяет полностью избавится от говнокода (если интерфейс говяный, то его придётся оставить). Либо вместе с ядром вам придётся переписывать клиентский код — т.е. почти всю систему, даже если отдельные части написаны хорошо, но используют говяный интерфейс/API.

            Кроме того, есть ещё один нюанс.
            По своему опыту я могу сказать что программисты делятся на две кадегории: говнокодеры и чистокодеры. Невозможно заставить чистокодера написать говнокод так же и наоборот. По этому, что бы сначала написать говноядро, а потом переписать его, вам придётся поменять команду разработчиков. А это вообще жесть.
            • 0
              Прокси, адаптеры и прочие подобные решения позволяют решить проблему совместимости, изолируя чистый код от говна. Вот пример, с которым работаю прямо сейчас. Было:
              function updateState($state)
              {
                global $USER;
              
                //...
                mysql_query("UPDATE users SET state = {$state} ... WHERE id = {$USER['id']}";
              }
              

              Стало:
              function updateState($state)
              {
                global $USER;
                $user_id = $USER['id'];
              
                UserAdapter::updateState($user_id, $state);
              }
              

              где UserAdapter::updateState($user_id, $state) проделывает всю работу получая объекты User по user_id и изменяя их состояние, пересекаясь со старым кодом только на уровне данных в MySQL. Сначала UserAdapter стремительно разрастался, но теперь стал потихоньку сокращаться.
              • 0
                При этом, вы не избавились от глобальной переменно $USER и не избавились от лишней функции updateState(). Вы просто написали новую чистокодерскую функцию UserAdapter::updateState();

                Где профит?
                • 0
                  Профит в обратной совместимости. Старый код вызывает новую updateState не замечая разницы, новый работает непосредственно с User, а UserAdapter просто временный «мост» между старым и новым.

                  Когда все функции с global $USER будут переписаны на UserAdapter, то от $USER можно будет избавиться, а в последствии и от UserAdapter.
                  • 0
                    Я не отрицаю, что всё можно переписать и избавиться от говнокода. Но что бы избавится от глобальной переменной $USER вам потребуется переписать ядро + клиентский код. Т.е. почти всю систему.

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

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

                    $action = 'update';
                    $what = 'State';
                    $funcName = $action . $what;
                    $funcName(23);
                    


                    TDD-тестов у вас нет и придётся тестировать ВСЁ приложение что бы убедиться в работоспособности. А это очень долго.

                    Кстати, я очень сильно сомневаюсь, что программисты знакомые с паттернами (прокси, адаптеры и прочие подобные решения) могут начать использовать глобальную переменную $USER. Здаётся мне, вы за кем то переписываете чужой говнокод. Т.е. менеджер сменил команду разработчиков?
                    • 0
                      Ну, я опровергал тезис «За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно» вне контекста использования инструментария. С другой стороны часть старого кода копипащу в новый, особо в него не вникая, лишь убедившись визуально в отсутствии зависимостей или хардкода или как можно безопасней разрывая зависимости и вынося хардкод в константы и т. п.

                      Не то чтобы переписываю, а должен внедрять новые фичи, править старые баги и т. п. Просто для себя решил, что лучше это делать параллельно с «сильным» рефакторингом существующего кода, чем вставлять костыли в существующем стиле. Заодно и тестами покрываю. С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы :)
                      • 0
                        За счёт уже сденного говнокода с захардкоденными всё и вся — невозможно начать писать качественно

                        … используя готовый говно-инструментарий.
                        Просто эта фраза вырвана из контекста.

                        С другой стороны, лет 10 назад мой код от этого бы принципиально не отличался бы

                        Вы начинаете писать правильно не за счёт говнокода, а за счёт своего большого опыта. И вряд ли вы сможете наговнокодить глобальную переменную $USER, потому что прекрасно понимаете: чистокод пишется быстрее чем говнокод. Здесь можно поспорить только с TDD, которое даёт результат в переспективе, но может немного замедлить текущие задачи.

                        Второй ваш абзац подтверждает мою догадку о смене команды. Соответственно, подтверждает утверждение о том что нельзя сначала скомандовать: «пишите говнокод блеать!!! »; а потом на поздних стадиях дать команду: «пишите чистокод с проектированием и tdd используя готовые говно-инструменты, йопт !!!».
                        • 0
                          Скорее не опыт, а знания, почерпнутые из сторонних источников. Читаешь какую-нибудь книгу или статью, видишь, что сталкивался с озвученной проблемой и видишь элегантное решение. Или просто в чужом коде натыкаешься.

                          Не то, что смена команды. Просто менеджер решил форкнуть существующий проект, а разработчик апстрима о рефакторинге слышать не хочет («всё работает»). Багфиксами обмениваемся, но не более. Если предлагаю багфикс с рефакторингом, то воспринимает его просто как багрепорт.

                          • +1
                            видишь, что сталкивался с озвученной проблемой

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

                            а разработчик апстрима о рефакторинге слышать не хочет

                            ну да, ну да. Как это знкакомо… К сожалению, говнокодера нельзя заставить чистокодить.
                            • +1
                              Дайте ему в руки фреймворк, качество кода вынужденно станет выше.
                              • 0
                                Как раз вчера разбирался с сайтом который генерирует страницы по 7-8 секунд. Сайт написан на ZendFramework. Я очень сильно удивился когда на не очень сложных страницах увидел в логах по 1000-1800 SQL-запросов!!! Все они очень простые и лёгкие и выполняются в среднем по 0.6мс и БД совсем маленькая. Но 1800 запросов к БД на одной странице это жесть. ZandFramework не вставил мозги разработчику.

                                Красной таблетки не существует. (с)
                                • 0
                                  Дайте нормальный фреймворк, а не микроскоп, которым будут гвозди забивать :)
                                  • 0
                                    По вашему мнению, существуют сайты для которых 1800 SQL-запросов на генерацию одной типовой страницы — это нормально?
                                    • 0
                                      Это уже другой вопрос, и он слабо относится к исходной теме, что количество говнокода можно сократить, если не давать в руки сложных инструментов, а ограничиться более примитивными. То, что примитивный инструмент может под капотом быть невероятно сложным, это уже проблема выбора инструмента.
    • 0
      Да, в корне верно! Стив Макконел в своей книге «Совершенный код» писал примерно о том же. Он говорил, что чем меньше связность элементов в системе (классов) и т.п., тем проще их использовать в других проектах. Таким образом проект действительно будет собираться как из кубиков.
      • +1
        В реале, есть шанс что проект будет сначала разбираться на кубики…
        • 0
          Некомпетентность архитектора. И точка.

          У некоторых, ИМХО какая-то иллюзия, называться архитектором, и быть архитектором.
  • +6
    Вспомнил «Жизнь внутри пузыря» Ашманова, особенно идею об «общей шине» ( www.ashmanov.com/pap/bubble/#p4.9.2).
    • +1
      О да, общая шина это пять!

      В далёком 2007м бумажная тогда ещё Компьютерра брала интервью у Ашманова, по общей шине там тоже проехались. «Общая шина… потому что Общая шина!», хе-хе.

      Способствует возвращению с небес на землю некоторых не в меру ретивых проектантов и снижению ЧСВ у них же.
      • +5
        Вы бы хоть продемонстрировали:

        image

        Действительно, доставляет. :)
        • +4
          Вы бы хоть продемонстрировали

          Да, действительно надо было. Исправлюсь, продемонстрирую другую картинку оттуда, которая тоже божественна и связана с данной статьей:

          image

          P.S. А вообще «Жизнь внутри пузыря» это конечно классика из разряда «Читать всем!», кто хоть как-то связан с IT.
          • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Только надо учитывать, что рассказанная история, пропущена через фильтр сознания Ашманова

              Конечно. Он и сам это признает в «Эпилог 2.0», отвечая на вопрос:

              2) А чего это автор получается весь в белом, а все остальные известно в чём? Или, словами из другого блога, почему автор выходит д'Артаньян, а все остальные персонажи — козлы?
    • 0
      Класс!
    • +1
      Огромное спасибо за ссылку. С удовольствием прочитал.
  • +1
    Савельев — фрик, если не ошибаюсь.
    • 0
      Его теории отлично описывают реальность и дают ее предсказуемость.
      И доктора наук в СССР фрикам не дают вроде, не? :)
      • 0
        Его теории отлично описывают реальность и дают ее предсказуемость.

        Какую-такую реальность? Его гипотезы довольно часто идут вразрез с мнением современной науки.

        И доктора наук в СССР фрикам не дают вроде, не? :)

        Только академика. СССР, если что, уже 20 лет не существует, а наука на месте не сидит…

        P.S. Про Савельева.
  • +3
    Брукс, перелогиньтесь!
  • +12
    Вы выросли. :) Это проходит каждый в своей области, ну разве кроме 5-10% клинических инфантилов, просто не каждый после этого пишет пост на Хабре :)
    • 0
      Эмоциональные и толстые высказывания — это, как правило, признак непрофессионализма. Так что автору еще расти и расти (без всяких обид).
      • 0
        Вы знаете, в частной беседе — да. Скромность и толерантность, дипломатия рулят.

        А вот если пытаться в группу людей что-то сложное донести — не поймут. Уверенно же и четко говоря простые вещи, вплоть до этапажа, вы гораздо быстрее поляризуете людей на несколько лагерей, один из которых и поведете.
    • 0
      Покажите мне их, хиде они, эти PMы?
  • 0
    Согласен на все 100%!
    Только мое мнение, что иногда надо переписывать с нуля даже на поздних стадиях. Лучше уж сделать еще одну итерацию и учесть имеющийся опыт, чем долго думать, а надо оно или не надо, тратя при этом время. Все равно время переписывание потом покроется меньшим количеством багов и более простой поддержкой.
    • +3
      Согласен. Вопрос планирования, чтобы это шло не бесконтрольно, а был какой-то вектор.

      А так, я даже писал с нуля MVC фреймворк однажды. Думал написать второй, но, побродив по зарубежным open source вариантам, нашел пару по душе и решил — что лучше помогать коллегам, чем думать, что ты умнее всех :)
    • +1
      >> иногда надо переписывать с нуля даже на поздних стадиях

      Если сроки позволяют. Надо очень-очень хорошо все считать. А потом умножать на два и прибавлять месяц. И с этим идти к руководству, заранее зная ответ.
  • +2
    вы все еще не читали «Мифический человеко-месяц»?
    • +1
      Никак не мог добраться. Но Peopleware, написанный много лет назад, убедил меня подвинуть Брукса в списке 2read выше.

      А вот недавно, обобщая свои выводы, увидел схожие тезисы у Брукса. Воистину, «все украдено до нас» (С)
      • +4
        Доберитесь. Эту книгу стоит прочитать еще до того как берешься за свой первый проект. В издании 1995 года говорил сам Брукс — я удивлен что эта книга все еще актуальна. При этом первое издание вышло еще в 75 году. А в издании 1995 года добавилось эссе «Серебряной пули нет». Которое в целом перекликается с вашим топиком.
        • +1
          Благодарю за совет и интересную информацию
  • 0
    Все верно, и это применимо к любой области.
    Работают люди, а не методики. А качество работы людей зависит от того любят ли они свою работу или нет.
    Вот и весь секрет.
    • 0
      Методики могут помогать и позволять следить за проектом. Но они должны быть приняты людьми.
      • 0
        Принять просто, но надо ведь еще и применять постоянно.
  • +43
    Если в туристическом походе вам приходится периодически менять планы из-за неожиданного ландшанфта или изменения погоды, значит ли это, что не следует прокладывать маршрут?

    Если разные дома требует от прораба разных подходов к процессу строительства, значит ли это, что он должен отказаться от любых графиков и просто говорить своим строителям «кладите-кирпичи-блеать»?

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

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

    Другими словами, и проектирования, и методологии есть, и это хорошо. Но чтобы не возникло конфузов, все эти вещи нужно уметь правильно готовить, а не бездумно лепить agile потому что это круто и не заниматься оверинженирингом там, где ещё ничего не понятно.
    • +5
      Все это не работает без людей. В вашем посте любой пример это подтверждает. Прораб рулит рабочими, без него сами работают роботы и немцы. Здание рассчитывает умный архиетектор, и именно его косяк при самой крутой методе фатален
      И тд

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

      Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
      • +3
        Одно не исключает другого, любым людям (в том числе талантливым) нужна организация совместной работы.
        • 0
          Талантливый организатор
          • +8
            Спасибо, кэп!

            Теперь понятно! Нужно было всего лишь устраивать на работу талантливых людей!
            Пойду найму 10 талантливых программистов и пару талантливых проджект менеджеров… Всего-то делов!
            • 0
              Если у вас есть всего лишь месяц, то лучше потратить на эту благородную задачу,
              чем на поиск методики, которая решит все сразу, или проектирования на бумаге всего и вся, вместо пяти итераций с релизами говнокода каждый день.
              • 0
                Уже год ищем, пока нашли только двоих талантливых. Что мы делаем не так?
                Может быть вы нам подскажете место, где тусуются талантливые программисты?

                Поиск методики — дело неблагодарное. Всегда выбираешь из того, что знаешь по опыту, а дальше — по обстоятельствам, проекты то все разные.
                Да что это я, вам тут все в этой ветке про это пишут, а вы дальше гнёте)
                Предлагаю на этом остановиться)
                • 0
                  Думаю, таланты вообще редкость, и продавать компанию сотрудникам — тоже талант
      • +3
        Корень успеха это талантливые люди. Остальное инструмент в их руках. А не люди а ля инструменты в руках подходов
        Мне показалось, или вы обходными путями всё-таки дошли до первого тезиса Agile манифеста?
        «Individuals and interactions over processes and tools» © agilemanifesto.org
        А в начале статьи говорили, что это фуфло… :-)
        • 0
          да, мой опыт Agile искажен. в оригинале, конечно, оно так, как вы и говорите. об этом же я читал и у Мартина Боба в Rapid Software Development (один из авторов этого манифеста).

          в реальности оч. мало людей так думает
      • 0
        > Методики и проектирование суть инструменты
        Естественно! И у каждого инструмента своя область применения. Так же как нельзя отверткой забить гвоздь, так и проектирование не решит всех проблем проекта. Но это не означает, что «проектирования нет». И так же естественно, что инструментом нужно уметь пользоваться (необходимы профессиональные люди).
        • 0
          оно эволюционное. в обычном виде я считаю, для 99% проектов оно нахер не нужен, тк будет 100% оверинжиниринг и время на рынке пропущено.
          • 0
            Для мелких 3-х месячных проектов (почти все мобильные приложения) — не нужно. Да и все веб приложения по MVC шаблону строятся, для них тоже не особо нужно проектирование. Нынче веб+мобильные — это порядка 80%, так что вы не далеки от правды. Но это частный случай (хоть и массовый). А в общем случае без проектирования в большом проекте сложно.
            • 0
              Легко, если сначала вы строите конструктор, а потом с его помощью решаете поставленную задачу.
      • 0
        Никто не спорит, что всё упирается в людей, а проектирование, методологии и т.п. — это всего лишь инструменты. Вопрос в том, нужны ли эти инструменты, или же люди и гвозди забивать, и брёвна пилить должны голыми руками.
    • +1
      Когда художник пишет картину, он её делает по линиям, сразу конечный вариант? Нет, сначала много набросков, общие элементы, а потом детали, детали, детали.

      • 0
        Красивая метафора
    • +2
      Отлично сказано!

      Мне вспомнилась фраза Дуайта Эйзенхауэра: Когда готовишься к сражению, планы бессмысленны, но планирование необходимо.
      Также вспоминается фраза, которая есть практически в любой книге по гибким методологиям: Серебряной пули не существует, каждая методология имеет свою область применимости.

      Читая статьи подобные этой, постоянно сталкиваюсь с одной и той же ошибкой в понимании гибких методологий. Почему-то считается, что гибкие методологии устраняют типичные проблемы разработки — и это не верно! Наоборот, в них признается факт, что от этих проблем не избавиться и в процессе разработки мы должны учитывать. Даже самые опытные программисты делают глупые ошибки — поэтому надо писать тесты и вообще лучше работать в паре, нельзя сразу учесть все требования — поэтому пишется сразу код выполняющий только текущую задачу, а дальше короткие итерации и рефакторинг в помощь, и так далее. Не находите, данные рекомендации совпадают с выводами автора, основанными на практике?

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

      Ну а хвалебные отзывы о сверхневероятной эффективности каких-то методик оставим на совести консультантов — им же надо как-то продавать свои услуги.
      • 0
        Гибкие методологии требуют гибкого подхода к их внедрению. :)
      • 0
        Согласен насчет разумного подхода. Вопрос про курицу и Яйцо. Без программеров не нужен Agile, а с хорошими программерами Agile не нужен. Как-то так
        • 0
          Agile нужен не для написания красивого кода. Это заблуждение.
          Что-то мне кажется, что пора писать статью, зачем же нужны гибкие методики…
  • +1
    Мне кажется истина как всегда где то посредине. Хорошим программистам любящим свою работу так же нужны какие-то общие рамки и ориентиры, просто для того чтобы эффективно работать вместе. От того что перед написанием проекта будет составлена общая архитектура, хотя бы в виде: «Это мы пишем модулями, а этот функционал будем использовать во многих проектах поэтому выносим на api», а более детальное проектирование можно отложить на момент реализации конкретного блока приложения.

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

  • +3
    Надеюсь, этот пост прочитает как можно большее число манагеров и они наконец поймут, что можно хоть каждый день придумывать различные методологии, часами обсуждать новые фичи и в течении нескольких месяцев заниматься проектированием, но если у вас нет людей, которые могут «писать код, блять», то это пустая трата времени и денег.
    • 0
      Да, я эту мысль закладывал, как одну из основных
  • +21
    Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.

    Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».

    Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
    • 0
      Люди разбегутся, пока будут выстраиваться процессы и болтовня по 100 часов в неделю.
      ИМХО!!!
      • +2
        Вам не повезло, если у вас сложилось мнение, что «процессы» — это «болтовня 100 часов в неделю».
        Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.

        А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.
        • 0
          Удивительно, но мы как раз пришли именно к последней стадии. Черт, как тонко подмечено. Жаль, не удалось перейти снова к Сю.
  • +6
    Самое-то главное просмотрели: когда Нео выбирает и съедает одну таблетку, Морфеус ест _другую_.
    • 0
      Не только просмотрели, вообще не показали.
  • 0
    Я как PM тоже пришел к Вашим выводам примерно год назад. До этого страдал привязыванием методологий к разработке проектов. Лишь в нескольких случаях получалось создать нечто работоспособное, в иных случаях 90% процессов были просто не нужны в проекте.
    Скажу только одно — методологии (лучшие практики) знать необходимо, но слепо использовать их нельзя.
    Даю гарантию, что любому из ваших проектов пригодится только 1-5% процессов, описанных в методологиях, возможно даже вы возьмете по одному процессу из Kanban и PMBoK и этого будет достаточно.
    Не тратьте время на фигню в виде утренних скрамов, пленинг покеров и будет Вам счастье ;)
    • 0
      да, живем без них и супер.

      Вообще, умный программист решает 90% проблем разработки проекта. Остальные 10% решает умный PM.
      • 0
        IMHO!!!
  • 0
    Или же, если разработчики уже имели опыт рефакторинга в другой компании, они сходу предложат вам проектировать сразу. UML, использование сложнейших инструментов и так далее — давайте сразу сделаем все правильно, чтобы не переписывать. Это может касаться не только программистов — дизайнер будет стараться нарисовать сразу конечный макет, дабы сдать его без переделок.

    Знакомо — было на прошлой работе. В результате неделю просидел просто-так, думая, «а чтоб ещё добавить?». В результате, все изменения пошли уже после того, как я начал делать хоть что-то, помимо проектирования.
  • 0
    Спасибо, это лучшее вдохновение перед работой!
    С такими как вы, хочется работать и получать тот кайф от кода (некоторые это не понимают).

    Видно, накипело, как и у многих… Спасибо!
    • 0
      Пожалуйста.

      Всех благодарю, кому помог.
  • +1
    Восхитительно, спасибо. Данная статья сильно укрепила мои взгляды.
  • +3
    Любой дизайнер, программист, специалист, глядя на свои работы годичной давности, найдет много ошибок — ибо вырос профессионально.

    Кто-то даже сказал, что если через полгода ваш старый код не кажется вам убожеством, то вы ничему не научились за эти полгода.
    • 0
      да, клево
  • +1
    Вы всё совершенно правильно подметили для продуктовых компаний или технологичных стартапов.

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

    А для таких людей нужна жёсткая система с жёсткими правилами. Они просто по-другому не могут работать хотя бы с 10% от продуктивности программистов по рождению.

    Но в целом согласен — нужно брать хорошее из методологий только тогда, когда этого потребует проект, а не подстраивать каждый проект под канбан или agile.
    • 0
      да, есть такая тема.

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

      управлять разрабами сайтов, такими, как студенты, нужно уметь, и тут действительно нужна ИМХО система, согласен.

      но сколько умных, читающих эту статью программистов пойдут на ЗП x2 работать Битрикс программистами? Или тем более ЖУМЛА (старой, нерефакторенной)? нафиг нафиг
  • +3
    Ну что сказать?.. Очевидно где то в своей сфере и со своим опытом вы правы, но подходы «пиши-код-блять», «давай быстро заговнокодим» и т.д. ничего хорошего никому не дал.
    И что самое удивительное, если для компаниям такой подход даёт прозрачную надежду на быстрый выход продукта и, иногда, эта надежда сбывается, то программиста которые так работают ВСЕГДА оказываются в жопе. Потому что даже если продукт выходит он оказывается настолько плохим, дырявым и с точки зрения кода не поддерживаемым, что у всех консультантов, которых компания ВЫНУЖДЕНА приглашать, поскольку непонятно ведь отчего вся система падает или не держит нагрузку, возникает вполне логичный вопрос — «а как вообще такое можно было написать?». После чего возникает другой вопрос — «кто конкретно делал этот проект и почему в нем сплошной говнокод и нет никакой структуры?». А самое печальное, что ответы на этот вопрос все знают и та команда которая делала этот проект заменяется на более профессиональную. Так что мой вам совет, не пытайтесь скрыть свою некомпетентность за фразами «это не работает», «главное это писать-блять-код», «не надо лишних действий» и прочими мантрами типа «красной таблетки не существует».
    • 0
      Если код работает, его всегда можно улучшать. Особенно при закладывании основ во время быстрых фаз. У нас есть опыт 8х больших версий проекта, все масштабируется

      Если же делать идеально — ну мы как-то 9 месяцев делали очень давно календарь учета рабочего времени
      И он был на смарку. Увы, тогда техник, описанных в статье, я и близко не знал.

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

      Имхо разумеется, все имхо…
  • –11
    Пиши код, блядь!
  • –11
    Сильная статья :) В некоторых деталях я не соглашусь, но такое несогласие вполне нормальное явление.
    С удовольствием бы плюсанул, но, увы, кармы не хватает…
    • –3
      Скажу тем, кто поставил минус: «не нужно сдерживать негатив в себе, расскажите окружающим о том, что вас беспокоит и всем станет от этого лучше» :)
  • 0
    Как здорово, что я не одинок :)
  • +4
    Статья чем то напоминает «Я научился программировать на python за 21 день».

    «Мы использовали всякие способы разработки и поняли что они не эффективны».

    Звучит примерно так же. По крайней мере для меня. Я не говорю что не надо писать код. Весь вопрос какой код и кому писать.
  • +8
    Вот так бывает: загорается человек, делает проект с радостью. Все у него получается, совершенствуется в своем мастерстве.

    Потом доходит до книжек по архитектуре, о проектированию, UML и пр. С глубокой верой (ага, а как же иначе — умные люди ведь писали) тратит время на изучение, читает умные книжки, пытается понять. И все… Дальше одно переливание из пустого в порожнее и потеря времени.
    • 0
      Жаль, что не могу поставить 5 плюсов. Бывает месяца пропадают, на якобы изучение новых технологий, а на самом деле просто ленишься писать код.
      • 0
        согласен
  • 0
    Вы почти пересказали книгу «Факты и заблужнения» профессионального программирования,
    так что умные книги читать надо и делать из них выводы тоже полезно.

    Спасибо Вам за ваш опыт… сам имею похожее мнение, но не решаюсь на озвучку из-за помидоров и попкорна.
  • 0
    Я правильно понял, что вы пришли к канбану?
    • 0
      Да
  • 0
    >первые три-пять итераций системы должны быть обязательны сделаны быстро (как правило, хардкодом и говнокодом).
    это чтоб проект получил пинок в жизнь и хоть как-то существовал… можно утонуть в архитектуре и рефакторинге… и проект утонет. У меня был опыт разработки «мертвворожденных» проектов. Чисто банально — кончилось финансирование, изменились тенденции рынка и т.д…
  • +6
    Конечно, всё держится на людях. Если вам повезло с командой — всё получится, что с методологией и планированием, что без них. Если не повезло — не получится, опять-таки, независимо от методологий. Меня лично бесит, когда начинают рассказывать, что «у нас всё вышло, потому что у нас Agile!». У вас всё вышло, потому что программисты были хорошие.
    • 0
      Поэтому я все усилия, по возможности, прилагаю на поиск и на удержание людей. Не верю в методологии — если нет проджекта, верящего в проект, и команды умных людей, все остальное не имеет значения. И не верю в умение сделать сразу хорошо, а верю в эволюцию
      хорошие слова… есль люди способные довести проект до финиша — есть и проект…
    • 0
      У вас все вышло, потому что вы, к счастью, заебали своим аджайлом своих программистов недостаточно, чтобы окончательно выбить из них инженерный подход и хакерский дух, и они таки сделали вам софт.
      • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Нельзя делить на черное и белое. Главное, конечно, люди. Без них и аджайла и не аджайла не будет. Так же от людей самих зависит, как они лучше работать будут, как понимают методику, по которой работают в проекте.

      Но всё же хорошие программисты в разных условиях по разному будут эффективны. Если приходит менеджер, который узколобо верит только в водопад и планирование и появляется некий комитет «более умных» которые будут утверждать каждый шаг и не давать «умным программистам» вести проект и общаться (разведение грибов), то любой проект можно тормознуть на года и скорость разработки будет одинакова, что при таком же штате индусов/студентов.
  • +2
    простите, креационисты, переходные формы все-таки нашли

    Ого, я что-то пропустил?
    • 0
      Надеюсь, что имелись в виду звенья между нами и нашими предками, а не между уткой и крокодилом…
    • 0
      Что самое интересное, что поскольку теория не подтверждена фактологическими данными (а их на самом деле собрано за сотню лет огромное количество), то опираться на неё для выбора стратегии разработки несколько эмм… Рискованно, что ли. Ведь если нам нужно спроектировать не «изменённый клюв вьюрка», а самого вьюрка с нуля, то отнюдь не факт, что такой подход сработает.

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

      Ну да ладно, это я так, придираюсь. Понятно, что методология, предлагаемая автором (камбан) подтверждена опытом (не только автора, но и крупных корпораций). Просто непроверенная теория, с принципиальными отличиями от разработки софта тут несколько, кхм… Некстати, что ли.
    • 0
      видообразование, наблюдаемая эволюция и тд
      evolbiol.ru/evidence01.htm

  • –1
    Статья супер, спасибо за нее.
  • +1
    и прочитав кучу умных книг про Методологии программирования я понял, что большинство из них ориентированы на большие компании типа Ms, Oracle и создании грандиозных продуктов… В малешьких компаниях с 5-10 чел. с персональной зоной ответственности половина методик просто не кактит. Скрум я пробовал в трех компаниях и он ни где не прижился.
  • 0
    Интересно, что о прославленной ценности людей и потребности нанимать на работу максимально одарённых думает Рей Крок. Почему-то мне кажется, что он бы с вами не согласился. Точнее сказать, согласился бы не во всём.
  • +2
    Хватит нести чепуху: «писать надо говнокодом, хардкодить всё подряд, рефакторинг и проектирование не нужно вообще»
    Вы просто не понимают и не умеют пользоваться этими инструментами. Очень похоже, что архитектор у вас фиговый.

    Лично я пользуюсь постулатами:
    1. Если для разработки нового функционала, необходимо переделывать базис — значит базис изначально был запроектирована не правильно. (у вас именно такая ситуация).
    2. Если нужно изменить существующий фунционал, то менять базис в любом случае придётся, но чем больше говнокода, тем больше изменений и дальнейших багов.

    Например, jQuery изначально хорошо запроектирована, написана без говнокода, через tdd. Это базис на котором разработано сотни тысяч плагинов, который используют на миллионах сайтов и который можно расширять до бесконечности. Как вы думаете, можно ли было реализовать jQuery без проектирования, без tdd и собрать говнокодом?
    Нет!
    • 0
      Я чуть позже напишу статью, возможно

      А пока банальный пример. Любой сказочный архитектор может с пеной у рта говорить про проектирование сразу. НО! реальную проверку система пройдет ТОЛЬКО С ЖИВЫМИ ДАННЫМИ

      без живых данные любые макеты есть херня.

      А дальше — экономика. Чем больше итераций в единицу времени — тем быстрее все поймете. Отсюда говнокод для быстрых первы версий.

      Итак, пример — убийца. Как бы не проектировали самолеты, они все равно падают. Потому что только атмосфера, увы, все выявляет. На чертежах все идеально.

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

      А дальше — см. Выше про скорость эволюционирования. Кто быстрее, тот и победил
      • +1
        Я учился в вузе расчёту самолётов. Там первый просто ломают на стенде при помощи имитации эксплуатационной нагрузки специальными машинами. Так вот если самолёи ломается при нагрузке, более чем на 20% превышающей расчётную, то считается, что он «перетяжелён» и его надо перепроектировать с целью снижения массы. Поэтому, кстати, пассажирский самолёт и должен ломаться при попытке сделать на нём мёртвую петлю. Ну а в очень нештатных погодных условиях типа урагана, при сильных порывах ветра словить на крыло нагрузку более чем на 20% превышающую максимальную расчётную — проще простого: при полёте на максимальной (для планера) скорости порыв ветра со скоростью более 10% от этой максималки и всё…

        Так что атмосфера там почти ничего не выявляет.
        • +1
          Спасибо за уточнение.
          Но суть та же.
          >Там первый просто ломают на стенде при помощи имитации эксплуатационной нагрузки специальными машинами.

          То есть не нарисовали, сразу построили по чертежам и сдали в эксплуатацию.

          Всегда проверяют живыми нагрузками. Либо их аналогом.

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

          Все просто и очень сложно одновременно :)

          • 0
            >То есть не нарисовали, сразу построили по чертежам и сдали в эксплуатацию.

            Самолетной индустрии более 100 лет. Первые самолеты делали без проектировки, в современном понимании этого слова. Современные самолеты это то, что мы получили эволюционным путем за более чем 100 лет развития.

            Индустрия ПО несколько отличается от строительства зданий и самолетов.
        • 0
          Я проектировал самолеты и могу сказать как этот процесс происходит.
          1. Проектирование общей компоновки.
          2. Расчет массово-габаритный (итерационный)
          3. Проектирование аэродинамики: расчеты в первом приближении, программное моделирование, корректировки…
          4. Создание модели, продувка. Корректировки, продувки и т.д. Возврат к п.2. и к п.3.
          Когда все более менее устраивает аэродинамиков и компоновщиков то
          5. расчет на прочность планера и узлов, корректировка массы с учетом реальных узлов. Скорее всего возврат к п.п. 1,2,3
          6. создание массо-габаритного макета, продувка.
          7. Создание узлов в натуральную величину и испытание их на прочность.
          8. Создание лидерного экземпляра и его испытания.

          Т.е. никто не строит самолет только для того, чтобы его сломать :)
          Перед постройкой очень длительное проектирование.
          • 0
            Первый экземпляр всё равно ломают на нагрузочном стенде, по крайней мере раньше было так. Нужна уверенность, что крылья не отломаются при взлёте в начале лётных испытаний;-). С учётом возможной итеративности проектирования вероятность перетяжелённости стремится к нулю…

            Смысл моего коммента был в том, что атмосфера, на самом деле, практически ничего не «показыает», а самолёты ломают обычно не от плохого проектирования, а от попадания туда, где они и должны ломаться.
            • 0
              Ну да, атмосфера — это «практика», которая может стоить дорого :)

      • 0
        Сколько итераций надо сделать что бы без проектирования слепить самолёт? Сколько денег на это будет потрачено?
        • 0
          одну-полторы
          • –1
            На самом деле природа делает миллионы итераций что бы изобрести белку, а потом ещё миллионы итераций что бы изобрести птицу. Всё это она делает вслепую не зная конечной цели и без проектирования. Просто что-то делает, а в результате через милионы лет появляется птица.
          • +1
            Вы сможете без проектирования, без чертежей, без каких либо расчётов собрать самолёт за полторы попытки? И он будет летать??? (речь конечно же не о бумажном самолётике)
            • 0
              Извините, не заметил фразу «без проектирования», думал, вопросы был сколько раз самолёт обычно перепроектируют.
            • 0
              Не все аналогии подходят.

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

              Основная аналогия — это программа подобна строительству дома. Девелопер == строитель, архитектор == архитектор. Каркас программы. Вроде вот оно (если учишься, то очень похоже). Далее, всё кажется немного сложнее. Ведь нужна гибкость. О, тут подходит уже аналогия с некоторыми конструкциями, вроде подъемного крана. Т.е. уже не статическое здание, а имеющие какие-то степени свободы в каких-то измерениях…

              Полный отстой. Аналогии не уместны. Программист == переводчик. Он не пишет конструкции, он пишет мысли, которые должны быть понятны и доступны другим.

              Кстати, самолет — это вариант дома/крана. Самолет может и не будет летать с первого раза. Но миллионы лет не менялись требования к возможности взлететь. Создатели самолетов трудятся над тем, чтобы улучшить характеристики, когда над ними не «висит» заказчик, изменяя характеристики воздуха, турбулентности и не предоставляет новые варианты закона Стокса (так, для примера).
              Потом, второе, почему аналогия не уместна. Самолет делают из метала. А не из утверждений. Это большая разница. Огромная, даже я бы сказал. Возьмите эти чертежи самолета и заставьте их летать. Придется их свернуть в самолетик (в этом случае классная аналогия — чем меньше чертежей, тем легче взлетят).

              Программирование — это язык, а не материал. И чертежи — это язык. Кажется — последний из перечисленных лишний? Если да, вы программист. Если нет, вы сантехник. Вам надо унитазы проектировать, вы любите язык труб. А потом вы хотите, чтобы написанные на языке труб ваши желания, были воплощены на языке программирования (языке материала)? Для вас плохая новость — язык труб очень сильно ущербный и не подходит для изящного описания того, что можно написать на языке программирования. Мало того, язык труб идет вразрез с любимой вами (тех, кто любит язык труб) парадигме ООП. Да и других парадигм. В языке труб нет инкапсуляции. Увы, «архитекторы» хотят всегда видеть всё, вплоть до последней прокладки. Не важно, какое большое здание. Потому что эта последняя прокладка может повлиять на всё большое здание. И поэтому трубы рисуются в плоскости, в разрезе. Нельзя этот рисунок делить на уровни. Любой кусок все равно будет показывать не только внешние, но и внутренние (скрытые) части объектов. Потому что иначе нет смысла рисовать эти трубы, правда? Из этого складывается впечатление, что нужно продумывать всё сразу и что не бывает «локальной» правильности.

              А в коде, как в тексте — всё наоборот. Программист (не сантехник), читает код и сразу либо понимает код либо нет. И второй случай не обязательно зависит от квалификации программиста. Это сигнал, что код не передает смысл ясно.

              Т.е. представление о проектировании и создании «продукта», приходящее в ИТ из «реального» мира не совсем подходит. Потому что программа по сути, это не кирпичи, не аллюминий и не пластилин. Поэтому в цепочке: «идея -> проектирование -> написание кода» — либо «проектирование» лишнее, либо «написание кода». Это не два разных этапа должны быть.
              • 0
                >Программист == переводчик.
                +pow(10,10)
              • +1
                Интересно как же вы будете выделять уровни абстракции без проектирования. Точнее я знаю как пейсать код блеать! Про количество итераций для одного и того же скромно умолчим?

                Маконнела читать до просветления.
                • 0
                  «Интересно как же вы будете выделять уровни абстракции без проектирования»

                  Фаулера и Бека Кента читать до просветления :)

                  Отчего такая любовь к Макконелу? Да, нужен, да, хорош. Но воспринимать надо критически. Не всё подходит для любых языков. Некоторые советы для некоторых языков просто вредны. Макконел С++сник.
                • +1
                  могу кратко пояснить, как выделяются уровни абстракции на ходу. Отлично выделяются и лучше, чем предугадывать.

                  Если вы знакомы с реляционными БД, то сначала на таблицах, так очевиднее.
                  У вас есть пока небольшая бухгалтерская программа. И есть одна из таблиц — Orders (заказы). Колонки, помимо денег, хранят атрибуты заказчика — имя, телефон. Вы это так писали, такие были на данный момент требования. Внезапно обнаруживаете, что связки имен и телефонов повторяются. Что надо делать? Выносить в отдельную таблицу.

                  Точно так же в ООП. У вас на текущий момент класс Order, у которого есть поля — имя и телефон. Выделить абстракцию? Не вопрос. Создаете класс OrderingCustomer. Туда выносите атрибуты — имя и телефон. Здесь, побольше возможностей, поэтому и смотрите, этот класс выносить за пределы класса или внутри класса оставить. Смотрите на текущие требования и выбираете наиболее ограниченный вариант. Проблемы?

                  Второй пример. У вас уже есть таблица OrderingCustomers. Кроме того в процессе разработки при постепенном поступлении требований появилась таблица Employers. И вы видите, что часть колонок пересекается. Имя и телефон. Пора выделить новую сущность — Persons. Вынести эти колонки туда и в таблицах OrderingCustomer и Employers установить ключи. Это простая по сути операция поиска общего и частностей. Частности в исходных таблицах, общее в новой.

                  В ООП. Ровно точно так же. Только еще и поведение выделяете, общее и частное. Уже появляются абстракции. Проблемы?

                  Вдруг вам понадобилось обрабатывать одинаково эти разные объекты. Создаете фабрику, тогда вас перестает волновать, что за объекты. Еще больше понадобилось абстрагирование — создаете интерфейсы, наследуете объекты.

                  Нет никаких проблем создавать абстракции исходя из нужд «здесь и сейчас». И нет никаких проблем делать это постепенно и менять по мере надобности.

                  Заметьте, я примеры дал, почти механические. Вы, теоретически, могли бы сразу увидеть, что имя и телефон относятся к человеку и смоделировать и это. Но а если это не потребуется? Может вы хотите вообще вселенную смоделировать включая атомы? Это не возможно, т.к. объективной истины нет, а модели субъективны )))
                  Заказчик, который дает требования к проекту, мог повернуть не в ту сторону, куда вы предугадываете и с объектами вышла бы незадача. Архитектура в конце концов при постоянном предугадывании становится деревянной, не позволяющей вносить дальнейшие изменения. А потом, появляются мысли и желания о полном переписывании системы. Корни этих желаний — неумении проводить рефакторинг и непонимание, как разрабатывать исходя из текущих требованих по принципу YAGNI.
                  • 0
                    А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные? Ошибка проектирования, а точнее его отсуствия.

                    Я уже сказал весь вопрос в количестве итераций. Проектирование позволяет их уменьшить.

                    В качестве примера могу привести пример разработки бухгалтерского пакета (про частные изменения законодательства в этой сфере я надеюсь вы в курсе.) Так вот. Проект уже 7 месяцев ТОЛЬКО расширяется. При этом требовалось ввести новую форму бухгалтерского учета! (помимо УСН добавить ОСНО) и новый функционал успешно был внедрен без переписывания всего и вся и без рефакторинга, просто еще одна система встала рядом. А по сути система позволяет работать одной компании сразу под несколькими юридическими лицами и для каждого можно указать форму бух учета. Более того я могу точно сказать что переписываться кардинально он не будет никогда. Расширятся изменятся, какие то части будут становится устаревшими, но так что «Аааа тут у нас говнокод поэтому надо переписать» не будет никогда.

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

                    Часто на собеседованиях задаю простой вопрос: Какие уровни абстракции вы видите в web-приложении. На что мне люди начинают с умным видом (с опытом разработки от 5+ лет) что то нести про MVC, про что угодно но только не о том что есть страницы есть лейауты, есть сам по себе в конце концев Запрос на сервер и Ответ с него же. Люди пользуют Yii/CodeInteger/Symphony где все это реализовано. Самый кошмар начинается что когда они рассуждают о приложении они абстрагируются от взятого фреймворка и начинают рисовать ТОЛЬКО модели которые сами создали. Остальное для них архитектурой проекта не является.
                    • 0
                      Проектировать или нет, зависит от способа разработки и архитектуры проекта. Первое, что мы сделали, это разработали API передачи данных с клиента на сервер, и наоборот. К этому добавили особый способ организации кода, и получили простой как двери фреймворк. Его то и фреймворком язык не особо поворачивается назвать. После этого любое проектирование сводится к созданию практически полнофункционального прототипа, и дальнейшему его оживлению. Это очень легко итерируется. Мало того, мы заменили проектирование такой абстракцией как «карта проблем», это примерные требования к разрабатываемой функциональности. Такой себе вектор движения в разработке. Это работает еще и потому, что архитектура слабосвязанная.
                    • +3
                      Как раз в здравом уме так и делают — исходят из требований. Я показал механику на этом примере. Программист, создавая объекты, таблицы или колонки всегда сам себе задает вопрос:
                      — Ровно на этот момент что необходимо и достаточно?

                      Пример вымышленный, возможно, не делают прямо таких мелких шагов, как здесь. Но суть приблизительно такая.
                      Таблицы БД я привел для примера, потому что они более строгие, чем ООП, но вместе с тем похожи на объекты ООП. На таблицах очевиднее, как разделять общее и частности. В ООП — то же самое — выделение базового класса.
                      Но с БД немного другая ситуация, если у вас уже внедрен проект, а вы его дописываете, а не разрабатываете с нуля. Могут быть проблемы с данными. Но в общем, если мы говорим об этапе разработки, то такая техника корректна.

                      Именно так и должно быть, потому что программирование — раздел математики. Это точная наука. Поэтому надо использовать «объективные техники». Т.е. делать как можно меньше предположений, а использовать правила. Информация к нам поступает от заказчика. Поэтому надо опираться только на нее. Если требование не прозвучало, то его не было. А прозвучит, только тогда будем кодить. Кодирование — это требования на языке программирования. И есть различные способы оценки качества кода. Один из них — объем кода. Даже так можно анализировать. Вы выделяете абстракцию (базовые классы) и это сокращает описание. Сокращение описания — это не что иное, как выделение существенной информации. Т.е. знаний.
                      • 0
                        Да да.

                        И получается… высоконагруженный проект (10-15к пользователей ежесекундно в пике и по 5-6к пользователей минимум это надеюсь хайлоад? общий объем базы более 200Гб) В нем «исходя из требований заказчика» делают в славном MySQL поле типа ENUM с ТРЕМЯ ролями пользователей. (НУ БОЛЬШЕ ЖЕ СЕЙЧАС НЕ ТРЕБУЕТСЯ ?!). Потом заказчику вдруг по требовалось внедрить еще пару ролей. А теперь начинается финиш. Изменить структуру нельзя. Ибо простой в несколько часов(миграция с версии на версию, переиндексация базы в связи с изменением струкутуры.) будет стоить 200-300 тысяч рублей. Начинается хардкодинг. Проверка «а какая же у нас роль» превращается в развесистый куст. причем так как уже написанное не предполагало что такое может случится, следовательно пишется развесистый куст SQL/проверок у конкретного пользователя. И хрен с ним что на это уйдет месяц. Месяц работы программиста стоит 30 тысяч рублей. Затраты на простой в 10 раз больше. О качестве кода скромно промолчим.

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

                        Кстати у меня были такие конкуренты. Почитают ТЗ скажут «на данном этапе надо только вот это поэтому мы сделаем это за 150 тысяч рублей! за 2 месяца». Мы со своей группой разработки настаивали что это будет стоить 600 тысяч (цифры не с потолка) и длительность разработки будет 5 месяцев. Прошел год, заказчик звонит нам. Ругается. Извиняется.

                        С него вытащили порядка 1.2 млн рублей, при этом поставленная задача была не выполнена и на 50%. А ему мозг весь проели фразой «Ну вы же хотели получить первую версию за 2 месяца, поэтому писали строго исходя из того что надо было в первую очередь (около 10% от всего что надо)».

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

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

                            Вы еще предложите от ТЗ отказаться.
                            • 0
                              косяк исключительно этапа проектирования. Которого типа и не надо

                              Насколько я понял автора, он не предлагает в принципе отказаться от проектирования. Он говорит о том (насколько я понял), что раз во многих случаях нельзя запроектировать все и сразу, то по сему в этих ситуациях более целесообразно использовать проектирование не предварительное, а эволюционное.
                              • 0
                                Это увеличит срок разработки проекта.
                                • +1
                                  Я бы не стал тут обобщать. Того проекта где изначально достаточно четко видно то, что должно получиться на выходе, скорее всего да — увеличит. А вот того проекта где то, что должно получится на выходе изначально в большом тумане, скорее всего уменьшит.
                                  • 0
                                    По моему наоборот )
                            • 0
                              >Но если для внедрения новых изменений требуется переписать всю систему… это клиника.

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

                              Ну и плюс речь больше, по-моему, о ситуациях когда заказчик не знает, что ему понадобится через два месяца и понадобится ли вообще, чем когда он знает планы на несколько лет, но на первом этапе хочет 10% от возможностей предполагаемой системы. Тут да, для реализации первых 10% нужно сразу учитывать остальные 90. Но не стоит предугадывать за заказчика что его 100% превратятся в 10% и проектировать систему исходя из своих предположений каковы будут 90%. Слишком велика вероятность ошибиться и предусмотреть расширяемость там, где она не потребуется, а там где потребуется не предусмотреть.
                        • +1
                          Вы спросили как можно эволюционно выделять абстракции — и я вам показал как.

                          Подход этот очень здравый. Называется YAGNI. В паре с KISS дает хороший эффект. Подход надо попробовать и прочувствовать, тогда поймете, почему таким образом г… нокод не получается. Никаких костылей не будет. Вы, видимо, забываете о рефакторинге. Именно рефакторинг делает из кода то, что нужно. Архитектура будет не идеальной, возможно, но достаточно хорошей и поддающейся изменениям.

                          Про энам с тремя полями, что-то не понял. Где вы увидели проблему? Есть энам с тремя ролями. Нет никакой сущности, которая описывает роли. Заказчику потребовались новые роли. И что? Заводите таблицу, добавляете роли, сколько хотите. С поля выкашиваете энам, предварительно замапив на новую таблицу. Потом устанавливаете ключ. Работы минут на 15. (тесты также поправить, но всё это не сверхзатратно).

                          Правда, зачем сразу делали энам — загадка. Это не относится к эволюционному программированию. Достаточно на данный момент — это не значит «не использовать реляционную модель».

                          По ТДД всё делается маленькими циклами: тест -> кодирование самым простым и очевидным способом, чтобы тест прошел -> рефакторинг, направленный на приведение кода в нормальный вид.

                          Последний шаг как раз и гарантирует, что не будет г… нокода. То, что нужно на данный момент, не относится к рефакторингу. Рефакторинг — обязательная часть процесса. Нельзя рассуждать так: оно на данный момент работает и этого достаточно, поэтому не будем рефакторить. Достаточность относится ко всему, кроме тестов и рефакторинга — это часть процесса. В какой-то момент и энамы исчезнут.

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

                          Вот здесь и помогают тесты. А рефакторинг помогает быть «коду в форме» и готовым к любым изменениям. Гибкость — это не всегда гибкость. Если вы что-то предугадываете, закладывая гибкость, то это означает жесткость изменений в других направлениях. Постоянный рефакторинг и соответствие текущим требованиям позволяют быть проекту достаточно гибким в любом направлении.
                          • 0
                            Я где то написал что я против TDD? Это хорошо, и правильно.

                            Нет гибкость это именно гибкость. Как угодно и куда угодно. От широкого к узкому. Понятно что могут возникать вещи и некоторые вещи будут вынесены в более высокие слои абстракции. Но в целом…

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

                            Я еще раз говорю то что вы говорите, что это займет 15 минут, это исключительно в ваших фантазиях. В реальности, заняло месяц. Без TDD и без ООП правда писалось все.
                            • +1
                              Гибкости куда угодно и как угодно не бывает. Гибкость обычно в каком-то направлении (степени свободы), а в других жесткость.

                              Кстати, жесткость — это самое важное, намного важнее гибкости. Жесткость — это строгая типизация. Жесткость — это выражение того, что вы хотите и способность программы от этого не отклоняться.

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

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

                              Какой-то простой пример. Моделируете предметную область. Объекты: яблоко, груша, арбуз.
                              По YAGNI: не делаете общего предка. Понадобилось, уточнились требования — сделали. Но еще не знаете, как сделать иерархию, заказчик всё еще молчит. Но и не страшно, потом расширите.
                              По предугадывание. Закладываете гибкость и пишете базовый «фрукт», «овощь», «еда». Можете потом расширять иерархию, если угадали, добавлять новые фрукты, овощи. Всё для этого готово. Но проблема, если заказчика будет интересовать совсем не это, а: «форма» или «цвет» или даже «полосатость». Что в этом случае делать? Выпиливать старый предугаданный код. Может случиться, что ваша иерархия не только бесполезна, а очень мешает.

                              1. Вы потратили время на написание кода. Вы могли бы почти такое же время потратить и потом, но вы делали заранее.
                              2.1 Вы потратили время на выпиливание не нужного кода.
                              2.2 Вы не потратили время на выпиливание кода, он не вредит, но может «авось» понадобиться. Тогда вы тратите время на поддержку кода (юнит-тесты).

                              Вообще, юнит-тесты заставляют прилагать усилия и благодаря этому стараться не делать лишнего и не отрываться от Земли.
                              • 0
                                Про объекты. Либо у вас серьезные проблемы с пониманием наследования и изначального проектирования, либо на этом мысль оканчивается.
                                • 0
                                  Ну тогда и я про ваши проблемы расскажу.

                                  Есть три этапа становления программиста. Может больше, но я пока не знаю новых.

                                  1. Новичок. Учится кодить и кодит хоть как-нибудь и радуется, что программы его вообще работают.
                                  2. Любовь к паттернам и проектированию. Наступает после детального изучения книги банды четырех. Человеку кажется, что если он понял, как и что делает каждый паттерн, что такое наследование, то можно ВСЁ запроектировать.
                                  3. Отказ от паттернов. Переход на эволюционное проектирование. ТДД. Да, я верно говорю — ТДД — это не просто организация процесса. Это эволюционное проектирование. Оно явно и не явно заставляет так проектировать.

                                  Вы пока на втором этапе. Эта статья написана человеком, либо на третьем этапе, либо переходящим на третий. У него появилось откровение, что можно разбираться на ходу с проблемами (поэтому красной таблетки не существует).

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

                                  Возможно будет четвертый этап — уход от говноязыков.
                                  • 0
                                    Что-то мне подсказывает что вы не правы =) Но, пусть каждый останется при своем мнении.
                                  • 0
                                    Мне как-то удаётся совмещать 2 и 3. Вроде TDD чистой воды, но после рефакторинга «получаются» паттерны. А зачастую фазой «хоть как бы тест прошёл» вообще пренебрегаешь и сразу «рисуешь» патерн, которому в обозримом будущем рефакторинг не понадобится.
                                    • 0
                                      Это следующий этап у меня получился почти автоматически после этапа «на assert(sum(2,2), 4) пишем return 4»
                                    • 0
                                      Ну так, да, паттерны сами получаются. Поэтому и говорю про отказ от паттернов. В том плане, что лучше бы о них не думать, потому как они заставляют думать наперед. Другое дело, когда они естественно появляются. Не все, конечно.
                                      Но оказывается, есть ряд паттернов, которые часто используются и часто появляются. При этом архитектура как бы «утрясается». Сначала пишете как-то, потом рефакторингом трясете до положения, когда вам код нравится. Вместе с паттернами. Можно было бы графически нарисовать, как получается на диаграммах Эйлера, сначала смысловое пересечение, как потом в коде два разных класса соединяются через базовый, появляется степень свободы (и жесткость). Как потом отвязываемся от классов через интерфейс. Буквально, во многих случаях можно представлять графически воздействие требования, появление в результате этого необходимости пересмотреть жесткость и гибкость в каких-то измерениях (а программа — это многомерная структура, где мерность — количество независимых переменных).

                                      Такое воображение может быть много кому помогло бы представить, почему возможно в ООП эволюционное проектирование.
                        • 0
                          m36 исходит из «сильной» точки зрения — "(сможем и будем) сделать когда надо", а вы — и- «слабой» — "(лучше) сделать когда можно". Из «слабой» позиции можно охватить в разы больший scope, но, в общем, с меньшей надёжностью.

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

                          Вопрос — почему простой в несколько часов стОит как 6-10 месяцев (1200-1700 часов) работы программиста? С этого и начинается — не хотят отдавать 300 тыр за простой — отдают 1200 тыр за всё по итогам…
                          • 0
                            Потому что владельцы боятся что такой простой отпугнет пользователей и это снизит приход денег. А там доходность проекта более 1,5 млн $ в месяц. Типа лучше незаметно для пользователей накидать говно-код чтобы это не заметили, и потратить денег на это, но по итогу срубить больше (исключительно по их мнению)

                            Я говорю что проектировать надо всегда. Где я написал про «лучше когда можно»? Вот никогда не поверю что даже самая простая система может быть написана без предварительного проектирования. Оно в любом случае есть хоть эволюционное хоть какое. Предварительное позволяет в целом снизить стоимость дальнейшей разработки. Тут я более чем полностью согласен с дядькой написавшей книжку Совершенный код.

                            Разработка через тестирование это лишь организация разработки в целом. А не разработка архитектуры проекта. Это все таки разные вещи.
                            • 0
                              «Лучше когда можно» — это «на стадии проектирования», до того, как реально будет нужно.

                              Насчёт «Code complete» — ну, С++ уже само по себе отпугивает и smells bad. Для Java это — прошлая эпоха. Если книгу про то, что водопад лучше аджиля, написал С++-ник, то это следует отнести на профессиональную деформацию восприятия: для С++ это в значительной степени так, в то время, как для Java есть автоматический рефакторинг средствами IDE и дизайн можно улучшить уже после написания кода (это возможно за счёт отсутствия у языка Java, по сравнению с С++, излишней «гибкости» в нехорошую сторону). Мартин Фаулер теперь пишет, что улучшения дизайна можно безопасно оставлять на потом.
                              • 0
                                Не путайте дизайн отдельных частей и архитектуру проекта.
                    • 0
                      А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные?
                      У Заказа могут быть просто поля с контактной информацией закзачика.
                      • 0
                        Можно сделать и просто. Потом будет не просто =)
                        • 0
                          Веселуха будет когда пользователи начнут удалять и редактировать свои профили… тогда окажется, что нормализация — это не всегда хорошо…
                          • 0
                            Нормализация как раз позволяет вполне безболезненно вносить любые изменения в архитектуру. Может мы немного по-разному понимаем этот термин?
                            • 0
                              Ну, есть шанс, что это, если разрешить, повлечёт изменение в уже сделанных ими заказах или вообще удаление их…

                              Ну, можно сделать версионирование — тогда данные о пользователе в заказе останутся на момент внесения или исполнения заказа…
                              • 0
                                Ну так не разрешать. Нормализация ведь не «управляет» поведением системы, которая оперирует данными.
                                • 0
                                  «ON DELETE NO ACTION» — и будет управлять, точнее, ограничивать… Нормализация — это же система избегания дублирования данных…
                                  • 0
                                    «ON DELETE NO ACTION» — поведение СУБД, это несколько далековато от декомпозиции
                          • 0
                            Смотря что и КАК нормализировать =) вообще уникальные профили для пользователей не проблема. у меня есть проект с 8 ролями, хотя изначально предполагалась одна, все расширилось отлично. Наверное я что то не знаю и делаю не правильно =(
                    • +1
                      А кто собственно в здравом уме будет пересекать сущности Заказ и Персональные данные?

                      Бизнес. Сам заказчик или аналитик. Если я, как непосредственный разработчик, получаю на входе нечто вроде: «Есть сущность „Заказ“, у которого есть реквизиты „Номер“, „Дата“, „ФИО“, „Адрес“, „Телефон“, „Описание“ и „Сумма“», да ещё после уточнения получаю информацию о том, что персональные данные практически не дублируются, а если и дублируются, то информация об этом заказчику неинтересна, то какие у меня основания выделять «ФИО», «Адрес», «Телефон» в отдельную сущность, если в бизнес-процессах она как отдельная сущность не фигурирует, а фигурируют её реквизиты как реквизиты другой сущности? Введение отдельного типа сущностей усложнит архитектуру, а то и пользовательский интерфейс, и увеличит ресурсоемкость без каких-либо профитов для бизнеса. Типичный оверинженеринг. А не вводя такую сущность мы получим простое как три копейки приложение, понятное любому студенту. Изменятся бизнес-требования, например, заказчику нужны будут отчёты не только по датам, но и по «ФИО», «Адрес», «Телефон» как единой сущности, то есть в его бизнес-процессах появится сущность «покупатель и его контактные данные», тогда и введём, заодно уточнив как покупателя идентифицировать. А пока у него «покупатель» как отдельная сущность в процессах не фигурирует, то он просто вопроса не поймёт и мы будем вынуждены принимать решение (или вынудим заказчика принять непонятно зачем) исходя из своего видения, которое вполне может оказаться ошибочным в будущем. И нам придётся систему не доделывать, а переделывать.
                      • 0
                        Как у вас все сложно.
                    • +1
                      >Часто на собеседованиях задаю простой вопрос: Какие уровни абстракции вы видите в web-приложении.

                      На такой вопрос задаю встречный: «Что считаем веб-приложением и с какого уровня начинать?» :)
                      • 0
                        С TCP/IP :)
              • +1
                Читал, что, для нормальности аналогии, строительство дома — это запуск программы, а программа — проект…
      • 0
        А чем вам UnitTest не работа с живыми данными?
    • 0
      Вы досконально знаете историю написания jQuery? Уверены, что там не было итераций говнокод-рефакториг?
      • 0
        Если даже там был когда-то говнокод, то сейчас его нет — значит произвели рефакторинг или всё переписали с ноля. В любом случае приходим к выводу о том, что рефакторинг необходим.
    • 0
      Я читал только что-то вроде «зачем нужно проектирование, когда есть рефакторинг»…
  • +1
    «Мозги у людей отличаются в разы». Сильная фраза
  • +2
    Хорошая статья)
    Мне тоже надоели бесконечные Scrum-митинги и презентации, я не очень-то люблю UML-диаграммы (хотя вполне хорошо их знаю), уже раздражают вопросы на тестировании типа «чем фасад отличается от адаптера, а фабрика от абстрактной фабрики» — т.к. умение найти красивое архитектурное решение считаю важнее, чем помнить его «официальное название». Все так. Но! Что в статье не отражено, так это обратная сторона.

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

    Золотая середина, без отклонения в крайности. Вот о чем речь. То, чему учил Будда почти 2 тысячелетия назад, правда в применении ко всей нашей жизни. Жизнь с тех пор изменилась, в ней появилась такая сфера, как IT. Удивительно, но чтобы понять, что эта мудрость применима и в IT-индустрии, индустрии потребовалось много лет. Сколько же длилась эта болезнь «вирусом» Rup, Scrum, UML-фанатизмом, GoF-религией. В разуме разработчиков, кажется, начался иммунный ответ к этим болезненным перекосам, но у менеджеров пока нет.
    • 0
      Что такое «русский скрам, бессмысленный и беспощадный», я на своей шкуре испытал три года назад…
    • 0
      я могу сказать одно.

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

      у меня программисты работают по разному графику — можно и в 9 начать, и в 12. и нет проблем, чтобы кто-то остался и добил. я доверяю людям, но если спалил на халтурах — пощады не будет :)

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

      нужно дать людям ТВОРИТЬ. ведь программист — творческая работа. не терпит муштры, если человек умный. ИМХО разумеется.
  • 0
    Вчера здесь был пост «Иллюзия эффективной разработки: проектирование» на ту же тему.
    Я полностью согласен, что люди и их профессионализм и эффективность играют ключевую роль в успехе.
    Но кто-нибудь скажет мне, как таких определить?
    К нам на собеседования приходит много людей, как определить, кто из них будет в десять раз эффективней, а кто нет?
    Не задавать же им вопрос: Почему канализационные люки круглые?
    Тесты, из серии Oracle/Sun/MS Certified, не всегда показывают эффективность, к тому же люди могут даже не знать тех технологий, которые мы используем, но все равно быть эффективными, и достойными быть нанятыми.

    • 0
      Но кто-нибудь скажет мне, как таких определить?

      Никак. Ну либо надо быть гением, чтобы суметь с первого раза разглядеть человека. Только в процессе работы можно выяснить кто чего стоит. И это действительно большая проблема.
      • 0
        Все-таки какая-то методика оценки должна быть, может быть люди, которые проводят большое количество интервью ей поделятся?
        • +1
          Большинство на собеседованиях врут.
          • 0
            Скажем так, приукрашивают. Скрывают место работы, на котором не прошли испытательный срок. Приукрашивают причины увольнения. Объявляют себя специалистами в технологиях, которые их заставили освоить принудительно и на которых они могут програмировать только методом copy-paste-edit.
      • 0
        > Только в процессе работы можно выяснить кто чего стоит.
        Ну вот вам и ответ! Самые «приятные» во всех отношениях организации, где я работал и работаю, при приеме на работу ограничивались самым элементарным собеседованием, а дальше испытательный срок. А вот из тех где было: покажите нам свое портфолио и расскажите о вашей роли на каждом сделаном проекте + несколько интервью разного уровня + тестовое задание на 1-2 дня и прочая херня, я очень быстро уходил т.к. при подобном подходе к набору персонала коллектив там как правило состоит из скажем так «не самых лучших» работников.
        • 0
          Google, Microsoft, Яндекс…
          • 0
            Там сейчас именно такой подход к подбору персонала, т.к. они выросли до размеров мегакорпораций и им надо очень много стандартных «винтиков» в отлаженный механизм, с их бюджетами и маркетингом это вполне оправдано. Хотя мне было бы скучно изо дня в день заниматься однообразной рутиной пусть даже в такой «громкой» конторе — зарплаты у «винтиков» там не намного больше чем в более «компактных» командах на более интересных проектах, чтобы компенсировать такую скуку.
            • 0
              хз хз, у меня знакомый работает в Эппл, другой в Гугл.
              очень творческая там атмосфера.
    • 0
      Почему канализационные люки круглые?
      И как обычно на него отвечают?
      • 0
        Когда мне его первый раз задали, я ответил так: «потому что в круглую дырку влезет чувак примерно таких же размеров, что и в квадратную, а металла уходит на круглую дырку меньше». Задавая вопрос мне сказали, что так делают с каких-то очень давних веков, вот я и подумал, что тогда в древности у них металл был в дефиците, и они таким образом его экономили.

        Потом (уже после интервью) я понял, каким бредом была моя идея, а так же то, что ответ на этот вопрос, ничего не говорит о профессионализме или эффективности программиста, поэтому сам такие не задаю, и как на него обычно отвечают не знаю.

        Поэтому меня интересует, что надо спрашивать и на что обращать внимание в ответах? У меня конечно, есть любимые вопросы, но я отнюдь не уверен, что это оптимальный набор, позволяющий «раскрыть» весь потенциал кандидата.
        • 0
          Вы написали «К нам на собеседования приходит много людей», из чего я заключил, что вы часто их проводитете и там нередко задаёте такой вопрос, вот и поинтересовался. Хотя мой ответ — «чтоб крышка не проваливалась», ваш тоже мне кажется интересным. Интереснее всего будет, если на самом деле прав вы, а непроваливающаяся крышка пошла сама собой как бесплатный бонус…
          • 0
            На самом деле математические корни у обоих ответов одинаковы. Круг — идеальная фигура по многим соотношениям параметров.
            • 0
              Круг — идеальная фигура по многим соотношениям параметров.
              О! Идеальный ответ. Даже дзеном отдаёт.
        • 0
          А я люблю задавать такие вопросы. Не как определяющий судьбу кандидата, разумеется, но с единственной целью: посмотреть, как человек возьмется за нестандартную задачу. Если скажет хоть что-то (сиречь, начнет думать) — ок, пойдем дальше.
          Если нет — обычно это означает, что несмотря на тысячу прочитанных умных книг, первая же практическая задача поставит его в тупик.
          Вопрос про люки хорош тем, что на него не существует «правильного ответа». Как и подавляющее число задач из повседневной жизни.
          • +1
            «Готовься к собеседованию: читай хабросрачи».
    • 0
      да, этот пост меня вдохновил.

      спасибо его автору :)

      определить — думаю, только на испытательном. в бою.

      иначе никак
  • 0
    Странно, что еще никто не вспомнил 37signals с их книгами «Getting real» и «Rework». Оттуда много почерпнул для себя хорошего и умного. Некоторые идеи автора пересекаются с их размышлениями.
    • +1
      да, классные ребята
      14 человек, миллионы долларов оборота. красавцы.

      а фирма, поднявшая ФРЕЙМВОРК до МИРОВОГО уровня… я апплодирую им. Хотя считаю, что Питон победит зло :)
  • +4
    Вдохновенные люди — это, конечно, отлично, но и их нужно организовать, чтобы не было проблемы «лебедя, рака и щуки».
    А в посте говорится, что не надо. Печалько.
  • 0
    Один великолепный программист стоит десятырех раздолбаев или средненьких


    Ну, не совсем уж и так. Правильно даже иметь одного продвинутого и несколько средненьких
    • 0
      Кто-то работать тоже должон. Как правило, у гениев мало упорства, как у творческих натур. А середнячки, как ремесленники, не особо напрягаясь, генерят код.
  • –1
    РЕСПЕКТ!

    сразу видно что практик, а не теоретик!
  • 0
    Офигенно. Хочу работать в такой команде. Уже в мире ИТ 9 лет и всегда считал, что это трата времени. Многие мои знакомые программисты, у которых проекты по 10 лет, в результате все равно получается костыли и вся архитектура ООП разваливается. Не получается и даже после переписывания с 0, все равно с появлением новых требований появятся костыли. Поэтому: МЫ ПИШЕМ КОД!
    • 0
      ООП разваливается если он изначально спроектирован криво. Основная проблема людей что в ООП люди видят волшебную таблетку, при этом проектировать абсолютно забывают/не умеют/не способны/не хотят.

      История из жизни:
      АП — Архитектор проекта. Я — соотвецвенно Я.

      АП: Зачем нам писать свои костыли ?! Нам надо быстрее! Мы возьмем Симфони.
      Я: Ээээ ?! А почему именно Симфони ?!
      АП: Я видел ролик где люди соревновались в написании хеллоу-вордов. На Симфони это сделали быстрее всего.
      Я: WTF ?!?!?!

      Итог… Проект до сих пор трудно и тяжело «рефакторится», так как внезапно АП понял что ORM в проекте был совершенно не нужен и привел к адскому усложнению проекта в целом.

      Виноват ли в этом Симфони? вряд ли. А вот к квалификации таких архитекторов у меня много вопросов.
      • 0
        По уму, к чужим фреймворкам всё равно постепенно дописываются свои прокладки…
      • 0
        Я не знаю проекта без костылей. За жизнь проекта, ситуация меняется, появляются новые требования, которые уже не вяжутся с архитектурой. Что касается фреймворков, ORM, ООП, для каждой задачи нужно свое решение. Если проект можно разработать без фреймворка, то лучше без него. Если стоит задача, чтоб проект быстро работал, то лучше писать с 0.
        Что касается вашей истории, вы должны были попробовать переубедить архитектора, что вы будите делать в будущем.
        • 0
          Я знаю
          • 0
            И я
        • 0
          Делать не мне надо, так что сами себе злые буратины. А Проекты без костылей были есть и будут =) Мало их правда.
          • 0
            Я точно напишу статью, чтобы ни одного неуверенного не осталось.

            Подсоберу примерчиков.

            Ибо для опровержения утверждения в математике достаточно контрпримера.
      • +1
        ORM — опциональный элемент symfony. Хотя возможно стоило взять не Symfony Framework, а только необходимые Symfony Components.
        • –1
          Я в курсе.
      • 0
        Бля, не бывает правильного проектирования.

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

        А потом на деле там оказывается какая-нибудь фамилия 300 символов, и нужно менять поле в БД. Данных оказывается много с дублями, и нужна подсистема поиска дублей. и Так далее.

        Поэтому только так. Живые данные, быстрые прототипы, без всяких понтов. Обкатать, понять бизнес-логику, предметную область. Утрясти функционал заказчика. Ибо круче живых прототипов ничего нет, сраные axure-generated Htmlки отдыхают, и тем более скетчи-картинки.

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

          • 0
            А кто спорит? Если можно сделать быстро, спроектировав неплохо — надо делать. А еще лучше — взять готовую хорошую либу и сэкономить себе миллион-другой нервных клеток.

    • 0
      welcome!
  • +1
    Только одна ссылка: No Silver Bullet.
  • 0
    Подписываюсь под каждым словом. Когда команда отбрасывает всю эту не нужную шелуху из костылей, обеспечена отличной внутренней мотивацией её эффективность повышается в десятки раз. Очень здорово, что вы об этом написали. Так как тема эта из области теологии. Многие до сих пор верят в волшебные методики.
    • 0
      Такое вполне возможно при отличной команде. Зачастую группа разработки такой не является.
  • +3
    Один великолепный программист стоит десятырех раздолбаев или средненьких
    Зато организация процесса в расчёте на десятерых раздолбаев или средненьких в сто раз надёжнее, чем в расчёте на одного великолепного.
    • +1
      Согласен. Этот гений потом уйдет «fellow» в какой-нибудь гугол, а обычным разработчикам нужно будет дальше развивать его код. И, несмотря на то, что сверхвысококвалифицированные программисты пишут очень простой, логичный, легко читаемый и поддерживаемый код — за этй внешней простотой всегда скрыт айсберг теории — которую гений знает, а средний программист по больнице — нет. Они смогут его код читать и патчить — но при попытке что-то в нем поменять это будет война миров, хаос и разрушение.
  • +1
    Здесь я буду краток. Мы попробовали фиксированные итерации, пробуем канбан. Так как я программист, помимо PM — могу подтвердить, что все методологии действительно сводятся к пиши-код-блять.рф.


    Сколько лет опыта руководства разработкой с полной ответственностью за проекты, если не секрет? У меня в принципе немного — я чуть больше десяти лет занимался непосредственно разработкой (десктоп, с++, сеть, процессы) и сейчас шестой год руковожу (десктоп, айфоны, андроиды, вся инфраструктура). Успешных проектов пока меньше десяти :(. Но не могу сказать, что методология прямо так и не нужна. В идеальном мире, где можной выйти на улицу и нанять кучку профильных гениев — может быть. Но в суройвой объективной реальности, гле вакансии на iPhone разработчика на 100к+ на руки белыми весят месяцами (!!!) без откликов приходится работать со средними разработчиками по рынку. Просто чтобы сохранить хотя бы подобие предсказуемости и устойчивости к увольнению одного-двух человек из каманды. И тут уже не все так просто :(.
    • +1
      и как работаете в такой ситуации?
      • +1
        У меня есть некие самописные процессы, которые я вывел из существующих и на основании своего опыта. Стараюсь улучшать и дорабатывать по мере возможности.
        Есть некая подборка тулзов для организации этого дела на практике. Платных, open source, что-то сам писал. Тоже потихоньку дотачиваю напильником.

        Вообщем кручусь как могу. Без процессов не смог бы.
        • +1
          опубликуете описание? :)
          • 0
            Мои извинения, но я пока еще не такой крутой менеджер, как программист. Вот лет через пять-десять… А пока я лучше поппишу про то, в чем действительно хорошо разбираюсь. Следующая фундаментальная статья у меня будет про DSL в питоне — там будет интересно.
            • 0
              Ждем-с!
    • 0
      гле вакансии на iPhone разработчика на 100к+ на руки белыми весят месяцами (!!!) без откликов

      Вы действительно рассчитывали нанять профильного гения за сумму порядка 100к просто разместив вакансию, не проводя активный хантинг? Если требования были «гениальными», то, по-моему, неудивительно, что никто не откликнулся.
      • 0
        Нет, это я в целом привожу пример состояния рынка в дефолт сити. Требования были более чем скромные.
        • 0
          Тогда, странно, что к вам не стучались те, кто про разработку под iOS только на хабре читал. Хотя, может, «гениальные» требования они прочитали между строк, ориентируясь на сумму. Такое бывет. Вижу, например, знание и зарплату в 100к, так даже не дергаюсь, если на этом фреймворке только бложик «написал». Бы ла бы зарплата в 50к указана — отправил бы резюме на ту же вакансию.
          • 0
            Стучались, конечно — но я имею в виду отсутствие релевантных откликов. «Под айфон ни разу не писал, Objective-C и С++ не знаю — но быстро учусь» фильтровались.
            • 0
              да, очень бесят.

              готовы научиться ВСЕМУ за ваш счет. классно, думаю.
              а ЗП хотят по максимуму :)

              впрочем, иногда бывает, беру. когда очень талантливые и обучаемые.
    • +1
      У меня меньше, два года полноценное руководство отделом. До этого, правда, 6 лет назад была своя студия на фрилансе, и там были интересные проекты (мы даже прорабатывали клон sape.ru).
      Во многом — у меня хорошие учителя просто, с большим опытом. Который легко подтверждается на практике.
  • –1
    Должен сказать автору спасибо! Я уже начал думать, что я один в этом мире :)
  • +5
    Автор сделал очень верное наблюдение — методологии (управления, проектирования, разработки — можете продолжить список) не приносят ожидаемой от них пользы. Но при этом он делает совершенно неправильный вывод — что эти методологии не нужны. Да, бесспорно, люди важны. Опыт бесценен и незаменим. Но нельзя же строить опыт на пустом месте?

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

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

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

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

    Люди — это очень важно. Хороший специалист должен быть образован. Он должен иметь большой опыт. Все обруганные в статье методологии — это чей-то опыт. Было бы глупо им разбрасываться. Поэтому я добавлю, что хороший специалист получает опыт не только за счет своих шишек, но и умеет воспользоваться чужим, как положительным, так и отрицательным.
    • 0
      А ещё для сбора денег по-видимому используются всякие SOLID, MVC и дизайн-паттерны. Иначе чем объяснить то, что о них так избыточно много говорят.
      • 0
        Это, скорее, первичный фильтр при найме.
      • 0
        ну, на самом деле, если систему написали быстро и просто и она 10 лет работает, то она может быть сделана без MVC, SOLID (SOLID кул тема), и так далее, и вовсе не нуждаться в рефакторинге.

        другое дело, если, как у меня, бизнес-сущности растут на грибах и правила их взаимодействия. вот там договор, а теперь у договора тарифные блоки (тариф — сложная сущность 30+ параметров), а теперь у нас еще связаны брони с договором. а теперь брони еще бывают такие и сякие, и для таких-то услуг без них нельзя создать договор… а комбинаций цен 200,000 и тд.
    • 0
      От любой методологии есть реальная польза, когда она применяется в соответствии с допущениями, для которых была создана.
      Даю 95%, что на момент создания методологии эти допущения ещё неочевидны.
      • 0
        я уверен, что они неочевидны и даже после этого. Но это не говорит о том, что методология бесполезна.
        Она полезна, поскольку несет в себе бесценный опыт людей, которые её придумали. Очень важно понимать ПОЧЕМУ и ЗАЧЕМ создана эта методология. Но это совершенно не означает, что она всем поможет и всех спасет.
  • +1
    После покупки Люцента Алкатель забросил свою систему ИП-ТВ и стал мигрировать на люцентовскую. «Родная» алкателевская была добротно спроектирована «сверху вниз» на основе решений от Оракла. Люцентовскую изначально писало какое-то подразделение испанской Телефоники для одного городка в неколько десятков тысяч человек, потом это подразделение продали Люценту и в Люценте систему стали масштабировать «снизу вверх». На той стадии, когда меня сократили из Алкателя — весна-лето 2009 — для люцентовской системы ещё не было автоматического инсталлятора, её приходилось разворачивать в полуручном режиме, при этом рещение о миграции на неё было принято уже минимум полгода как. Так что вот, пример из практики на тему «проектирование versus итеративность».
    • 0
      ну вообще, эволюционный рефакторинг не исключает, что после опыта снизу вверх вы оцените все риски, и сверху вниз спроектируете простой и нужный вариант функционала и быстро его напишите…

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