Удивительно, что ваш продукт еще работает

    Я сейчас открою вам секрет полишинеля. Готовы?

    image

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

    Так ли это, почему и что делать.

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

    Сначала для технарей. Ответьте сами себе: вы следуете принципам clean code, SOLID, DRY и всему тому, что пишут в статьях и конечно у вас нет магических значений в коде. У вас действительно 100% покрытие тестами, у вас есть честный автоматический CI/CD, ваш REST использует все необходимые HTTP коды, а не только 200, 201 и 404. У прекрасно описаны все эндпоинты и минимальный технический долг, а legacy код тут же рефакторится? Если нет, то вы сами все поняли. И это я еще про мониторинг не говорил, да и про много чего.

    Теперь для менеджеров. Ребят, вы же не по водопаду работаете, да? Ну и скрам у вас честный, вы же не приравниваете стори-поинты к часам или ко дням и делаете планнинг-покер, обсуждая получившийся результат, да? И обязательно никаких блокирующих задач в спринте и defenition of done у вас есть и после реализации задача сразу попадает в продакшн. У вас есть roadmap продукта, документация, а задачи, передаваемые разработчикам содержат больше трех слов и описывают почему мы это делаем, что мы делаем, как протестировать и что в итоге получится. И описаны все бизнес-кейсы… И это только пару вещей, которые надо делать, мы же с вами знаем.

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

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

    Происходит это потому, что менеджеры чаще всего ни черта не понимают в разработке. Они понимают в ROI и KPI, они MBA получали, а если у них и есть какой-то бекграунд типа полу-профильного образования, то они дальше чем условный Hello World не заходили. И вообще, у них сроки горят, а правильно декомпозировать задачу до MVP, без технических знаний, достаточно сложно. Сюда добавляется нелюбовь программистов к менеджерам, помогать они им явно не будут. Вот и остается менеджерам писать повести или романы к историям и придумывать косвенные метрики, чтобы понять, качественно ли была выполнена та или иная задачи. Да только все эти метрики синтетические, никакого отношения к качеству разработки они не имеют, или очень опосредованно.

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

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

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

    Теперь почему всех это устраивает. Да-да, это устраивает абсолютно всех. Тех кого это не устраивает, либо не работают над этими продуктами, либо рефакторят их и приводят в нормальный вид.

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

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

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

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

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

    Как вы оцениваете качество разработки вашего продукта?

    • 5,6%Он идеальный, мы следуем лучшим практикам и используем все самое лучшее16
    • 28,3%Хороший код, нормальные процессы, но есть куда стремиться80
    • 49,1%Не идеально, но было и похуже139
    • 26,2%Все плохо: легаси, устаревшие технологии, антипаттерны.74

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

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      +7
      Удивляют приверженцы подхода «А так и должно быть». Деньги же приносит, а код вылизывать — это не фичи в продакшн запускать, конкуренты обгонят. Особенно это от программистов слышать как-то… ты должен был победить зло, а не примкнуть к нему! :D
        +14
        Средний срок жизни кода становится всё меньше и меньше.
        И если весь код вылизывать сейчас — то вылижут окончательно его к тому моменту, когда этот код будет уже не нужен.
        Есть, конечно, фундаментальные проекты (вроде nginx-а), которым текущая тенденция нипочём, но большая часть бизнес-кода живёт так.

        (и я не разработчик, я вообще динозавр-админ — просто смотрю, как часто проекты схлопываются или переписываются целиком по каким-либо причинам).
          +2
          Они переписываются как раз потому, что дальше уже невозможно развивать из-за технического долга и плохого кода. Слишком дорогими становятся новые фичи.
            +13
            Нет, оно переписывается, потому что концепция сменилась, нагрузка сменилась, требования от менеджеров сменились настолько, что нужно писать по новой, масштаб сменился, проект передали/продали другой компании с другим стеком и так далее.

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

              Соглашусь с предыдущим человеком. Видел пару небольших проектов, которые "ну полный пи… ц" и реально проще было бы переписать уже, но нет, всё равно равно дорабатывали.
              Переписывают, всё таки когда уже идейно/морально всё устарело.
              Или N лет создавалось на одной технологии, а сейчас проще написать с нуля используя новый стек технологии.

                0
                Часто переписывают от того что менялась команда разработчиков. Новые (а на найме в существующий проект всегда экономят) хотят работать только с использованием «модных» технологий, или не хватает компетенции быстро продолжить вести существующий проект на текущем уровне.
                Вот и получается что срок кода около 5 лет (2 смены команды).
                  +1

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


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

                    +1
                    Ох уж эта вера в «грамотную изначальную архитектуру». А особенно слепая вера в её необходимость и вечность. Вот только о том что при планировании системы надо предусмотреть условия и порядок её вывода из эксплуатации апологеты «грамотной архитектуры» забывают «чуть чаще чем всегда».
                      0
                      Вот только о том что при планировании системы надо предусмотреть условия и порядок её вывода из эксплуатации апологеты

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

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

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

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

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

                              Скорее не устарел, а стал унаследованным, эффективное его развитие невозможно

                    +12

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


                    хуже того: идеально вылизанного кода в принципе не существует как понятия. То, что считалось верхом вылизывания и оптимизации четверть века назад сейчас воспринимается как трудноподдерживаемый набор грязных хаков, и наоборот хороший годный современный код с позиции тех времён может восприниматься как overengeniered. Что будет ещё через четверть века вам никто сейчас не скажет

                      +2
                      Не готов согласиться с Вами на сто процентов. У меня была возможность сравнить два проекта стартовавших в начале двухтысячных. Оба продукта в одной отрасли, оба B2B. В одном была лапша и набор самых плохих методик, в другом возможно не идеальный, но относительно чистый код.

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

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

                          0
                          Давайте по пунктам.

                          1. Я Вам привел один из свежих примеров в моей практике, нигде в моем комментарии не было сказано, что это единственное, что я видел в своей профессиональной жизни.

                          2. Факторов много, но это не повод делать плохо. Это то, что я также хочу донести.

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

                        А что касается старого кода, на то есть код-ревью и рефакторинг, когда с течением времени необходимо изменять проблемные участки на актуальные решения.
                          +1
                          С моей точки зрения — это верный подход.
                      +3
                      А потом приверженцы такого подхода задаются вопросом — «А почему фичи внедряются по пол года?»
                      Дак, у вас долга в проекте уже больше чем кода.
                        0
                        С другой стороны, если использовать все методики и паттерны, типа SOLID, AGILE, SCRUM и тд и тп, то время разработки быстро стремится к бесконечности. Еще не факториал, но экспонента то уж точно.
                          –1
                          Вы считаете, что правильно — это всегда долго?
                            +5
                            А нет такой вещи, как правильно. Есть большой набор инструментов и методик. И много энтузиастов, которые стараются использовать максимальное их число.
                            Я считаю, что нужно для себя выработать разумное подмножество того, что использовать. Тогда возможно есть шанс.
                              –2
                              Если не секрет, какие методики используете Вы и команда, чтобы удерживать технический долг в пределах разумного?
                          +1
                          почему код нужно писать так как ты сказал? То что для одного best practice для другого чушь говяжья.
                          Например, смешивать в REST уровень HTTP (в данном случае транспортный) и прикладной (логику приложения) я считаю неправильным.
                            –5
                            Вы API только для внутренних потребителей разрабатываете? Если нет, то не вызывал ли Ваш подход сложностей у партнеров?
                              +3

                              А тут особо не важно. Просто объявляем партнёрам, REST HTTP (крайне редкий зверь) у нас или REST over HTTP.

                                +2
                                гораздо проще когда сервис выдает 404 только если вы промахнулись с URL а не когда он не нашел в базе сущность с нужными полями
                                  0
                                  А habr.com/ru/post/49515666 должен выдавать 404? А ведь тут просто не нашли в базе сущность с нужными полями… при использовании АПИ отсутствие сущности гораздо более вероятная ситуация, чем «опечатка» в URI
                                  А вообще для того, о чем вы говорите, придумали JSON RPC
                                    +1

                                    А это не ендпоинт API. Тут 404 вполне уместна.


                                    JSON RPC — лишь один из вариантов API c HTTP в качестве транспорта. Причём его сложно назвать REST

                                      0
                                      Я и не говорю, что JSON RPC это REST. Прям совсем не Representational State Transfer, а очень даже Remote Procedure Call. Просто в REST принято общение через методы и статусы HTTP. Вероятно для ошибки в URI можно использовать 400, а для отсутствующего «состояния» — 404. Или как ВАМ больше нравится. В этом плане REST прям совсем гибкий и не стандартизированный. И в этом его плюс и минус. JSON RPC пожестче. А хотите совсем жесткого регламента — используйте WSDL + SOAP
                                        +2

                                        Принято в REST HTTP (редкий зверь) и вариациях на его тему (очень часто), но в REST (или что угодно, JSON RPC, GraphQL, SOAP и т. п.) over HTTP это вовсе не обязательно.


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

                              0
                              Не стоит напрягаться, так и должно быть.
                              Уже проходили в других областях. С самолетами, автомобилями, сотовыми телефонами, смартфонами…
                              Каждый бизнесмен пытается влезть на новый и растущий рынок, не обладая достаточными знаниями. Область новая, квалифицированных технарей еще нету в нужном количестве, а квалифицированных менеджеров управленцев всегда дефицит был. Вот и нанимают кого смогут, пока ресурсы позволяют.

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

                                Что же касается самолетостроения, то недавно был показательный случаи с Боингами, если Вы помните. Он отлично вписывается в то, о чем я пытаюсь сказать. Лично я не могу себе позволить делать такие продукты.
                                  0
                                  Потребителю качество становится важно со временем. Но не на старте технологии, когда требования еще не сформированы. Компании, которые это не предусмотрели изначально, сталкиваются с трудностями вплоть до полной замены своего продукта.

                                  У самолетов, автомобилей уже закат подкрадывается. Там развиваться некуда. Рынок стабилен, а производители не способны работать в таких условиях. А Боингу не хватило денег на рефакторинг.
                                    +1
                                    И в случае, когда из-за качества кода, разработка под новые требования становится дорогой, страдает бизнес компании.

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

                                  Так в этом же и состоит искусство быть хорошим программистом и прекрасным менеджером: найти тонкую грань между "очень правильно, но никогда" и "хлоп-хлоп и в продакшн".


                                  Прочитать книжку по AGILE или любой другой аббревиатуре много ума не надо — это же нужно еще и в текущую реальность интегрировать.

                                    0

                                    Увы этого многие не понимают. Менеджеры не могут понять в силу незнания что такое код и как его писать. Они только книжки про методики читать могут.
                                    Программистам же плевать на потребности бизнеса. Да и часто они не в курсах что там за потребности. А многие из них кодят просто по фану. И им дай волю они 5 лет будут одну сортировку писать доводя её до идеала.


                                    p.s. я сейчас свой проект небольшой пишу. На дикой смеси bash и php =) А что я админ мне можно=) В целом это прокатит что бы понять взлетит или нет идея с точки зрения бизнеса, то есть есть ли у людей потребности и можно ли монетизировать. Если взлетит то уже отдам нормальным разрабам где то на фрилансе ТЗ с логикой работы приложения с учетом ошибок и накопившихся за время работы кейсов. Если не взлетит, то какая разница что в утиль выкидывать.

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

                                        Это больше похоже на MVP, если планируется на реальных пользователях тестировать, а не инвесторам или фокус-группе показать.

                                    0

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

                                      0
                                      Конечно бывает, но это не повод не работать над качеством. Лучше понемного, но постоянно, чем много, но никогда.
                                        0

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

                                      +4
                                      Происходит это потому, что менеджеры чаще всего ни черта не понимают в разработке.

                                      Мне кажется, вы не правы. Происходит это все потому, что чаще всего, такой подход устраивать бизнес. То есть, бизнес устраивать то, что через 3-5 лет код нужно будет выкинуть. Потому что при разумном подходе у них будут деньги на "выкинуть".

                                        0
                                        Я считаю, что при разумном подходе, эти деньги «на выкинуть» можно использовать намного выгоднее.
                                          +2

                                          Это очень философский вопрос. Вам нужно быть на 100% уверенным в своем продукте, что бы строить такие долгосрочные перспективы. Это далеко не всегда возможно.

                                          0
                                          полностью согласен.
                                          0

                                          Спасибо Коля! Таких материалов побольше, их явно не хватает. Молодец!

                                          0

                                          А почему контроллер ларавеловский на кдпв?

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

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

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

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

                                              у меня например все были из разработчиков. Все. 25 лет разработки и 8 фирм
                                              Либо Вам чертовски повезло, либо я неудачник.
                                                0
                                                Код это биты и байты. Для клиента надо, чтобы продукт решал проблему. Как это сделано внутри для него неважно. Это имеет значение только с точки зрения экономики производства.
                                                Вы уделили этому внимание, потому, что знаете «внутренность» процесса разработки. В качестве управжнения возьмите другую область. Например, железо.

                                                Пример: мышки с usb приемником. Возражение на выбранную технологию: «Это плохое решение, приемники будут теряться. Надо использовать Bluetooth. Давайте переходить на Bluetooth».

                                                Техническое решение: переход на Bluetooth.
                                                Административное решение 1: продажа универсальных приемников
                                                Административное решени 2: бесплатная отправка клиентам утерянных приемников.

                                                Все мы знаем, что обе модели существуют сейчас и успешны.
                                              +6
                                              По моему опыту (почти 15 лет), если проект круто спроектирован, идеально написан и покрыт тестами, то он мертвый и никому не нужен. Как правило, это проекты написанные ради освоения бюджета, успешно сданные и положенные в стол. А живые проекты, которыми пользуются, они внутри далеко не идеальны (это мягко говоря), по крайней мере по моему опыту. Возможно, у кого-то есть другие примеры, буду рад почитать.
                                                0

                                                Пока ваш комментарий оказался самым близким к моему опыту. Я могу это объяснить лишь одним: деньгами. Когда уже получил бюджет, то на продукт уже пофигу. И тут уже все зависит от философских взглядов разработчиков. А вот если деньги будут появляться только по результатам работ, то первый же заработанный доллар в один миг стирает все декларации о стремлении к лучшим практикам. "Клиент готов платить за функционал, а не код". И практика показывает что большинство менеджеров выбирает поиграть в рулетку "а вот мне повезет и без ваших лишних затрат на так называемое качество".
                                                Но я бы не переживал, на самом деле. Ведь реально всех все устраивает. До поры до времени...

                                                  +1

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

                                                  0

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


                                                  Куда критичнее сливание в унитаз кучи человеко-часов из-за нечеткости требований, смены ТЗ в процессе работы/перед релизом. Отсутствие макетов до начала разработки.


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

                                                    0
                                                    Похоже на выводы по одному опыту. Продукты сделаны настолько качественно, насколько это требуется. Есть ведь разница между требованиями к Notepad и RTS системам самолета или ПО для медицинских систем. Так же есть стоимость исправления ошибки. Стоимость тестирования.
                                                    И компании есть разные. В некторых есть менеджеры которые отвечают за свою часть работы: за разработку и качество кода, за его безопасность, за тестирование, за поддержку, и за прибыль в конце-концов. И каждому точно не наплевать за его часть работы.
                                                      0
                                                      Это хорошо, что в Вашей профессиональной жизни Вам встречались только те, кому было не наплевать на результаты их работы. Считаю это показателем того, что Вам самому не наплевать и Вы уважаете себя и не собираетесь мириться с плохим качеством продукта и его программной базы.

                                                      На деле ситуация выглядит абсолютно по-другому: и в России, и в Германии, и в Америке. Говорю на основании собственного опыта и наблюдений.
                                                        0
                                                        Я все же попытаюсь переубедить. На мой взгляд отсутствие внутренней коммуникации воспринимается как «всем наплевать». Например, отказ продукт менеджера менять устаревшую технологию на новую без объяснения считается «накоплением технического долга». А на самом деле замена технологии сейчас стоит условно 1000 копеек, приносит 0 копеек (технологии никогда не продаются). При этом на 1000 копеек мы можем сделать фичу, которая принесет 5000, а убытки от старой технологии будут 2000. Мы в плюсе, заняли нишу, и есть еще средства на переписывание.
                                                        Какой продукт Вы сами считаете сделанным идеально или близким к идеалу?
                                                          0

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

                                                            0
                                                            Да, с ним можно жить. Но я не считаю обновление технологии в деньгах. Это трудно предсказуемо. Я пробовал это делать, как мне кажется, в более простом случае: влиянии наличия одного продукта в портфеле на продажи другого. В итоге отказался считать такой «наведенный» доход. Только прямые цифры.

                                                            Переход на новую технологию может наоборот принести убытки. Пример из головы, выбор Windows Workflow Foundation. В момент презентации технология казалась перспективной.

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

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

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

                                                      +2
                                                      Потому что бизнесу бывает даже достаточно прототипа, чтобы закрыть потребность. Вообще, проблема «хорошего кода» проистекает из попытки предвидеть требования в будущем. Если за аксиому взять, что никаких новых требований к продукту не будет — то любой работающий сейчас код хорош и нет смысла платить больше. А еще чем-то эта проблема сродни premature optimization — крайне сложно угадать узкие места, а оптимизировать все подряд — это зря тратить деньги.
                                                      Имхо, тут совокупная ситуация на рынке ПО смещается в сторону «плохого кода» потому что:
                                                      а) горизонт планирования российского бизнеса мизерный. Обычно 6-12 месяцев. Все, что не окупится за это время — скорее всего не окупится никогда. Поэтому и выгода в течение 3-5 лет от хорошего кода — чаще всего призрачна для бизнеса.
                                                      б) бизнес или конечные пользователи хотят больше фич прямо сейчас. И не согласны ждать завтра с хорошей архитектурой. И согласны даже мириться с некритичными багами.
                                                        0

                                                        Статья ни о чем, потому что по сути переливаем из пустого в порожнее. Типичный принцип Парето — 80% задач закрываются 20% усилий и 80% дохода получается 20% функционала. А дальше… А дальше нужно просто сделать так, чтобы ты был впереди конкурентов или их попросту не было — и можно пузырь надувать дальше.


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

                                                          +1

                                                          На практике часто если гипотеза подтверждается, то появляется ещё одна, которую надо срочно подтвердить. И даже уловки типа написать прототип/MVP вообще на другой платформе могут не помочь. Посадят всю команду учить новый язык/фреймворк/экосистему, которые ты выбрал потому что хотел гарантий, что на продакшен это 100% не пойдёт

                                                            +1
                                                            Пишите прототипы на Хаскеле.
                                                              0

                                                              Будут все учить Хаскель. Оно полезно, конечно, для многих, но цель "выкинуть прототип" достигнута не будет.

                                                                0

                                                                Делаю так (и пишу на нем в прод), полет нормальный.


                                                                Тогда уж на идрисе надо.

                                                            +1
                                                            Автор прав хотя-бы в том, что разработчики в своем стремлении сделать внутреннее устройство продукта надёжным, стабильно сопровождаемым и предсказуемым постоянно попадают в дурацкое положение. Уже не раз делались выводы, что серебряной пули не существует.

                                                            Удивляться тут нечему. На одну техническую проблему тонны языков программирования с сопутствующими фреймворками. Возможности комбинирования инструментов разработки друг с другом рождают новые профессии аля FullStack-developer конкретного стэка. С учетом того, что в IT всё новое предпочитают превращать в хайп(иначе не продвинешь), под влиянием моды довольно качественные инструменты вытесняются модными, не оставляя времени разработчикам на выработку эффективных методик работы с выбранным ранее инструментом. Разработчики со студенческой скамьи становятся похожими на Элочку Щукину, стремясь угнаться за последним словом моды которую формируют американские гиганты индустрии(Planned obsolescence in action). Проблема использования инструментов разработки не по назначению существует и она огромна.

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

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

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

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