Agile в небольших командах — как красиво сломать себе шею

    Я весело вещал на киевской партнерке про Agile в небольших командах. Но… недовещал, а только разогрел. Хочется, все таки, закончить повествование и рассказать, наконец, правду-матку о том, как все таки красиво Agile ломает шеи разработчикам и менеджерам! Наливаем кофе и ныряем под кат, будет очень весело.

    Программирование — только для умных

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

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

    А самое страшное, что может тут произойти — это работать с ненастоящими программистами долго и успешно над простыми примитивными проектами, не требующих глубоких знаний, а затем заняться интересным, сложным проектом с примесью Computer Science — веселье предстоит просто улетное: все ломанутся на StackOverflow и начнут заново изобретать… алгоритмы и удивляться, что TCP отличается от IP!

    Детали — важны, как никогда ранее

    К сожалению, чтобы программировать правильно, нужно знать язык программирования глубоко и широко. Если это простые динамические языки типа Python, Ruby, PHP, JavaScript — то знать там особо нечего, тонкостей и внезапных сложностей практически нет и можно лепить что лепится и оно будет как-то работать до определенного момента.

    Но чтобы писать на «настоящих» промышленных ЯП, таких как C++, Java или C# — требуется интенсивная подготовка в течении парочки лет и чтение и понимание толстых книжечек и всех тонкостей языка. Но это только начало — важно научиться программировать в парадигме ООП — а это еще тройка лет и чтение другой стопки книжечек по шаблонам проектирования.

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

    Проектирование — иначе просто нельзя

    Вы правда поверили сказкам, что можно размазать эмоциональный бред на листочки, а на обратной стороне написать definition of done в стиле «фи/не фи» и не проектировать? Да вы, братец, с ума сошли. Любая более-менее сложная система требует обмозговывания и потребления у доски пары десятков чашек кофе. Логическая схема сущностей, ролей, формальное описание алгоритмов — должны быть сделаны с полной алгебраической беспощадностью. Тут, как раз, пригодится знание UML. Иначе вы будете похожи на обезьяну, с пренебрежением поглядывающую на коммутационный щит с проводами с мыслью: «фигня вопрос, все тут и так понятно, главное — я такая красивая». Поэтому не позволяйте глупости и лени захватить мозг проектной команды и всегда строго формализуйте сложные вещи.

    Программистами — не нужно управлять

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

    До сих пор не знаете самый любимый фильм у программистов? Вот же он — обязательно устраивайте еженедельный просмотр, кино отлично мотивирует, особенно перед встречами с клиентом!

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

    Но если менеджер сознательно «включает дурачка», надевает «розовые очки» и начинает публично играться в листочки c эмоциональным бредом (ProductBacklog), досочки (Burndown), картишки (PlanningPoker) и улыбаться на Retrospective так, что ждешь, что вот вот случится каминг-аут — то, скорее всего, проект обречен и сделать уже ничего нельзя.

    «Из курочки — сварит и дурочка»

    Поэтому — расслабьтесь и не пытайтесь изучить и отличить "водопад" от RUP, а Scrum от Kanban — это не поможет. Сосредоточьте усилия на поиске настоящих программистов! Команда сама выберет наиболее адекватную проекту методологию, число тестировщиков, аналитиков и, что особенно важно, бригаду адаптации эмоциональных эманаций клиента в область строгой формализации и алгоритмов — всяких менеджеров разных мастей и научит их работать.

    Парадокс, но имея адекватную команду программистов, становится неважно, какую методологию выбрать — поверьте, любая методология, даже самая «страшная и ужжжасная» под именем «без ТЗ» — приведет проект к успеху и взлету в срок с прекрасным техническим качеством. В принципе, можно даже стать волшебником изумрудного города — и проект все равно взлетит. И наоборот — набрав «сантехников» по объявлению, вам не поможет даже самая правильная, единственная правильная методология в мире — водопад. Люди запутаются в собственном коде и документации до такой степени, что придется набирать несколько каскадов тестировщиков, проверяющих баги предыдущего каскада (в периоде).

    Agile — для спецназа

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

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

    Никогда не забывайте историю появления XP и судьбу девушки-product owner, которую Kent Beck с невменяемыми заказчиками довели до паралича и нервного тика лица. Зато да, книжки написали интересные… :-)

    Качество кода и сплоченность команды — превыше всего

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

    А что такое красота программного кода? Это:

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

    Человек открывает код… и ему приятно развивать его дальше, у него повышается настроение! А бывает же, что открываешь код и с трудом сдерживаешься от рвоты — это правда жизни.

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

    Выводы
    • Не забивайте себе голову методологиями разработки программного обеспечения — это не поможет
    • Сосредоточьтесь в первую очередь на поиске и наеме профессиональных, настоящих программистов и вспомогательного персонала (аналитики, тестировщики, менеджеры всех мастей)
    • Если удалось подобрать адекватную команду — пусть она сама выберет методологию разработки и знайте, что с любой методологией проект скорее всего взлетит
    • Если не удалось подобрать адекватную команду — лучше меняйте работу, ибо вас скорее всего загрызут «истеричные тетеньки-инвесторы» политическими требованиями дать оценки и попасть в сроки. Либо вы попадете в медленно падающий и пылающий дирижабль с эмоциональными листочками на стенах, утренних Stand-ups для идиотов-социофобов, создающих лишь бы что — зато в срок! Рассчитайте высоту, найдите парашют и готовьтесь покинуть это бесовское место раньше начала фейерверка :-)

    P.S.: По-секрету, говорят есть способ все таки взлететь в любом случае — работать по строгому водопаду с ТЗ, unit-тестами, жесточайшей дисциплиной и человеческими жертвоприношениями Ктулху. Но это если повезет. А иначе вы попадете в суровую атмосферу Первой мировой и будете заниматься матстатистикой — прогнозом и подсчетом потерь личного состава от лягания лошадей и вести активную борьбу с каннибализмом. Удачи!
    1С-Битрикс 76,70
    Компания
    Поделиться публикацией
    Комментарии 120
    • +7
      Статья какая то сумбурная и не логичная, возможно это стеб или ирония,
      но выводы в разделе «Выводы» верны.
      • –1

        И чем именно верны эти сумбурные выводы? Лично я наблюдал массу эпичных факапов у любителей квадратно-гнездовых водопадов и "человеческих жертвоприношений".

        • +5
          • Не забивайте себе голову методологиями разработки программного обеспечения — это не поможет
          • Сосредоточьтесь в первую очередь на поиске и наеме профессиональных, настоящих программистов и вспомогательного персонала (аналитики, тестировщики, менеджеры всех мастей)
          • Если удалось подобрать адекватную команду — пусть она сама выберет методологию разработки и знайте, что с любой методологией проект скорее всего взлетит
          • Если не удалось подобрать адекватную команду — лучше меняйте работу

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

          • +1

            Да эти выводы действительно верны. Простите, был слегка сбит с толку остальной статьей.

            • +3

              Мне кажется у автора мысль движется в ту сторону, что и у всяких беков и фаулеров, когда говорят про agile maturity или engineering fluency, только он говорит в самобытно-эмоциональном стиле, что забавно в сочетании с понятиями "эмоциональный бред" и "эмоциональные листочки на стенках", которые он сам и применяет :)

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

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

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

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

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

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

                                  И это правда.
                                  — Скажи им попробовать новые идеи, они скажут, что нет опыта.

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

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

                                  Так и это не исключено.
                                  — Посоветуй им открыть магазин, они скажут, что нет никакой свободы.

                                  Странный ответ, вымышленный. Скорее скажут, что нет денег на открытие.
                                  — Скажи им заняться бизнесом, они ответят, что нет знаний.

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

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

                  Опять битрикс толкает речь про красоту программного кода. Сколько ещё это терпеть?

                  • 0
                    А что делать? Нравится красивый код, снится и сводит с ума.
                    • 0

                      Поэтому на старый некрасивый код можно и забить.

                      • 0
                        Да его рефакторят на D7 с OOP, просто его много очень.
                        • +5
                          Этому отрефакторенному D7 коду уже тоже рефакторинг давно нужен )
                          • +1

                            Я видел D7.


                            Если взять статические методы классов и запихнуть их в статические методы классов, но с неймспейсами — это не совсем рефакторинг )

                            • 0
                              Не, ну там не все уныло так :-) Появились объекты, настоящие, с конструкторами! Используются исключения, константы, все по взрослому. Постепенно стандартные компоненты переведут на объектную модель тоже.
                              • +1
                                Постепенно стандартные компоненты переведут

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


                                Появились объекты, настоящие, с конструкторами!

                                А иногда 2 или 3 объекта! И документации нет, какой использоваться непонятно по причине отсутствия документации и меток deprecated. А иногда ещё бывает так, что половина модуля переписана, а вторую половину методов нужно использовать из старых.

                                • 0
                                  по поводу @deprecated пометил, спасибо, согласен, это важно
                                  • 0
                                    Но вообще если метод публичный, общее правило — можно использовать. Если он исчезнет внезапно — пишите либо в саппорт либо мне в личку, будем разбираться
                                    • +1

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


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

                                • 0
                                  Коллекции в магазине тоже — пример здоровой инкапсуляции имхо.
                        • +1
                          Перестал читать на «Но чтобы писать на «настоящих» промышленных ЯП, таких как C++, Java или C#»
                          • +3
                            Зря, дальше интереснее :-)
                            • +2

                              Но с простотой Вы перегнули, имхо.
                              В Erlang и ассемблере классов нет, и они что простыми сразу стали?
                              Оттого что в языке нет встроенной статической типизации — он не становится сильно проще.

                              • 0
                                Да, вы правы, конечно. Перегнул немного для атмосферности.
                              • +1

                                Самокритично =)

                            • –2
                              Пришел умный дядя, и рассказал как правильно код писать, и что мне Agile не нужен.
                              Спасибо.
                              Я выбираю Agile.
                              • 0
                                Извини, но ты не понял смысл статьи :-)
                              • +3
                                Да, кадры решают. :)
                                • +2
                                  «До сих пор не знаете самый любимый фильм у программистов? „Вот же он“ (ссылка на фильм) — обязательно устраивайте еженедельный просмотр, кино отлично мотивирует, особенно перед встречами с клиентом!» — С коллегами посмеялись!))
                                  • 0
                                    Ну классный же фильм, у парня собачку прибили, а у разработчика клиент неадекватный и баги в коде и — и вперед :-)
                                  • +2
                                    У меня от повсеместных тире пошла кровь из глаз.
                                    • 0

                                      Да, "сумбурная" пунктуация местами весьма напрягает.

                                    • +2

                                      Кто эта девушка — первый product owner — которую довели до нервного тика? Где можно про это прочитать? Просветите, пожалуйста.

                                      • +3
                                        Marie Dearment
                                        https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System#endnote_customerRepBurnout
                                        http://www.coldewey.com/publikationen/conferences/oopsla2001/agileWorkshop/hendrickson.html
                                    • +3

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

                                    • 0
                                      Закон дырявой абстракции — http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html
                                      • 0
                                        https://ru.m.wikipedia.org/wiki/Уровень_абстракции_(программирование)
                                        • 0
                                          Ну смотри, ООП пытается защитить нас, снижая сложность — это инструмент снижения сложности ПО. Но если его применить неправильно, станет сложнее :-)
                                      • –2

                                        Как всегда о засилье дураков. Старо как мир. Но справедливости ради, разве не недоучки — люди с незаконченным высшим, придумали т.н. паттерны ооп? От которых число дураков выросло даже експоненциально в нашей отрасли. И еще, как можно ставить в пример java, когда, пожалуй, ни одно упрощение яп до уровня недоучек не привело столь много дилетантов в ит? :)

                                        • –2
                                          Ну в java попытались как-то стабилизировать адскую свободу в C++ — не согласен, что не получилось. А вот в всяких python что понатворили…
                                          • +1

                                            Думаю у Питона достаточно строгий дизайн или что вы имеете ввиду вообще?

                                            • 0
                                              Думаю он излишне аскетичен на гране примитивизма. Где нормальная инкапсуляция с человеческими protected/private? Нет ее и наверно не будет
                                              • +2

                                                Так это не "понятнворили" а "недонатворили". Это раз. Во-вторых, там есть инкапусуляция, в-третьих, это динамический язык со своими динамическими традициями (сравнивать с JS, ruby, lisp)

                                            • 0
                                              Вот яркий пример использования языка не по назначению: http://www.opennet.ru/opennews/art.shtml?num=45984

                                              Понятно, тут можно спорить. Но по моему мнению — Scala должна занять эту нишу.
                                              • +1

                                                Ее принципиально нельзя использовать не по назначению :)?

                                        • +1
                                          Но справедливости ради, разве не недоучки — люди с незаконченным высшим, придумали т.н. паттерны ооп?

                                          Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year.[6][7] In the following years, Beck, Cunningham and others followed up on this work.


                                          Beck attended the University of Oregon between 1979 and 1987, receiving B.S. and M.S. degrees in computer and information science.[3]


                                          Cunningham was born in Michigan City, Indiana.[6] He received his Bachelor's degree in interdisciplinary engineering (electrical engineering and computer science) and his master's degree in computer science from Purdue University, graduating in 1978.[7]


                                          От которых число дураков выросло даже експоненциально в нашей отрасли.

                                          Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)

                                          • +1
                                            Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)


                                            На самом деле, есть два вида дураков. Первые начитываются книжек по паттернам и начинают пихать их куда ни попадя. А вторые ничего не читают и просто говнокодят. И если у первых болезнь довольно быстро проходит на реальных проектах, то у вторых вообще не лечится.
                                            • +2
                                              Первые начитываются книжек по паттернам и начинают пихать их куда ни попадя

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

                                              • +2
                                                Ну я не скрываю, что сам не так давно был дураком 1-го типа.
                                              • +1
                                                Туда же дрочерство на ООП и фреймворки.
                                                Только я сомневаюсь, что болезнь лечится :) Больные считают себя здоровыми.
                                                • 0
                                                  Ну если не увлекаться, ООП же помогает. Не?
                                                  • 0
                                                    Лечится освоением другой парадигмы.
                                            • +2
                                              Запомните, что самое важное в программном проекте, который пишут настоящие программисты — это красота и стройность программного кода! Именно он привлекает к себе людей, мотивирует их вкладывать на свое развитие время и энергию.

                                              Самое главное в программном проекте это его функциональность, удобство использования для конечного потребителя. Но никак не стройность программного кода. Больше скажу всем, кроме программистов, наплевать как он там построен внутри, на чем написал, протестирован ли. Если же он непонятный, или неудобный в использовании, или просто несет никому ненужный функционал, как бы красиво он написан не был, он отправится в мусорную корзину, и никто ничего в него вкладывать не будет.
                                              • –1
                                                :-) шутите. Ориентироваться на потребительского дебила — не интересно, поверьте. Если бы так писали серьезные продукты, типа mysql или linux — до чего бы докатились, страшно подумать
                                                • +3
                                                  Ну вам лично может и не интересно, но есть куча проектов не для айтишников, а для «потребительского дебила»: фейсбуки там всякие, винды… хотя это же несерьезные продукты, ими ведь пользуются всего лишь сотни миллионов людей, да и доход от них измеряется в жалких миллиардах.
                                                  • 0
                                                    Почему, facebook интересный продукт, дал много опенсорсу, там нормальный код внутри, уверен! Винда — тоже классный продукт, разве нет?
                                                    • +1
                                                      Это я к тому, что винда и фейсбук, будучи казуальными продуктами, ориентированы на широкую аудиторию — «потребительского дебила». А если бы это было не так, они бы либо вообще не взлетели, либо их доли в потребительском сегменте болтались в районе статистической погрешности, как у линукса (и по той же причине).
                                                      Насчет кода винды: не видел, но подозреваю там жуткий говнокод.
                                                    • +1
                                                      Суть в том, что говнокод ооочень сложно и дорого развивать. И если продукт развивается и довольно долго — там сильная техническая команда и разумный код.
                                                      • +1
                                                        Суть в том, что говнокод ооочень сложно и дорого развивать


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

                                                    Обратите внимание на этот кусок. И имеются в виду программисты. Плохо себе представляю программиста которого может мотивировать на развитие говнокод.
                                                    • 0
                                                      Согласен абсолютно! Тот, кто останется копаться в д… ме — скорее всего имеет проблемы с самооценкой и что они напишут дальше…
                                                      • –1
                                                        По мне так в битриксе лютый говнокод, но это не мешает быть ему успешным продуктом, и привлекать кучу программистов. И успешный проектов на нем реализована куча.
                                                        • 0
                                                          Не согласен. В Битриксе стройная довольно лаконичная архитектура и разумный, читаемый код. Есть малюсенькие фрейворки, в которых логика более отточена — но просто они… маленькие.
                                                      • +1
                                                        Обратил, работать над продуктом который пользуется популярностью намного приятнее чем над «мертвым» продуктом. Это мотивирует, когда ты реализовал какую то фичу и люди начинают этим пользоваться. А если ты написал мега красивый по коду модуль и никто этим не пользуется, нафиг оно надо?
                                                        Насчет говнокода, мне например нравиться рефакторить старые проекты, делать код читабельные, удобнее в использовании. Но это имеет смывсл только тогда когда продукт пользуется спросом.
                                                        • 0
                                                          А как можно рефакторить говнокод без 100 тестировников и юнит-тестов? Согласен, что если продукт популярный — с ним интереснее работать, конечно.
                                                          • +1
                                                            кто вам мешает писать тесты на свой код?
                                                            • 0
                                                              Тесты не дают писать менеджеры проектов, т.к. сроки постоянно горят :-)
                                                              • +1
                                                                Я просто оставлю это здесь
                                                                Developers do not need to ask for permission for doing tdd or programming in pairs. Professionalism never requires consent. @lemiorhan

                                                                Asking permission to do TDD is like asking permission to use a keyboard. @JamesSaliba

                                                                Ну вы меня поняли…
                                                                • 0
                                                                  И много вы видели проектов с хорошим покрытием юнит-тестами? Не проще ли модульно программировать с качественной инкапсуляцией и писать интеграционные и смок-тесты? :-)
                                                                  • +1
                                                                    Юношеский максимализм.
                                                                    Конечно, дома вы можете делать TDD в свое удовольствие.
                                                                    А когда вам платят за работу, вы будете делать то, за что вам платят, увы.
                                                                    Это жизнь.
                                                                    Можно развести холивара много, про отличного специалиста нарасхват, но я видел не одного человека, который увольнялся с такими мыслями, а потом просился обратно.
                                                                    И в большинстве случаев, его место уже было занято.
                                                                    Тут недавно говорилось, что на начальном этапе TDD всего лишь удваивает время написания продукта.
                                                                    Какая ерунда.
                                                                    Ввалить еще миллион-другой в разработку.
                                                                    Нужно смело сказать об этом тому, кто за это платит.
                                                                    • 0
                                                                      Согласен, TDD слишком дорого и не дает гарантии. Гораздо спокойнее писать модульно, с инкапсуляцией, с головой, аккуратно и иметь набор функциональных тестов.
                                                        • +1
                                                          если код будет неясным и некрасивым, то рано или поздно он превратится в кучу мусора, поддерживать его станет невозможно, как и добавлять новые функции — в итоге этот «многофункциональный код» будет на свалке
                                                          • 0
                                                            Это технические детали на которые конечному потребителю плевать. Им плевать сложно вам добавлять функционал или нет, тратите вы на это 10 минут или 10 дней. Им важен результат. Вот вы пользуетесь Windows, Linux, mysql, mssql и т.д., и вы лазили у них в исходный код и это для вас стало решающим использовать их или нет? Сомневаюсь.
                                                            • 0
                                                              конечному потребителю может и наплевать, а вот конкурентам, которые могут быстрее и проще добавлять новый качественный функционал — нет;)
                                                              • 0
                                                                Сколько фейсбуков появилось одновременно с текущим и сколько появилось после? Самое важное тут не качество кода, а время. Кто первый, то и съест основную часть пирога. А когда ты на коне можно озадачиться рефакторингом с целью уменьшения времени на внедрении нового функционала.
                                                                • 0
                                                                  Я понимаю вас. Мы говорим, думаю, об одном — писать разумно, без фанатизма и чтобы можно было взлететь и потом расширять. Так могут писать только профессионалы.
                                                                  • 0
                                                                    Я просто говорю что красивый код никак не влияет но то взлетит проект или нет.
                                                                    • 0
                                                                      Он повышает шансы устойчивости к нагрузке и быстрой адаптации к требованиям клиентов, которые нужно будет, часто, быстро удовлетворить как раз во время запуска за короткое время.
                                                                      • 0
                                                                        Ну уж на нагрузку он никак не влияет, даже наоборот. Даже наоборот в красивом коде больше абстракций, которые создают дополнительную нагрузки при исполнении кода. Ну а клиентов на начальном периоде у вас вряд ли будет много. Если только вы не уже не супер известная компания, но это совсем другой случай :)
                                                                        • 0
                                                                          Абстракции позволяют провести быстрый аудит производительности и пофиксить тормоза в нужных точках, а не бегать по копипасченному спагетти, вырывая с кровью куски и ломая все остальное :-)
                                                                          • 0
                                                                            я все понимаю, но опять же, если у вас эта нагрузка есть. Я работал в проекте в основе которого лежала оч неплохая идея, достаточно интересная, подобного в России не было. Но за время работы сменилось 3 тимлида, и каждый говорил что написано все очень плохо. В итоге мы переписывали 3 раза с нуля, ушло много времени и денег. За это время появилось оч много проектов с таким же функционалом, и наш затерялся в этой куче, 5-10к посетителей, половина с рекламы. Код в итоге получился более-менее, но кому он теперь нужен. Проект в который вбухали миллионы, теперь на свалке, не отбив даже половины.
                                                                            • 0
                                                                              Услышал, согласен
                                                                              • 0
                                                                                Ни один хороший тимлид не даст переписывать все с нуля — это никогда не работает. Так что скорее всего да, было написано все очень плохо.
                                                                • 0
                                                                  Им плевать сложно вам добавлять функционал или нет, тратите вы на это 10 минут или 10 дней.

                                                                  То есть им в любой точке времени T плевать, есть функционал или нет?

                                                                  • 0
                                                                    Возьмем для примера что то типа фейсбука, У него допустим нет возможности выкладывать видео, а на сайте бабушкины-тапочки.ком есть. Но никто не будет уходить с фейсбука и-за этого, все будут ждать функционал. Потому что на фейсбуке у тебя 500 друзей, а на тапочках ни одного, с кем тебе там делиться видео, если там никого нет?
                                                                    • 0

                                                                      Зачит ли это что им плевать, есть функционал или нет?

                                                                  • 0
                                                                    Потребителю плевать, а менеджеру проекта не должно быть побоку это.
                                                                    • 0
                                                                      Многие проекты начинаются командой из 1-4 человек, а менеджеры появляются когда проект уже чего то добился. Конечно крупные компании не будут писать говнокод, и будут у них менеджеры, аналитики и т.д. но это не спасает от того что проект полностью провалится, взять хотя бы гугл+, есть у меня подозрения что написан он добротно, но кому теперь это надо?
                                                                      • 0
                                                                        Согласен в принципе. Но мне попадались проекты в крупных компаниях, которые внутри выглядели ужасно просто — парадокс :-)
                                                                        • 0
                                                                          Архитектура вообще дело сложное. Особенно когда проект начинается без видения каким он в итоге должен стать, тут ничего не поможет. Перерабатывая потом его, намного легче создать более удобную архитектуру, потому что вы уже знаете каким он должен быть и какие задачи решать. Но опять же не факт что это у вас получится.
                                                                          • 0
                                                                            Согласитесь, опытный разработчик обладает предчувствием развития архитектуры и требований — он правильно пишет классы, называет методы, создает разумные таблицы. Неопытный такое закостенелое чудовище может создать, что его полгода распутывать придется.
                                                                            • +1
                                                                              На то он и опытный, потому что он уже писал такой закостенелый код и спотыкался на этом и теперь знает как сделать лучше сразу :)
                                                                              • +1
                                                                                Не всегда к сожалению.
                                                                                У меня сложилось мнение, что некоторым этого не дано.
                                                                                Я тут приходил в компанию, в гости, из которой ушел несколько лет назад.
                                                                                Те же люди, когда с них сняли контроль за архитектурой, стали говнокодить и лепить костылики, лишь бы быстрее.
                                                                                Я расстроился.
                                                                                Спрашивал, как же так, ребята (хотя уже не ребята, взрослые люди).
                                                                                Да как то так, говорят. Закрывали вот, потребности.
                                                              • +3
                                                                В статье натужно нашучено и плотно насыпано ссылками.
                                                                • +1
                                                                  Можно было сказать проще.
                                                                  Индустрия программирование еще не достигла уровня индустриальной промышленности.
                                                                  А болтается где-то на уровне мануфактуры/кустарного производства.
                                                                  :-)
                                                                  • 0
                                                                    Прекрасно :-)
                                                                    • +1
                                                                      Индустрия программирование еще не достигла уровня индустриальной промышленности.


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

                                                                          Уж очень похоже на какое-то очень эмоциональное раздутое ИМХО, не имеющее никого подкрепления, кроме личного опыта, видимо, часто неудачного. Какие-то крайности: важен только совершенный код, важны только люди, а вот остальное нет. Все важно, и люди, и качество кода, и процессы и еще куча всего. К сожалению, не увидел у автора понимания, что такое тот же Agile

                                                                          • 0
                                                                            Agile — это вода и понты. Опыт и еще раз опыт :-)
                                                                            • 0
                                                                              и не увидите. воду в текст — на хабр лей. сожрут.
                                                                              • 0
                                                                                Битрикс в своё время выходил с проектом Битрикс24, на который ставились готовые таскмэнеджеры, аджайлборды, и выглядело это всё убого. Вместо структурирования процесса и задач, создавался стог хаоса с соломинками-задачами, чек-листами и т.д. Но, Битрикс продал этот продукт многим своим партнёрам (франчайзи). Я тогда работал в компании, которая переходила на Битрикс, и ребята из Битрикса настойчиво продвигали идеологию методологий.

                                                                                Когда же фирмы купили эти решения и, как мы поняли, нифига не взлетело, Битрикс открестился от этой идеи, сказав, о чудо, правду: если ваши программеры и менеджеры — нубы, получающие от 15 до 40 т.р. в месяц, они засрут любую методологию. Наймите квалифицированный персонал. А если нет денег, смиритесь с постоянными поражениями команды.

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

                                                                              Самое читаемое