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

    О чем это


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

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

    На самом деле, после пары десятков проектов я пришел к выводу, что все это — не более чем заблуждения, и чудеса происходят только в книгах авторов, которые делают на своих бестселлерах миллионы. Или в головах консультантов, которые делают деньги, продавая вам фуфло в виде 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 и движущая сила мира. О вас хорошо сказал Айзек Азимов в своем рассказе «Профессия».

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

    Похожие публикации

    Комментарии 348

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

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

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

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

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

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

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

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

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

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

              … И когда я сотворю что задумал, даже боги ужаснутся, не то что работодатель!!! )

              +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
                                                                                                                                                                                              Как раз в здравом уме так и делают — исходят из требований. Я показал механику на этом примере. Программист, создавая объекты, таблицы или колонки всегда сам себе задает вопрос:
                                                                                                                                                                                              — Ровно на этот момент что необходимо и достаточно?

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

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