Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.
Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль. Но в этой статье я хочу пойти ещё дальше и доказать, что постановка вопроса из заголовка этой статьи просто не имеет смысла. Такая постановка вопроса предполагает, что существует компромисс между затратами и качеством. И необходимо постоянно соблюдать баланс. В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Мы привыкли к тому что нужно выбирать между ценой и качеством
Как я писал ранее, при разработке ПО постоянно приходится делать выбор между качеством продукта и затратами на его разработку. Когда вы покупаете новый смартфон, у вас есть выбор. Заплатить больше денег и получить более быстрый процессор, больше памяти и улучшенный экран, или заплатить меньше, но пожертвовать некоторыми функциями. Из этого правила бывают исключения: иногда продукт более высокого качества стоит дешевле. А иногда люди даже не могут объективно сравнить два продукта и выбрать более качественный. Например, не замечают разницы между экранами, которые изготовлены по совершенно разным технологиям. Тем не менее, утверждение: «Высокое качество стоит дороже» – обычно справедливо.
Качество ПО это о многом
Говоря о качестве ПО, следует начать с определения критериев качества. Что такое качественное ПО? С этого момента всё несколько усложняется, ведь у любой компьютерной системы есть множество критериев, по которым можно оценивать её качество. Можно оценивать UI и UX: насколько быстро и просто пользователь может решить свою задачу? Можно оценивать надёжность: есть ли в программе баги, которые ведут к неправильному и нестабильному поведению? Ещё один критерий – это архитектура: насколько исходный код программы структурирован, насколько просто и быстро программист может найти нужный ему в данный момент участок кода?
Приведённый список критериев качества, конечно же, не полный. Но этих критериев достаточно, чтобы показать одну важную вещь. Некоторые критерии, по которым обычно оценивают качество программы, даже не видны для конечных пользователей. Заказчики могут дать обратную связь и сообщить, насколько хорошо ПО решает их бизнес-задачи. Пользователи могут пожаловаться на неудобный интерфейс. Или будут жаловаться на баги, особенно если они приводят к потере данных или к продолжительной недоступности системы. Но пользователи не в состоянии оценить архитектуру и качество кода.
Поэтому я разделяю критерии качества на две категории: внешние (например, UI/UX или наличие багов) и внутренние (архитектура). Самое важное их отличие в том, что пользователи могут оценить внешнее качество, но не могут понять, насколько хороша (или плоха) внутренняя архитектура системы.
На первый взгляд внутреннее качество не имеет значения для пользователей (но только на первый)
Если пользователи не могут оценить внутреннее качество ПО, является ли этот критерий важным? Давайте представим гипотетическую ситуацию, что две команды разработчиков, независимо друг от друга, решили создать приложение для отслеживания и прогнозирования задержек авиарейсов. Одной командой управляю я, а второй руководит Ребекка. Набор базовых функций у приложений примерно одинаковый, интерфейс у обоих приложений тоже получился достаточно удобный и продуманный, критических багов в приложениях нет. Единственное отличие заключается в том, что исходный код приложения от Ребекки чётко структурирован и организован, а код, созданный моей командой, представляет из себя беспорядочный набор классов и методов с непонятными именами и ещё более непонятной логикой того, как этот код связан между собой. Есть и ещё одно отличие: я продаю своё приложение за $6, а Ребекка продаёт почти такое же приложение за $10.
Поскольку пользователям недоступен исходный код приложений, а качество кода никак не влияет на пользовательский опыт, зачем пользователям платить лишние $4? Иными словами – зачем переплачивать за внутреннее качество, которое не имеет никакого значения для пользователей?
Если развивать эту идею ещё дальше, то можно прийти к мнению что вкладываться во внешнее качество выгоднее, чем во внутреннее. Делая выбор между двумя приложениями, пользователь может выбрать то, которое дороже, если у него более качественный и удобный интерфейс. Но пользователи не видят внутреннее устройство приложений, не говоря уже о том, чтобы пользователь мог сравнить архитектуру двух приложений. Так зачем платить больше за то, что не приносит практической пользы? И зачем разработчикам тратить время и ресурсы на повышение внутреннего качества своих программ?
Программы с высоким внутренним качеством проще расширять
Почему для программистов настолько важно чтобы код был качественный? Программисты проводят большую часть времени за его чтением и редактированием. Даже при разработке новой системы, работа почти всегда ведётся в контексте уже написанного кода. Когда программист добавляет новую фичу, сначала ему необходимо разобраться, как эта фича вписывается в существующую архитектуру приложения. Затем зачастую нужно внести изменения в архитектуру, чтобы новую фичу можно было реализовать. Часто нужно использовать структуры данных, которые уже есть в системе. Поэтому нужно понять, что эти структуры данных означают, какие между ними имеются связи и какие новые структуры данных нужно добавить для реализации фичи.
Высокое качество кода позволяет программистам быстро в нём ориентироваться. Добиться ситуации, когда код станет сложным для понимания, на самом деле очень просто. Логические условия могут переплетаться, связи между структурами данных могут быть сложными и неявными. Названия, которые Тони дал переменным и функциям 6 месяцев назад, возможно, были понятны ему, но также непонятны новому разработчику, как и мотивы побудившие Тони покинуть компанию. Разработчики обычно называют это «техническим долгом» (техдолгом), или иными словами, разницу между текущим состояние кода и идеальным состоянием, в котором он может быть.
Одним из основных преимуществ, которые даёт высокое качество кода является то, что программист может быстро понять, как работает система и внести нужные правки. Когда приложение разделено на модули, программисту не нужно изучать все 500,000 строк исходного кода и он может быстро найти нужные ему в данный момент несколько сотен строчек. Когда программисты дают понятные имена переменным, функциям и классам, можно легко понять, что делает каждый отдельный фрагмент кода без необходимости глубоко вникать в контекст. Если структуры данных в программе совпадают с терминологией из доменной области бизнеса, то программисту легко соотнести запрос на новый функционал с тем, как устроена система. Техдолг же увеличивает время, которое требуется для работы с кодом. Также возрастает вероятность ошибиться. В случае появления багов из-за плохого качества кода, потребуется дополнительное время на то, чтобы локализовать проблему и исправить её. А если баг не будет замечен сразу, то это приведёт к появлению проблем в production-коде и тому, что придётся потратить ещё больше времени на исправление этих проблем в будущем.
Каждое изменение в коде влияет на будущее продукта. Часто бывает ситуация, когда есть простой и быстрый способ реализовать новую фичу, но ценой нарушения текущей архитектуры (т.е. за счёт увеличения техдолга). Если программист выбирает этот путь, он выпускает свою фичу быстрее, но замедляет работу других разработчиков, которым придётся поддерживать этот код позднее. Если все в команде будут так поступать, то даже хорошо спроектированное приложение с хорошим кодом быстро обрастёт техдолгами, и даже для внесения небольшой правки потребуется несколько недель.
Пользователи хотят получать новые фичи как можно быстрее
Мы подходим к важному моменту, а именно: к ответу на вопрос, почему же для пользователей всё таки важно внутреннее качество ПО? Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать. Наши с Ребеккой приложения выглядят сейчас почти одинаковыми, но через несколько месяцев высокое качество кода Ребекки позволит ей выпускать каждую неделю по новой фиче, а я застряну на месте, стараясь справиться с техдолгом и пытаясь запустить хотя бы одну новую фичу. Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки, несмотря на то, что оно стоит дороже.
Визуализация влияния внутреннего качества
Главным преимуществом высокого внутреннего качества программы является уменьшение стоимости будущих изменений. Но на написание качественного кода требуется больше усилий, а это увеличивает необходимые ресурсы в краткосрочной перспективе.
На графике ниже схематично изображено, как можно представить соотношение функциональности и времени, которое требуется на его разработку. Обычно кривая выглядит примерно так:
Так выглядит процесс разработки, когда код не очень качественный. Сначала разработка идёт достаточно быстро, но затем на дальнейшее расширение функционала требуется всё больше и больше времени. В определённый момент времени, для того чтобы внести даже маленькое изменение, программисту нужно сначала изучить много сложного и запутанного кода. После того, как изменение внесено, обнаруживается, что что-то сломалось, и это ведёт к дополнительным затратам времени на тестирование и исправление ошибок.
Высокое внутреннее качество способствует повышению эффективности разработки на более поздних стадиях. Некоторым командам удаётся даже получить обратный эффект, когда каждая новая фича выпускается быстрее предыдущей за счёт того, что удаётся переиспользовать уже написанный код. Но такое происходит нечасто, потому что для этого требуется высокопрофессиональная команда с хорошей организацией работы. Но иногда такое всё-таки происходит.
Однако есть одна хитрость. На начальных стадиях разработки игнорирование качества кода оказывается более эффективно, чем следование высоким стандартам. Но когда же заканчивается этот период?
Чтобы ответить на этот вопрос, сначала нужно пояснить, что на изображениях представлены псевдографики. Не существует единственно верного способа для оценки производительности команды. Непросто понять, как плохой код влияет на конечное качество продукта (и если эта корреляция есть, то насколько она выражена). Кстати, эта проблема актуальна не только для ИТ-индустрии. Как, например, оценить качество работы юриста или доктора?
Но вернёмся к вопросу, в какой момент стоит начать задумываться о качестве кода. Опытные разработчики считают, что плохое качество кода начинает замедлять работу уже через несколько недель после начала проекта. На ранней стадии проекта на красоту архитектуры и кода можно не обращать внимания.
Также по собственному опыту могу сказать, что даже небольшие проекты получают серьёзное конкурентное преимущество, если используют в своей работе современные и эффективные практики разработки и задумываются о качестве кода.
Даже лучшие команды иногда пишут плохой код
Те, кто плохо знаком с процессом разработки, считают, что плохой код говорит о том, что команда плохо работает. Но, как показывает практика, даже самые опытные команды иногда допускают ошибки и пишут плохой код.
Чтобы наглядно это показать, хочу рассказать вам о беседе с одним из наших лучших тим-лидов. В тот момент он как раз закончил работать над проектом, который все считали очень успешным. Заказчик был в восторге от новой системы, причём, как от новых возможностей, так и от ресурсов, которые были потрачены на её разработку. Команда тоже была довольна выполненным проектом. Технический лидер команды тоже был весьма доволен результатом, но признался, что на самом деле архитектура системы получилась не такая уж удачная. Я спросил у него: «Но как же так, ты ведь один из наших лучших архитекторов?». Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Многие люди сравнивают создание сложных систем с проектированием небоскрёбов. Видимо, поэтому опытных разработчиков называют «архитекторами». Но в процессе создания ПО всегда есть некоторая неопределённость, нехарактерная для других областей деятельности, в которых неопределённости гораздо меньше. Типичные заказчики плохо понимают, чего они хотят от программы и начинают понимать это только в процессе работы над ней. Чаще всего, в тот момент, когда им показывают первые версии программы. Элементы, из которых создаются программы (языки программирования, библиотеки, платформы), меняются раз в несколько лет. Проводя аналогию со строительством небоскрёба, можете ли вы представить ситуацию, когда заказчик просит архитектора добавить ещё с десяток этажей и изменить планировку у нижних, при том, что половина здания уже построена? Ситуация усложняется ещё больше, когда выясняется что технологии, используемые для производства бетона, его физические свойства и характеристики обновляются каждые 2 года.
В условиях постоянных новых вызовов, роста их количества и сложности, командам постоянно приходится придумывать что-то новое. Всё чаще приходится решать задачи, которые раньше никто никогда не решал, и соответственно для них нет общеизвестного и проверенного решения. Обычно ясное понимание проблемы приходит только в момент её решения, поэтому я часто слышу мнение, что понимание того, как должна выглядеть архитектура сложной системы, приходит как минимум через год после начала работы. И даже самая профессиональная в мире команда разработчиков не сможет сделать систему идеально.
Профессиональная и организованная команда отличается от менее организованной тем, что в процессе работы над системой создаёт меньше технического долга, а также параллельно избавляется от существующего. Это помогает проекту быстро развиваться и выпускать новые фичи как можно оперативнее. Такая команда вкладывается в создание автоматизированных тестов, что помогает быстрее выявлять проблемы и тратить меньше времени на поиск и исправление багов. Участники такой команды постоянно работают над поддержанием высокого качества кода и быстро избавляются от плохого кода, пока он не начал мешать двигаться вперёд. CI-системы тоже способствуют этому, особенно в ситуации, когда множество людей параллельно работает над разными задачами. В качестве метафоры можно привести уборку на кухне после приготовления пищи. Невозможно что-то приготовить, не испачкав при этом стол, посуду и другие кухонные принадлежности. Если вы не почистите их сразу, то грязь засохнет и потом будет гораздо сложнее её отмыть. И когда в следующий раз вы захотите что-нибудь приготовить, вам будет намного сложнее это сделать потому что сначала придётся помыть гору посуды.
Исследование DevOps Research and Assessment (DORA)
Компромисс между стоимостью и качеством – не единственный в мире разработки ПО, который кажется простым на первый взгляд, но на практике всё оказывается несколько сложнее. Также широко обсуждается вопрос, что лучше выбрать – быстрые темпы разработки и релизов или более медленные темпы и тщательное тестирование. Считается, что использование второго подхода позволяет добиться более высокой стабильности продакшн-систем. Однако в исследовании DORA было доказано, что это не так.
Собрав статистику за несколько лет, исследователи выявили какие практики способствуют более высокой эффективности команд. Оказалось, что самые эффективные команды обновляют продакшн-сервера много раз в день, а выпуск кода от момента его написания до релиза занимает не более часа. Следование такому подходу позволяет выпускать изменения маленькими частями, и вероятность серьёзных поломок снижается. Команды, которые делают релизы реже, по статистике сталкиваются с большим количеством серьёзных проблем. Помимо этого команды, которые привыкли к высокому темпу, умеют быстрее восстанавливаться после сбоев. Также исследования показали, что в таких командах обычно лучше выстроены процессы и они действуют более организованно.
Поддержка систем с хорошей архитектурой стоит дешевле
Самые важные пункты из того, о чём мы говорили выше:
- Недостаточное внимание к качеству кода ведёт к накоплению технического долга
- Технический долг замедляет развитие системы
- Даже профессиональные команды иногда принимают плохие решения. Но применение современных практик и периодическое «погашением» технического долга позволяет держать его под контролем
- Поддержание высокой планки качества кода позволяет минимизировать техдолг. Это даёт возможность сосредоточиться на новых фичах и выпускать их меньшими усилиями, быстрее и дешевле
К сожалению, разработчикам обычно сложно объяснить это руководству. Я часто слышу жалобы, что руководство не даёт возможности поддерживать высокое качество кода, ограничивая время которое выделяется для работы над задачами. Отвечая на вопросы руководства, зачем тратить лишние ресурсы на красоту кода, разработчики обычно отвечают, что это является показателем высокого профессионализма. Но использование только этого аргумента подразумевает, что на поддержание высокого качества расходуются дополнительные ресурсы, которые можно было использовать на другие задачи. И это подрывает сам довод о профессионализме. Истина заключается в том, что из-за некачественной архитектуры и плохого кода, жизнь становится сложнее у всех: разработчикам сложнее с ним работать, а заказчикам он обходится дороже. При обсуждении качества кода с менеджментом, я призываю к тому чтобы рассматривать его исключительно как экономический показатель. Если программа внутри сделана качественно, то будет проще и дешевле добавлять в неё новые фичи. Это означает, что вложения в написание качественного кода, в конечном счёте, снижают общие затраты на разработку.
Это и есть истинная причина, почему вопрос из заголовка статьи просто не имеет смысла. Тратить лишние ресурсы на архитектуру и хороший код, с экономической точки зрения, в итоге, оказывается более выгодно. Компромисс между ценой и качеством, с которым мы часто сталкиваемся в обычной жизни, нельзя напрямую применить к внутреннему качеству ПО, но можно применить к внешнему качеству. Например, если речь идёт о пользовательском интерфейсе. Поскольку корреляция между стоимостью и внутренним качеством в данном случае нетипична и контринтуитивна зачастую её бывает трудно осознать (и тем более объяснить другим). Но тем менее важно это осознать, чтобы сделать процесс разработки максимально эффективным.
У Мартина Фаулера есть ещё одна статья про технический долг. Небольшой тизер:
Дополнительное время, которое тратится на добавление новых фич, можно сравнить с процентами по банковскому кредиту. Чистка технического долга – это как выплата процентов по кредиту. Эта метафора хорошо описывает суть. Но может создаться ложное ощущение, что техническим долгом можно достаточно просто управлять. Однако в реальности это намного сложнее.
Комментарии (89)
szelga
13.06.2019 13:22В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим
есть ещё мир бизнеса, в котором, если не выпустить в срок, то можно уже не выпускать (иногда на самом деле, иногда только в воспалённом воображении менеджеров). поэтому и приходится искать компромисс между качеством и сроками (или же компромисс между краткосрочным и долгосрочным).
valis
13.06.2019 15:29Про качество уже много написано и оно легко доказуемо.
А вот интересная тема «расширяемость» и «заделки на будущее»
Есть 2 провальных примера:
1. Аутсорсер, который нескольким клиентам делает очень похожие приложения. Но при этом у них есть набор не пересекающихся фитч и у каждого есть «видение» дальнейшего развития продукта (как оказывается дальше это просто фантазии)
У аутсорсера накопилось N лищних баксов и за эти деньги они посадили программистов напилить продукт, который бы удовлетворял требованиям всех клиентов + заделки на будущее
В итоге продукт никто не купил. Может быть продавать не умели, а может быть заказчик не хотел переплачивать за лишние фитчи и туманные перспективы (которые уже из коробки работали)
2. Был запрос от бизнеса — сделать сличение 2-х наборов данных (сейчас пользователи сличают руками, но устали — хотим автоматом)
И тут на пользователей набросилась толпа бизнес аналитиков, которые быстренько нафантазировали огромный и расширяемый продукт, с кучей плюшек и кнопкой «сделать все хорошо». Но сначала основные требования — сделать сверку двух наборов данных.
Разработчики увидев крупные перспективы проекта организовали не малую команду и начали пилить крутой расширяемый продукт с автотестами и блекджеком. В котором сначала будет один отчет, а потом надуманные бизнес аналитиками фитчи будут лепится одна за другой по одному щелчку мыши.
В итоге:
— Пользователь получил свой отчет через польтора года (1.5 года КАРЛ!!! 1.5 года один отчет!!!)
— Ситуация поменялась и пользователь захотел уже другое
— Измененная ситуация никак не ложилась в парадигму «того самого мега продукта» в минималистическом исправлении и требовала либо серьезной переделки продукта либо быстро сделать что-то в сторонке (терпение бизнеса на исходе — выбор очевиден)
Я все к чему: Не думайте что во главе бизнеса сидят дяди, которые видят дальше чем месяц в перед! Делайте качественно, но согласно текущих потребностей бизнеса!!!
bivo Автор
13.06.2019 15:55+1Тут нужно помнить, что Фаулер из мира enterprise. Из того мира, где системы в стадии разработки и поддержки могут существовать годами и десятилетиями, количество строк кода исчисляется сотнями тысяч и миллионами, а писали их сотни и тысячи разных людей.
Для стартапов статья применима меньше, но всё же актуальна.
Когда код хороший и техдолги постепенно вычищаются, разрабатывать быстрее, проще, да и просто фановее.
Багов меньше, фич больше,котикиPM'ы довольны :)
warranty_voider
14.06.2019 13:04На самом деле в стартапах она применима ничуть не меньше, а иногда и больше. Потому что часто меняющиеся и зачастую противоречивые требования порождают необходимость в гибкой архитектуре. Чтобы можно было выкинуть одну фичу и безболезненно прикрутить на ее место другую. А потом вернуть первую, но на два экрана дальше. Энтерпрайз может планировать продукты годами и выпускать стабильные требования, по которым потом все работают и которые уже предусматривают возможность расширения функциональности в ту или иную сторону. Т.е. «мы делаем приложение расширяемым, потому что у нас есть требование, чтобы оно было расширяемым, и заказчик платит за это в явном виде». В стартапах это выглядит как «мы должны делать приложение расширяемым, хотя нас об этом и не просили, потому что в отсутствие четкого плана непредсказуемые изменения добьют нас через полгода и мы останемся без проекта и без денег вообще».
JediPhilosopher
15.06.2019 21:04порождают необходимость в гибкой архитектуре.
По моему опыту как раз с гибкой архитектурой — и с любой другой — в стартапах проблемы. Потому что сколько ни планируй, все равно окажется что в реальности людям нужно совершенно иное. И гибкость, придуманная еще до начала работ, оказывается нерабочей — гибко не там, где в итоге оказывается нужно.
TimsTims
13.06.2019 16:20+2> Единственное отличие заключается в том, что исходный код приложения от Ребекки чётко структурирован и организован, а код, созданный моей командой, представляет из себя беспорядочный набор классов и методов
Значит, вы гораздо раньше выйдите на рынок и начнёте продавать свое приложение, зарабатывать деньги и нанимать ещё программистов, в то время как у Ребекки сырая нерабочая альфа. Дополнительные руки позволят вам заново переписать приложение, при этом продолжая получать деньги за старое. А если вдруг окажется, что приложение никому не нужно — у вас будут мЕньшие потери по расходам, чем у Ребекки. Во всех раскладах — вы останетесь в выигрыше.
> Есть и ещё одно отличие: я продаю своё приложение за $6, а Ребекка продаёт почти такое же приложение за $10.
Никто не запрещает вам продавать ваше приложение по $10, загрести деньги лопатой, нанять +10 программистов на переписывание кода. И никто не запрещает Ребекке пытаться выжать вас с рынка, продавая в убыток для себя по $6. Ведь вы(блин, это же перевод) сами написали, что приложения внешне одинаковые, зачем продавать его дешевле?
Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку и используя её код переходите на него.
Если бюджет Ребекки больше, то захватив рынок вы продаете всю компанию и клиентскую базу — Ребекке, быстро поднимаете деньги, которые зарабатывали бы ещё несколько лет, и начинаете новый перспективный стартап.
Ну и все эти красивые графики не показывают одного важного пункта — когда будет готовое рабочее приложение. Например, у вас это 3 месяца, а у Ребекки 10 лет. Ребекка все равно в выигрыше?upviqq
14.06.2019 08:48Да, всё очень точно описано. К сожалению, писать глючное чёрти что выгоднее, так ещё и Ребекка посмотрит на вас и тоже перейдёт на тёмную сторону. И будет уже соревнование за менее глючное чёрти что.
А страдают пользователи. Сейчас сообщения об ошибках и сбоях воспринимаются как обычное дело, как будто я не законченный продукт купил, а записался в команду тестировщиков. Только почему-то плачу (с ударением сначала на вторую, а потом и на первую гласную) я.TimsTims
14.06.2019 11:26+1А вы готовы платить в 2-3 раза больше за чуть менее глючное ПО?
upviqq
14.06.2019 11:42А сейчас и выбора нет, слишком всё взаимосвязано. Что-нибудь, да заглючит, хоть в 10 раз дороже заплати. Косяк может быть в библиотеке, фреймворке, операционной системе, драйвере и ещё где-нибудь, и ещё в различных сочетаниях этих косяков.
Все потихоньку косячат и всё, уже недостаточно самому не лажать, тебе со всех сторон помогут.DrunkBear
14.06.2019 12:28Соглашусь.
Раньше было «ааа, у нас тут утечка памяти!!!»
А сейчас — ну да, там утечка памяти, это ж JVM. Настройте правильный GC и забудьте.
EvgeniiR
14.06.2019 11:57+1>А вы готовы платить в 2-3 раза больше за чуть менее глючное ПО?
Фаулер пишет о том что грамотное проектирование как раз таки окупается со временем.
Так с чего пользователю придется платить больше?)
DrPass
14.06.2019 12:18+2Не надо пугать всякими «2-3 раза», это миф. Менее глючное ПО отличается от более глючного не стоимостью разработки, не сроками разработки, а всего лишь культурой разработки. При нормальной организации даже наоборот, стоимость и сроки могут быть меньше, чем у корявых глючных монстров.
Magic_B
14.06.2019 12:23+1И правда, например, порой прежде чем кодить 2 часа, можно посидеть подумать 30 минут и написать работающий код за 30 минут. Вот вам и 2 раза быстрее и скорее всего качественнее.
bevalorous
14.06.2019 08:55Подогнали все условия, чтобы Ребекка проиграла, хотя ничего подобного в статье не было. И альфа у нее сырая, и приложение дороже, и расходы больше, и сроки она затянула, а бюджеты одинаковые. Конечно, Ребекка проиграет, о чем тут говорить вообще?
TimsTims
14.06.2019 11:27Прочитайте внимательно — я рассмотрел разные варианты. Когда бюджет у Ребекки больше, она спокойно вытягивает и выкупает конкурента.
bevalorous
14.06.2019 12:32Вам уже выше ответили — написание качественного кода и использование best practices не меняет качественно затраты. Конечно, при условии, что вы не пытаетесь внедрить их на проекте, где их невозможно внедрить. Если у вас огромный legacy-монстр, где компонент А зависит от Б, Б от В, В от Г, и все прибито гвоздями, а вы пытаетесь протестить компонент А юнит-тестом — тогда, согласен на 150%, вас ждет боль, много боли, и много затрат, и потеря огромного количества времени. Но причина этого в данном случае не в правильном подходе, который дорог, а в том, что вы не использовали его с самого начала и написали нетестируемое, негибкое, нерасширяемое нечто.
DarthVictor
14.06.2019 11:05+1Ну вот совсем не факт, большинство современных технологических лидеров не были первыми. Они были первыми нормальными.
готовое рабочее приложение.
Ну было оно у Yahoo раньше чем у Google, у MySpace раньше чем у Facebook, у Flick раньше чем у Instagram, а толку то?TimsTims
14.06.2019 11:31Толк в том, что они начали нормально так зарабатывать с этого деньги, и стали жить хорошо, и почти все они могли выкупить конкурента ещё в начале их развития.
Проблема в плохом руководстве и остановке развития проекта — она вообще никакого отношения к качеству кода не имеет.bevalorous
14.06.2019 12:34На место выкупленного конкурента всегда может прийти новый, у которого процесс разработки поставлен как надо, и уделает монополиста, потому что он будет быстрее внедрять фичи, выпускать релизы с меньшим количеством багов, легче находить разработчиков в команду и т.п… Такой сценарий тоже возможен, хотя, конечно, надо смотреть на конкретный рынок и конкретный продукт.
bevalorous
14.06.2019 12:38Если руководство ставит приоритетом скорость запила новых фич и насаждает культуру пренебрежения к качеству кода (это все теории, а на практике у нас все не так), то это подобно тому, как гонять таксомотор, перевыполняя норму по заказам, но не заботясь о ТО и амортизации. Рано или поздно (скорее рано) таксомотор загнется, и зарабатывать заказами станет не на чем. Метафора кредита в статье тоже очень хороша: не имеет значения, как быстро и как легком вы можете получить новый кредит, если необходимость выплаты прошлых кредитов уже сделала вас банкротом.
EvgeniiR
14.06.2019 12:12+1Значит, вы гораздо раньше выйдите на рынок и начнёте продавать свое приложение, зарабатывать деньги и нанимать ещё программистов, в то время как у Ребекки сырая нерабочая альфа. Дополнительные руки позволят вам заново переписать приложение, при этом продолжая получать деньги за старое. А если вдруг окажется, что приложение никому не нужно — у вас будут мЕньшие потери по расходам, чем у Ребекки. Во всех раскладах — вы останетесь в выигрыше.
Или у вас спустя несколько месяцев после выхода на рынок будет ужасная нерасширяемая поделка, в которой кнопочки в интерфейсе до сих пор ссылаются на #, а Ребекка как раз выйдет на рынок с удобным приложением и стабильнами поставками нового функционала без багов, и пользователи уйдут к ней.
Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку
Или, рано или поздно, разработка схожей по объёму фичи у вас начнёт занимать кратно больше времени и денег, а Ребекка продолжит стабильно выкатывать новые фичи укладываясь в бюджет
Раз уж мы под статьёй Фаулера, процитирую его же книжку, абзац написанный в контексте старой басни Эзопа про черепаху и зайца:
SpoilerСовременные разработчики также участвуют в похожей гонке и проявляют
похожую самонадеянность. О нет, они не спят, нет. Многие современные
разработчики работают как проклятые. Но часть их мозга действительно
спит — та часть, которая знает, что хороший, чистый, хорошо проработанный
код играет немаловажную роль.
Эти разработчики верят в известную ложь: «Мы сможем навести порядок потом, нам бы только выйти на рынок!»
В результате порядок так и не наводится, потому что давление конкуренции на рынке никогда не
ослабевает. Выход на рынок означает, что теперь у вас на хвосте висят
конкуренты и вы должны стремиться оставаться впереди них и бежать
вперед изо всех сил.
Поэтому разработчики никогда не переключают режим работы. Они
не могут вернуться и навести порядок, потому что должны реализовать
следующую новую функцию, а потом еще одну, и еще, и еще. В результате
беспорядок нарастает, а продуктивность стремится к своему пределу около
нуляbevalorous
14.06.2019 12:39Крайности — это то, что губит любую идею, даже самую хорошую. Доведение до абсурда. Либо 0%, либо 100%, середины не дано.
dimm_ddr
14.06.2019 13:01Во всех раскладах — вы останетесь в выигрыше.
Это так, но только при нескольких условиях:
1. Глючный говнокод получилось довести до состояния «готового» продукта, до состояния когда его начнут покупать
2. У вас действительно получилось написать это поделие заметно быстрее
3. У вас действительно получилось захватить заметную долю рынка пока Ребекка допиливала свой вариант
4. Процесс переделки не занял слишком много времени и вы не потеряли фору которую получили выпустив продукт раньше
5. Пользователи не разочаровались медленным процессом исправления ошибок и допиливания новых фич и не ушли на продукт Ребекки когда он появился вместо того чтобы дожидаться вашей новой идеальной версии. Это скорее 4а впрочем чем самостоятельный 5, но все же.
Эти условия далеко не всегда будут выполняться. Хотя, возможно, что они будут выполняться достаточно часто, статистики у меня конечно же нет.
warranty_voider
14.06.2019 13:08+1Практика показывает, что никто не будет переписывать MVP заново, когда он начнет приносить прибыль. Менеджмент будет раз за разом требовать
откопать стюардессувносить изменения в уже работающую версию (ровно по той же причине — написать с нуля занимает время, а фичи нужны вчера), а она на это не рассчитана. Даже если две версии будут развиваться параллельно, это гонка Ахиллеса и черепахи. В итоге деньги они будут терять, потому что фичи пилятся дольше, чем могли бы.
tendium
13.06.2019 16:41+1Эта концепция подходит для уже работающего бизнеса. А вот для прощупывания рынка достаточно выкатить quick-n-dirty решение. Но главное быстро. А то время уйдёт и будет поздно. Это не значит, что в быстром решении нужно плевать вообще на все best practices и критерии качества, но чем-то можно поступиться, да.
grondek
14.06.2019 11:58+1Такие кривенькие внутри прототипы мы часто показываем на выставках, чтобы привлечь потенциальных клиентов. И пока они раскачаются и доберутся до покупки, мы можем все это по-нормальному запилить в основной продукт.
А если не взлетит, то и не сильно жалко — времени на прототип потрачено относительно немного.
Да, оно внутри кривое-косое, иногда буквально руками приходится поддерживать работоспособность, но оно и предназначено отработать 2-3 дня по 10 часов выставки и уйти на полку.bevalorous
14.06.2019 12:41По сути, это отдельный проект, который только выглядит как реальный, но таковым не является. Иногда хватает презентации мокапов дизайна, даже без реально работающего прототипа.
DrunkBear
14.06.2019 12:47Было немного страшно в первые 2 раза, когда небрежно накидывал прототип, его показывали заказчику в стиле «смотрите, оно может делать так и так, а ещё мигать лампочкой. Что вы ещё хотите и как часто мигать?», а заказчик говорил «Супер, заверните. Только лампочку на прожектор поменяйте и удалённое управление поставьте, мы от такой штуке 2 года мечтали. Что? Ждать пока перепилите? Некогда, нам и так сойдёт, внедряйте быстрее.»
Поэтому пришлось найти баланс, чтоб прототип не ломался от пролетающих рядом птиц, собирался быстро и при этом, не выглядел как месть команде.grondek
14.06.2019 13:04Наши заказчики довольно долго раскачиваются, так сложилось. Пока ТЗ, пока пилотный проект, пока поставка пройдет.
Поэтому так можно. Но это для чего-то совсем нового, попонтоваться, а вот смотрите, у нас уже есть, а у всех остальных нет и пока не предвидится.
Застолбить рынок и перетянуть на себя внимание заказчика.DrunkBear
14.06.2019 14:18Ну да, в качестве демо пойдёт.
Помню, коллега делал какую-то навороченую фичу 2 недели, на неё посмотрели, сказали «не, фигня получилась, удаляй.»
В ответ на безумный взгляд пояснили: «мы же посмотреть просили, как оно будет выглядеть, а не полноценный релиз делать»
JediPhilosopher
13.06.2019 17:37+1Про скорость и качество - лучший коммент на хабре на эту тему:
Я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами. И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл. Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков. Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
Собственно в этом и суть. Автор статьи пишет
Наши с Ребеккой приложения выглядят сейчас почти одинаковыми, но через несколько месяцев высокое качество кода Ребекки позволит ей выпускать каждую неделю по новой фиче, а я застряну на месте, стараясь справиться с техдолгом и пытаясь запустить хотя бы одну новую фичу. Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки, несмотря на то, что оно стоит дороже.
Но он не учитывает несколько ключевых факторов:
- Приложение Ребекки может банально не прожить несколько месяцев чтобы выйти вперед по качеству фич — так как всех пользователей уже собрал автор. В итоге ее стартап обанкротится, закроется и будет выкуплен автором, нахватавшим денег своим кривым-косым, но вышедшим раньше приложением
- Люди консервативны. К тому моменту как Ребекка выпустит свое отлаженное приложение на рынок, у приложения автора уже будет обширная пользовательская база и коммьюнити, которые уже не будут гореть желанием менять знакомое (пусть и не самое лучшее) на что-то новое и непривычное
Поэтому и имеем то что имеем — выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.HellWalk
14.06.2019 10:57выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
Уже несколько раз на этой странице упоминают проекты, которые «выходят на новые рынки» и захватывают их. И если не зарелизился за месяц — все, поезд ушел, другие уже заняли нишу. А можно конкретные примеры?
Вот Wandex был первой поисковой системой. По вашей логике, он должен был занять рынок, а все остальные остались бы в пролете. Но почему-то рынок занял другой поисковик.
В России тоже самое — когда-то топ-1 поисковиком и сайтом был Рамблер, а где он сейчас?
Фейсбук так же не был первой социальной сетью.
На моей практике, все слова о том, что «Надо зарелизиться как можно скорее, иначе поезд уедет», отражают только капризные хотелки менеджмента, которым хочется побыстрее. И больше ничего.
Newbilius
14.06.2019 11:07У проекта есть бюджет. Предприниматель взял кредит, заработал в другом месте — не важно, главное что сумма денег ограничена. И этот бюджет определяет сроки разработки — ты или укладываешься в него, или проект умирает не выйдя в свет.
General_Failure
14.06.2019 11:59Если бюджет ограничен, и вдруг оказалось что чего-то не успевается, значит придётся что-то отложить или выкинуть из фичей, иначе придётся жертвовать качеством.
bevalorous
14.06.2019 11:12Вы забываете о том, что после захвата рынка у вас, скорее всего, не будет уже ни времени, ни денег на его исправление. Будут другие задачи и другие затраты. И для их реализации вам придется говнокодить дальше, потому что архитектура обязывает. Ком технического долга будет только расти и расти, разработка новых фич будет становиться сложнее и сложнее, цена ошибочных решений все выше и выше, пока ваш проект не загниет окончательно.
JediPhilosopher
15.06.2019 21:07А тут уже возможны варианты. И конечно правильным решением будет потихоньку этот технический долг разгребать. Но только тогда, когда уже есть какие-то деньги и доход. И видение продукта, основанного на реальном пользовательском опыте.
EvgeniiR
14.06.2019 12:17Но он не учитывает несколько ключевых факторов:
Приложение Ребекки может банально не прожить несколько месяцев чтобы выйти вперед по качеству фич — так как всех пользователей уже собрал автор.
Поэтому и имеем то что имеем — выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
Лихо вы, однако, сначала высказываете предположение(«может банально не прожить»), а потом строите утверждение так, будто предположение доказано и уже превратилось превратилось в 100%-ную истину.
Люди консервативны. К тому моменту как Ребекка выпустит свое отлаженное приложение на рынок, у приложения автора уже будет обширная пользовательская база и коммьюнити, которые уже не будут гореть желанием менять знакомое (пусть и не самое лучшее) на что-то новое и непривычное
Тем не менее, живут ведь как-то новые соц. сети, месседжеры и т.п., и далеко не все «первые» продукты в популярных нынче сферах до текущего дня дожили в принципе.JediPhilosopher
15.06.2019 21:10И много сейчас новых соцсетей и мессенджеров?
У тех же мессенджеров мы видели смену пальмы первенства из-за полного и абсолютного продалбывания всех полимеров старым чемпионом. Как ICQ потеряла лидерство и уступило скайпу, как скайп продолбал все вотсапу — это совершенно эпичные, но разовые истории. И опять же тут ни при чем особо архитектура и красота кода, скорее новые фичи и изначально новый подход.
В то же время вон даже на хабре были статьи про какие-то новые мессенджеры, с идеальной структурой и стандартами, продуманные и т.п., но нафиг никому не нужные. Потому что у них нет киллер фич, а к переделу рынка они уже опоздали.
sromik
13.06.2019 18:00«На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет».
Попробуем:
— Что важнее в разработке ПО: скорость или качество?
— Нет.
Превосходно.
На тему холивара «Качество vs Скорость» бывшие коллеги замутили целый рэп-батл: youtu.be/L19wvjOcW9ENewbilius
14.06.2019 11:09Получилось смешно, но автор статьи тоже не согласен с такой постановкой ;-)
Закон Беттериджа гласит: «На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет». Те, кто знаком со мной лично, знают, что я не разделяю эту мысль
dzsysop
13.06.2019 18:49Статья вышла какая-то непонятная.
С одной стороны автор постоянно утверждает что качество того стоит, с другой стороны не было представлено ни одного внятного обоснования этого утверждения. А просто описано несколько историй которые не подтверждают и не опровергают весьма спорное утверждение.
Еще хотелось бы обратить внимание что задачи решаемые разработчиками ооочень разнообразны.
Кейс №1. Есть конторы которые делают плагины для чего-то и это их основной вид деятельности. Они изначально не выбирают архитектуру, но обычно у них есть некий свод правил или стандартов которым они обязаны следовать чтобы удовлетворять требованиям материнского продукта (WordPress, 1C, Jira, Github, Jenkins, Apache и проч.)
Кейс №2. Предположим что контора занимается разработкой софта для спутника для какой-либо космической программы. Конечно инженерам бы хотелось верить и разрабатывать с учетом перспективы. Но на практике скорость разработки, внедрения и запуска таких систем показывает, что заказчик хочет решение на 100% отвечающее сегодняшним требованиям. И его до достаточно объективным причинам абсолютно не интересует будет ли это решение кроссплатформенным или масштабируемым или будет ли оно работать на следующем поколении процессоров и как оно себя поведет если… Заказчика не интересует увеличение производительности в N раз просто потому что система не предполагает никаких скачкообразных нагрузок.
Кейс №3 Есть задача создать сайт, скажем блог или социальную сеть. Соответственно есть 2 варианта: взять уже готовое и обкатанное решение или начать писать с нуля с правильной и кастомизированной под себя архитектурой. Первый вариант однозначно дешевле и первый вариант системы будет готов в разы или десятки раз быстрее. Второй вариант «правильнее» и чище и «качественнее» в долгосрочной перспективе, потому что любой устоявшийся продукт на рынке всегда имеет свои ограничения и помимо фич свои баги и уязвимости, а написанный с нуля под наши нужды теоретически может учитывать все известные проблемы существующих аналогов.
Мне кажется я могу продолжать довольно долго. Моя позиция состоит в том, что я согласен с автором по основному утверждению:
что постановка вопроса из заголовка этой статьи просто не имеет смысла
Но не согласен с его попыткой аргументировать в пользу:
что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Этот компромисс и принцип вполне применим. Просто всегда надо рассматривать конкретный проект и решаемую задачу. Именно от задачи зависит чем мы можем пожертвовать, а чем не можем.
В каких-то ситуациях можно обойтись без тестирования (как фазы) вообще и положиться на то что «оно же работает». А в каких-то надо стать практически параноиком и изобретать тесты на все возможные и невозможные сценарии.
В каких-то ситуациях можно и нужно использовать типовые решения, а в каких-то надо писать систему с нуля с минимумом зависимостей.
Опять же размер и качество команды тоже накладывает свой отпечаток на конечный продукт и от этого нельзя просто отмахнуться. Код после какого-нибудь реального гения разработки который заложил архитектуру на десятилетия вперед потом кто-то должен поддерживать и этот кто-то иногда может за неделю или месяц не разобраться что там к чему и где заканчивается одна абстракция и начинается другая. Люди приходят и уходят, а проект остается.
user_man
13.06.2019 19:43В общем автор не разобрался в рыночной экономике. Для рассейских коллег это вполне понятно, многие — выходцы из СССР, а некоторые — жертвы ЕГЭ. Но западенец-то что-ж такой безграмотный?
Вот он пишет:
>> Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки
Эту фразу выше уже откомментировали, но несколько огульно. На самом деле необходимо указать нишу, в которой предложенный западным автором подход всё-таки будет работать. И эта ниша очень узкая.
Подход будет работать в конкурентной среде для пары фирм с серьёзными финансовыми возможностями. То есть конкуренция не даст банально пользоваться монополистическим положением, а крупные финансовые средства дадут возможность вкладываться в долгую. Вот только тогда из идеи что-то выйдет. Во всех же остальных случаях идея нереализуема. Причины уже перечислены в комментариях выше. Главное — действуют много дополнительных факторов, которые нивелируют разницу в качестве ПО. Поэтому (если помечтать) некий второй гугл мог бы вложиться сегодня во второй ведроид и сделать его намного лучше, но реальность такова, что рынок ОС для мобилок весьма убогий, контролируется устоявшимися монополистами, а инвесторы совершенно не готовы просто поверить неким программистам, мол они сделают что-то лучше и только за счёт этого всё взлетит.
В общем ситуация из статьи как минимум редка. Где в мире есть конкурентный рынок с равными финансовыми возможностями для участников и готовностью топов слушать программистов?
Хотя вот тот же «телеграм» вполне взлетел. Не знаю на счёт качества нутра, но снаружи выглядит неплохо, фичи добавляются, вышел на рынок много позже конкурентов. Но за счёт чего вышел? Это вопрос. Большие деньги там точно были, но на что их тратили? На архитектуру или на рекламу? В общем знаю лишь отдалённо напоминающие предложенный в статье варианты, но не уверен в качестве кода. Может кто-то лично что-то внутри ковырял? Хотя бы качество выставленного API может оценить?
UdarEC
14.06.2019 12:27+2В общем автор не разобрался в рыночной экономике. Для рассейских коллег это вполне понятно, многие — выходцы из СССР, а некоторые — жертвы ЕГЭ. Но западенец-то что-ж такой безграмотный?
Как мне кажется,1 шанс на миллион, дело в том, что он понимает, что не наступило еще на планете этой «рыночной экономики» в полноте ее определения? (хуавеи и прочие экономические войны подтверждение тому).
В таком случае, вера в «законы рынка», который сам все решит наилучшим образом, ближе к религиозным воззрениям, а не научным теориям. Вот он и не питает иллюзий на этот этот счет.
В общем ситуация из статьи как минимум редка. Где в мире есть конкурентный рынок с равными финансовыми возможностями для участников и готовностью топов слушать программистов?
Если не касаться всяких хобби проектов, а рассматривать более-менее нормальный бизнес, то эта ситуация не сильно редка. Обычно, если бизнесу нужно проверить гипотезу, то они делают MVP, это и быстро, и значительно дешевле. Если идея стреляет, пишут, по большей части, заново, на основе и с учетом результатов MVP.
Этапы развития полноценного продукта уже планируют с учетом влияние «внутреннего качества ПО», так как это ощутимо будет влиять на скорость и стоимость разработки в долгосрок.
У такого продукта есть шансы получить хороший результат, который сможет приносить прибыль и быть конкурентноспособным.
Если MVP с низким «внутренним качеством» начинают развивать и насыщать фичами, забив на проблемы архитектуры, то такой продукт достаточно быстро приходит в негодность и экспоненциально увеличивает стоимость своего обслуживания. Успех такого продукта будет зависеть только от мастерства продажников, сколько они смогут продать этого «товара», пока он не протухнет окончательно.
Хотя вот тот же «телеграм» вполне взлетел. Не знаю на счёт качества нутра, но снаружи выглядит неплохо, фичи добавляются, вышел на рынок много позже конкурентов. Но за счёт чего вышел?
У них нутро закрытое, поэтому навряд ли кто-то ответит на этот вопрос в контексте качества ПО.user_man
14.06.2019 14:20>> дело в том, что он понимает, что не наступило еще на планете этой «рыночной экономики»
Нет, это просто технарь, он не знает, что такое экономика, не то что рынок. Самая обычная для технарей ситуация.
>> то эта ситуация не сильно редка
И где же примеры? Я вот вижу постоянное ухудшение. Ожидания пользователей банально игнорируются. Но как это возможно? Да очень просто — рынок монополизирован. Возьмите например браузеры — они в принципе не настраиваемы. То есть теоретически можно попытаться, но сам набор настроек просто крошечный. А казалось бы — вот поляна для бизнеса, вложился в хороший браузер и окучивай миллиарды пользователей. Но нет там никакой конкуренции, даже если «рассматривать более-менее нормальный бизнес».
>> если бизнесу нужно проверить гипотезу, то они делают MVP
Один делает, а десять других покупают готовую основу у тех же хобби или неудачных стартапов. Бизнес склонен сильно экономить деньги, а потому mvp сделают лишь если это стоит <1% от R&D бюджета. А вот покупка, помимо собственно продукта, даёт ещё и возможность перепродажи если что не так.
>> Этапы развития полноценного продукта уже планируют с учетом влияние «внутреннего качества ПО»
Это вы откуда взяли? В одном единственном случае на планете наблюдали? И да, это «учёт влияния» как вычисляется? И кем? Вы в деталях-то хоть немного разбирались? Или ляпнули первый рекламный текст «за всё хорошее»?
>> У такого продукта есть шансы получить хороший результат
Ну да, в точности по какой-то модной книжке — обтекаемо и абсолютно бездоказательно. Ведь кто может поспорить — теоретически у всего на свете «есть шанс».
>> Если MVP с низким «внутренним качеством» начинают развивать и насыщать фичами…
Купленное гуано обычно как раз «с низким «внутренним качеством»», а насыщать фичами надо, потому что покупали для некой ниши, для которой определили нужный набор фич, а в купленном этого нет.
Повторюсь — mvp по большей части ваша фантазия (ну или из рекламной книжки). Идеи отрабатывают на хобби да стартапах, а потом покупают, либо инвестируют. Хотя может покажете известный пример, выстреливший именно по методике mvp? Но сомневаюсь. А вот купленных да проинвестированных совсем не mvp — огромное количество.UdarEC
14.06.2019 15:02Бизнес склонен сильно экономить деньги, а потому mvp сделают лишь если это стоит <1% от R&D бюджета.
А это данные какой-то статистики или вы тоже ляпнули какую-то чепуху с потолка?
Говорить про этап MVP, что это рекламный булшит и он не работает, это бредятина чистой воды. Customer Development сложно представить без MVP или его подобия. CustDev тоже не делается никогда?
То что вы описали, вкладываться в стартапы, которые на 95% это очковтирательство и поедание бабок инвестора до очередного раунда, не есть модель успешного выхода на рынок. Это слишком примитивно.
На счет того, что рынок монополизирован, согласен, это есть, и во многих сферах приводит к отсутствую конкуренции и нездоровым тенденциям.
Я не ради спора написал свой комментарий, а потому что считаю мнение автора недалеким от реальности.user_man
14.06.2019 19:14>> А это данные какой-то статистики или вы тоже ляпнули какую-то чепуху с потолка?
Это из личного опыта, наблюдений. Более или менее известные продукты в основном перекупались у их авторов (небольших фирм).
>> Говорить про этап MVP, что это рекламный булшит и он не работает, это бредятина чистой воды.
Я не говорил «не работает», но точно, что работает крайне редко. Выкидывать прототип мало кто решается, потому что считают, что дорого. А на уровне больших контор — покупают, а не прототипируют.
>> вкладываться в стартапы, которые на 95% это очковтирательство и поедание бабок инвестора до очередного раунда, не есть модель успешного выхода на рынок
Ну вам виднее, только капитализация некоторых из подобных стартапов сегодня под пол триллиона долларов. А так — да, многие дадут убытки. Но пример всяческих фэйсбуков у вас перед глазами. Но глаза смотрят куда-то не туда. Вы про какой-то малый бизнес поди? Но там как раз очень мало денег, а потому очень сложно обеспечить вложение в долгую. А там, где денег много — тупо покупают готовое. Почти все известные фэйсбуки — результат именно таких инвестиций.
>> Я не ради спора написал свой комментарий, а потому что считаю мнение автора недалеким от реальности.
Ну так в этом суть — далеко или не далеко. И я считаю, что далеко. Назовёте пример конкурентной среды, где есть деньги и их вкладывают в качество? Что-то я кроме не совсем понятного старта телеграма ничего более и вспомнить-то не могу. То есть я реально не вижу подтверждений вашей уверенности. Просто не вижу. Но вы можете показать пример.
firedragon
14.06.2019 07:42Современный рынок похож на стаю птиц: Налетели, погалдели, оставили после себя кучу, сами понимаете чего и полетели в другое место. Кто-то приходит с лопатой и из этого бесполезного делает удобрение для своего садика.
И практически все сосредоточены на фичах, живой пример ядро линукса. Хорошо это или плохо не знаю но оправдало себя. БСД тихо умер. А вот Windows живет и здравствует. Как впрочем и андроид.
bevalorous
14.06.2019 09:17Согласен со статьей, обычно выбирают тактический выигрыш, но получают стратегический проигрыш. Экономят сегодня, чтобы потратить гораздо больше завтра.
По моему скромному опыту могу сказать, что написание качественного кода отнюдь не настолько сильно отличается от говнокода по затратам времени и денег. Тесты экономят время на отладке и сильно ускоряют саму разработку. Создание абстракций, продумывание контрактов и DI практически ничего не стоят, но повышают тестируемость и снижают зацепление частей системы, что сильно увеличивает скорость внедрения новых фич.
И наоборот, затраты на перелопачивание говнокода обычно очень сильно недооцениваются:- во-первых, это чаще всего делают не те, кто этот говнокод написал, да и кто признается, что написал Big Ball of Mud, который проще переписать с нуля, чем переделать?
- во-вторых, работа с легаси — непрестижный и неблагодарный труд, об этом статьи обычно не пишут; книг про работу с legacy — раз-два, и обчелся, зато про новые технологии выходят каждый месяц по несколько;
- при перелопачивании плохого кода никакой ценности для пользователей в продукт не добавляется, это чистые расходы времени команды и денег фирмы;
- затраты на переписывание обычно выше, чем на то, чтобы сразу сделать хорошо: приходится думать об обратной совместимости (не сломать API, оставить тот же UX и т.п.) и исправлять возникающие регрессии; надо ли говорить, что раз на тестах сэкономили, то значит, баги можно выловить только ручным тестированием или на продакшне?
В общем, чаще всего причины ситуации — обычные лень, невежество и неуважение к времени других разработчиков и деньгам работодателя, а вовсе не радение об экономии или поиск компромисса. Компромисс можно искать, если вы знаете и понимаете альтернативы. Если вы умеете писать только говнокод и не понимаете плюсы и минусы альтернативных подходов — не надо искать себе и своему продукту оправданий.UdarEC
14.06.2019 12:35Очень верно отмечено. Я бы добавил еще одну возможную причину: сам бизнес, который осознанно требуют минимизировать этап проектирования и делать продукт, который можно показать быстро уже сейчас. Торопыги-дилетанты.
bevalorous
14.06.2019 12:44-1MVC им в помощь. Или прототип. Но, сознательно жертвуя качеством, необходимо сразу заложить в планы перелопачивание. Все будут в выигрыше.
bevalorous
14.06.2019 11:19-1Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.
C. П. Королев
Magic_B
14.06.2019 12:10Полагаю, что качественно просто не умеет рынок делать… Мало таких специалистов.
Аргумент "давайте сделаем быстро, плохо и заработаем денег быстрее" совершенно понятен! Но, меня никто никогда не сможет заставить сделать плохо, я вот не умею так… Пускай так и будет. Каждый должен занять свое место!bevalorous
14.06.2019 12:46Есть еще часто неосознаваемая некомпетентность, сталкивался на своем собственном опыте множество раз. Это когда смотришь на код, написанный тобой же год назад, и понимаешь, что так больше не пишешь, никогда писать не будешь, а если увидишь у кого-то из коллег — объяснишь, почему так писать нельзя. А ведь год назад считал, что крут, и гордился этим кодом, вот поди ж ты.
testopatolog
14.06.2019 12:44Благодарен Автору за интересный вопрос.
Чтобы на него ответить, смоделируем ситуацию:
Допустим, на рынке ПО имеется продукт, который решает N задач, и его стоимость X — это объективная стоимость Разработки (соразмерная с прочими аналогами на рынке).
Примечание 1: здравый смысл подсказывает, что глупо создавать и нести на рынок продукт, затраты на который значительно превышают рыночную стоимость.
У пользователя субъективная оценка стоимости этого продукта, основанная на его Качестве, т.е. признаков этого продукта в их объединяющем критерии типа:
— ему требуется решать M задач (M<N), и он прикидывает полезную стоимость в продукте, как Y (Y<Х);
— развертывание и обслуживание данного продукта при эксплуатации потребует трудозатрат стоимостью Z;
— рост производительности труда и дохода, при использовании продукта, оценивается как P.
Очевидно, что пользователь приобретает продукт, если ожидается, что субъективная стоимость его Качества Y-Z+P больше объективной стоимости Разработки X.
И окончательный ответ на вопрос «Стоит ли высокое качество ПО затрат на его разработку?» формируется, когда в процессе эксплуатации продукта эти ожидания пользователя оправдываются.
Примечание 2: сравнивать субъективное с объективным не легче, чем квадратное с красным, но если есть общий критерий для оценки (стоимость), то почему бы и нет.
Главное, чтобы не запутать себя и других, не надо ничего вплетать в базовые понятия и выбрать адекватную модель для анализа.testopatolog
14.06.2019 13:46В рамках модели (предложенной в комментарии выше) добавлю уточнение, пользователь приобретает продукт (ПО) с эксклюзивными правами на его.
DrPass
14.06.2019 13:54Это полезная модель для лабы по эконометрике, но она никакого отношения не имеет к выпуску и продажам ПО в реальной жизни. Хотя бы потому, что
а) объективная стоимость разработки — параметр в общем случае неизвестный, и есть лишь его приближенные оценки, кроме того, это даже не одно число, а функция, меняющаяся в широком диапазоне в зависимости от массы других параметров.
б) у пользователя в общем случае нет никакой субъективной выражаемой численно оценки, по крайней мере, на основе «Качества» продукта. Популярность продукта основывается не столько на его функционале, сколько на его маркетинге, на его доступности, на его соответствии ожиданиям и т.д.testopatolog
14.06.2019 15:53Ваша обобщенная аргументация сомнительна, прокомментирую это по соответствующим пунктам:
a) Объективная стоимость разработки определяется рынком, в любом случае известна из договора купли-продажи готового ПО, устраивает и Разработку и Пользователя.
б) Грамотные пользователи-Организации проводят серьёзный многосторонний анализ с интеграционной оценкой выбора планируемого к приобретению стороннего ПО требуемого качества, когда собираются его встраивать в свои проекты/процессы.DrPass
14.06.2019 17:26Вы, если честно, смешиваете в одну кучу разные понятия.
Что такое «договор купли-продажи готового ПО»? Это покупка коробочной версии у поставщика ПО? Это покупка ПО, написанного под заказ для конкретного покупателя? Это покупка ПО индивидуальным потребителем по публичной оферте на массовом маркете? Стоимость разработки коррелирует с ценой продажи во втором варианте (и то, только если речь идет не об отечественном рынке индивидуальной энтерпрайз-разработки). Но этот вариант значительно уступает первому и третьему по объему продаж. При этом в первом варианте нередко заложены сверхприбыли, а в третьем нередко продажи и в минус идут. При этом отношения на этом рынке, извините за каламбур, не слишком рыночные.
б) Грамотные пользователи-Организации проводят серьёзный многосторонний анализ с интеграционной оценкой выбора планируемого к приобретению стороннего ПО требуемого качества,
Ок, значит, вы в вашей модели не указали рамки её применимости. Что она подходит, но лишь для описания ценообразования для 0.01% доли рынка ПО.testopatolog
14.06.2019 19:55Кажется я понял, что Вы не совсем понимаете, что такое «объективная стоимость разработки», поясню.
Предположим, несколько компаний разработали ПО с одинаковой функциональностью. Реальная стоимость разработки у каждого своя, издержки на производство могут сильно отличаться, но когда они выставляют своё ПО на рынок, механизм спроса/предложения формирует Объективную стоимость разработки (если она разная, то, делая выбор, есть повод глубже разобраться из-за чего).
Пользователю объективная стоимость должна быть известна, и, если выгодна, то он её заплатит при покупке, получая продукт нужного качества и соответствующий эффект от него.
Реальная же стоимость разработки ему по барабану, более того, она может являться коммерческой тайной Разработчика.DrPass
14.06.2019 20:49Кажется я понял, что Вы не совсем понимаете, что такое «объективная стоимость разработки», поясню
Как я могу понимать, если это определение вы сами придумали и сами используете :)
Я считаю его лишним. Есть общепринятое понятие «равновесная цена», которое используется в том смысле, в котором вы выше пытаетесь применить эту «объективную стоимость разработки». Но эта самая равновесная цена имеет смысл только для рынков, приближенных к рынкам свободной конкуренции. Рынок ПО многогранен, имеет массу секторов с разными правилами, и правила рынка свободной конкуренции там действуют лишь на некоторых из них, в частности, на онлайновых маркетах мобильного ПО, и то не в полной мере, т.к. там активно вмешиваются регуляторы.testopatolog
14.06.2019 22:02Разрешите порекомендовать Вам для общего развития:
Объективная стоимость (ценность) — меновая пропорция, цена, которая формируется в ходе конкуренции на рынке.
Источник: Гацалов М.М. «Современный экономический словарь-справочник.»dzsysop
14.06.2019 22:43Исходя из этого определения вы приравниваете термин «объективная стоимость» к общепринятому и устоявшемуся «рыночная стоимость».
Для меня как человека обыкновенного и понимающего современный русский язык, было бы в разы понятнее если бы вы сразу и использовали термин «рыночная цена» или «рыночная стоимость».
А вот термин «объективная стоимость разработки» звучит для мен почти противоположно по смыслу. Несмотря и, даже получается, вопреки, вашему приведенному определению, исходя из моего понимания норм русского языка и контекста, я бы связал термин «объективная стоимость разработки» скорее с «совокупной себестоимостью затрат необходимых для разработки», с учетом некоего набора лимитирующих критериев, которые позволят говорить о заявленной объективности.
Но исходя из вашего определения продолжение дискуссии для меня не имеет смысла, поскольку на лицо явная подмена понятий и жонглирование терминами, за которой непонятны ни утверждение само по себе, ни контраргументы оппонента.testopatolog
14.06.2019 23:03А я искренне благодарен вам, потому что узнал много нового и было о чём подумать, спасибо.
lotse8
14.06.2019 15:11Живой пример Microsoft. Там код сразу никто не вылизывает, а сразу кидают в production. Потом годами заплатки делают. И ничего себе безбедно живут уже много лет. Такая стратегия себя оправдывает, как мы видим. Остальное все теории.
DrPass
14.06.2019 15:27Вот не надо про Microsoft. У них как раз до недавнего времени был очень строгий контроль качества, и по отношению количества багов к сложности ПО их не в чем упрекнуть. Сейчас да, невооруженным взглядом можно заметить ухудшение. Но как это скажется/не скажется на их доходах, увидим позже, ещё рано судить.
user_man
14.06.2019 19:18>> Вот не надо про Microsoft
Ну ладно, а как вам гугл? Вы с его ведроидом на сколько плотно общались? Хотя бы на частоту обновлений внимания не обращали? Я уж не говорю про внутренности.
General_Failure
14.06.2019 15:30А у них были серьёзные конкуренты? Такая стратегия себя оправдывает, когда пользователи сидят на продукте как торчки на герыче, и никуда слезть не могут. Да и со времён винды 9х дела с качеством софта у них всё-таки получше стали.
loysagienn
14.06.2019 16:14Опытные команды отличаются тем, что они вполне бывает, что пишут говнокод, но держат этот говнокод под контролем.
Практически всегда некий огромный проект можно разбить на много маленьких кусков, у каждого из которых своя зона ответственности. Каждый из маленьких кусков в свою очередь делится на еще несколько маленьких кусков, и так далее. И опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
И вот у нас получается побитый на модули проект, и модули как-то между собой взаимодействуют (и это не обязательно микросервисы, в монолите код тоже можно побить на модули). И тут стоит уделить внимание именно формату взаимодействия, сделать его максимально продуманным и удобным с учетом возможных хотелок в будущем.
Дальше начинаем писать эти модули, и вот тут бизнесу может потребоваться выпустить продукт побыстрее, чем мы это сделаем, если будем писать весь код максимально качественно. Что делать? Бывают ситуации, когда некоторые не самые важные модули можно сделать из говна и палок на основе готовых решений очень быстро — делаем так. Иногда бывает такое, что мы не уверены, а нужен ли нам какой-то конкретный функционал, и если нужен, то в каком виде, нет определенности, или мы просто хотим провести какой-то эксперимент. Тут нет смысла писать максимально качественно, можно не покрывать тестами. В будущем требования могут измениться, или вообще мы поймем что этим никто не пользуется и выкинем. Какие-то критически важные модули всегда пишутся максимально качественно, покрываются тестами, на них не экономим.
Ну и конечно эти все решения принимаются в обсуждении с бизнесом. Мы рассказываем бизнесу, что вот тут мы сейчас идем на компромисс ради скорости, но у нас копится техдолг, сейчас мы сделаем по-простому, но если мы захотим в дальнейшем развивать эту часть, то нам нужно будет дополнительное время, чтобы этот техдолг разгрести.
И если вот так гибко лавировать между качеством и скоростью, то у нас получается, что где-то код написан качественно, где-то нет, но мы это все держим под контролем и не скатываемся в ситуацию, когда у нас весь сервис — куча говна, в которой никто уже не может нормально ориентироваться.
CoolMind
14.06.2019 19:41Статья не понравилась, со статьёй полностью не согласен. Слишком много в последнее время появляется подобных мантр.
1. Что такое качество кода? Я могу сориентироваться, что чашка сделана некачественно, неправильно сделан шиномонтаж. А что вы скажете о качестве кода? Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.
2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем. Наоборот, всё время существования проекта он может изрядно его тормозить. Пока вы будете думать о том, в какой слой вынести этот метод, успеет поменяться задание целиком.
3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.
4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.
5. Хоть с архитектурой, хоть без вы можете написать ужасный код.
6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.
7. «Некоторым командам удаётся даже получить обратный эффект, когда каждая новая фича выпускается быстрее предыдущей за счёт того, что удаётся переиспользовать уже написанный код».
Какое счастье, что такое происходит редко. Неудачное изменение в одном месте поломает весь код.
8. «Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Вы серьёзно? А что такое „правильно“? Почему его „правильное“ решение не устареет через полгода и не станет неправильным?
9. Я видел один проект, где чистота архитектуры была выставлена на первый план. Это отнимало очень много моральных сил со всеми тестированиями, методологиями, абстракциями. Я не видел более медленного проекта. По моим оценкам, всё должно было делаться раза в три быстрее и без „архитектуры“.EvgeniiR
14.06.2019 23:49+1Что такое качество кода?
Влияние совокупности принятых и реализованных на какой-то момент времени решений, на объём трудозатрат требуемый для внедрения последующих фич в проект.
Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.
Получается, сфера разработки ПО развивается в сторону управления сложностью последние пол века абсолютно не плодородно, программы не стали больше?
2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем.
Если проект не будет развиваться то ему ничего уже на даст ускорения, а если будет то Качественный Код здорово поможет ему в развитии, потому что читать код обычно приходится больше чем писать.
Наоборот, всё время существования проекта он может изрядно его тормозить.
Это некачественный код, либо излишний идеализм разработчиков.
Пока вы будете думать о том, в какой слой вынести этот метод, успеет поменяться задание целиком.
А это уже говорит о проблемах менеджмента
3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.
Абстракции нужны не ради абстракций, а для сокрытия несущественных деталей, чтобы упростить понимание логики системы, облегчить дальнейшее усовершенствование системы, и упростить процедуру входа новичков в проект, как и архитектура.
4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.
Статистики у вас конечно же нет?
Большое количество комментариев в коде уже говорит о проблемах.
Забавно, кстати, этот абзац — он ведь про то, чего по вашим же словам — «нет»
5. Хоть с архитектурой, хоть без вы можете написать ужасный код.
Хоть с архитектурой хоть без вы можете построить некачественно здание(речь вообще вроде шла о качественной архитектуре)
6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.
Ответ который я скрыл после написания updРешения, сложность которых обусловлена и оправдана сложностью предметной области, и которые действительно являются принципиально новыми пилит пара калек в гугле, энтерпрайза всякого это касается кратно меньше.loysagienn
15.06.2019 02:56+1Я сейчас работаю во фронтенд команде одного проекта, где в одном нашем фронтовом репозитории каждый день пишут код больше 25 человек, каждый день собираются и катаются релизы. И этот проект живет уже не один год. И у нас есть архитектура, методологии, абстракции, юнит тесты, функциональные тесты, статическая типизация и т.д.
Вы знаете, как в таких условиях без этого всего годами поддерживать код на таком уровне, чтобы я мог легко поправить что-нибудь в той части, где код писался полтора года назад неизвестно кем, и быть абсолютно уверенным, что я нигде ничего не сломал при этом?DrPass
15.06.2019 03:05Абсолютно уверенным вы быть не можете, но можете покрыть код тестами так, что вы будете достаточно уверенным.
gBear
15.06.2019 22:29-2Очередное «ожидание vs реальность», к сожалению.
В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Прочитаешь вот такое — удивишься, конечно — но таки ждешь «ниже» хотя бы попытку показать *связь* между качеством *продукта* и качеством его *кодовой базы*. А натыкаешься наПоэтому я разделяю критерии качества на две категории: внешние (например, UI/UX или наличие багов) и внутренние (архитектура).
Ну ок… пусть хоть так. Но, связь-то покажите…Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать.
И? Это чтоль что-то говорит о качестве *продукта*?! О качестве «внешнем»?! Ну можем «фичи» быстрее делать… наверное. Дальше-то что?При обсуждении качества кода с менеджментом, я призываю к тому чтобы рассматривать его исключительно как экономический показатель. Если программа внутри сделана качественно, то будет проще и дешевле добавлять в неё новые фичи
Это — далеко — не факт. Ибо это — внезапно — от конкретной «фичи» зависит не меньше, чем от качества *кодовой базы* или архитектуры. Я это вам как «менеджмент» говорю.Это означает, что вложения в написание качественного кода, в конечном счёте, снижают общие затраты на разработку.
На *разработку*?! Really?
Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(EvgeniiR
16.06.2019 00:06+1Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать.
И? Это чтоль что-то говорит о качестве *продукта*?! О качестве «внешнем»?! Ну можем «фичи» быстрее делать… наверное. Дальше-то что?
Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(
Я это вам как «менеджмент» говорю.
Ответьте, как «менеджмент», какой продукт сочтут более качественным пользователи — работающее стабильно и без багов приложение с регулярной поставкой новых фич в обещанные сроки, или приложение в котором релизы и новые фичи выходят с затяжкой в месяцы, а баги обкатываются на живых пользователях(которое, наверняка, ещё и стоить будет дороже)?DrPass
16.06.2019 02:18А можно я, как тоже «менеджмент», отвечу?
Пользователи хотят быстрое и стабильное, с регулярной поставкой заказанных фич в обещанные сроки, но ограничения по ресурсам практически всегда заставляют чем-то жертвовать. А чем именно, уже зависит от конкретного продукта, конкретного рынка, конкретной задачи. Я не могу сказать, что важнее, качество кода, скорость разработки фич, отсутствие багов, легкость сопровождения. Везде по-разному. Если какая-то бизнес-фича критична для заказчика, её, бывает, приходится делать на коленке и потом год ещё подпирать костылями на продакшене. Если какой-то сервис приносит деньги 24х7, то заказчик скажет «вы хоть два месяца эту мелкую фичу вылизывайте и обматывайте тестами, но чтобы деплой был без единого сучка и задоринки». А бывает и так, что проект делается тесно с заказчиком, который решил, что негоже ему ещё и глубокое тестирование оплачивать, когда своих сотрудников толпа сидит бездельничает, и да, тогда баги обкатываются на живых пользователях в продакшене.
Вот чего я ни разу в жизни не замечал, чтобы это было нужно и интересно пользователям, так это Continuous Delivery. Наоборот, почти все просят вернуться к редким, но крупным обновлениям версий. А те, кто не просит, просто молча терпят. Но это как бы мой опыт, у кого-то может быть иначе.testopatolog
16.06.2019 23:52+2что важнее, качество кода, скорость разработки фич, отсутствие багов, легкость сопровождения
— это бессмысленное сопоставление внешних результатов в одной плоскости Разработки — тупик, для того, кто не знаком с философией, не знает, например, закона единства и борьбы противоположностей, не видит дуального соотношения в Разработке:
* первое — её эффективность для Разработчика;
* второе — её качество для Пользователя.
Увидев это, можно:
1. легко понять, что частичное взаимопроникновение и разнополюсность этих сторон и обусловливают развитие ПО;
2. утвердительно ответить Автору: высокое качество ПО стоит затрат на его разработку.bivo Автор
17.06.2019 00:00Разработка, Разработчик, Пользователь — и всё с большой буквы, это прекрасно (без иронии)
Если бы вписать в эту идею-формулу ещё Продукт и Менеджмент, будет вообще чудесно (внезапно, тоже не ирония)testopatolog
17.06.2019 01:04Разрешите порекомендовать Вам для общего развития:
Правила русской орфографии и пунктуации: Полный академический справочник / Под ред. В.В. Лопатина. – М., 2011, § 203 в разделе «Прописные буквы в особом стилистическом употреблении», с. 166–167.DrPass
17.06.2019 01:38Вообще, в правилах русской орфографии и пунктуации забыли написать один важный раздел: «Злоупотребление прописными буквами при выделении акцентов на некоторых именах нарицательных». И это даже не ирония.
testopatolog
17.06.2019 02:13Это слишком очевидный, топорный приём, используемый, когда нет аргументов или нечего сказать — переключать внимание на упреки правописания комментариев, уходя от обсуждаемой темы — и особенно смешной, если это делать с умным видом. Сожалею.
DrPass
17.06.2019 02:29А в ваших руках одним комментарием выше этот топорный прием внезапно превращается в тонкую аргументацию, да?
По теме я написал выше. Впрочем, я не питаю особых иллюзий по поводу нашей дискуссии, т.к. судя по вашим рассуждениям и уровню подготовки, вы явно пытаетесь изучать прикладную отрасль, работая при этом в академической среде. И хуже того, пытаетесь ещё и прикладные решения какие-то создавать. Это вообще парадокс наших ВУЗов, когда экономическим наукам учат люди, которые никогда не решали экономические вопросы, а разработке ПО учат те, кто никогда не занимался профессиональной разработкой.
DrPass
17.06.2019 00:57Лучше бы вы не ограничивались философией, а чуть больше времени уделяли математической оптимизации и микроэкономике. В любой экономической/инженерной сфере мы можем найти массу примеров дуализма, и разработка тут не исключение. Вот только нам это никак не поможет принимать решения, какую стратегию разработки выбрать.
И да, правильный ответ: высокое качество ПО стоит затрат на его разработку. Иногда. А иногда не стоит. А иногда оно обязательно. А иногда оно приведет к смерти вашего бизнеса. Поэтому надо изучать текущую ситуацию и принимать решение на основании имеющихся фактов, а не искать серебряную пулю в законах философии.
gBear
16.06.2019 23:04Да запросто :-)
Для *пользователя*, качество продукта — вещь сугубо утилитарная. В том смысле, что он его (это качество) осознает и воспринимает исключительно в области своих *потребностей*. И — отвечая на ваш вопрос — *пользователям*, в общем случае, те вещи, о которых вы пишите, вообще «сугубо фиолетовы».
Хотя, я вполне допускаю, что могу быть пользователи, для которых «регулярная поставка новых фич» и лежит в области их потребности, но, гораздо важнее то, что — в любом случае — эта вещь интересует как раз «менеджмент». По другим, правда, причинам.
И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно. Например, качество процессов на это оказывает несравнимо более сильное влияние.
Я, к своему сожалению, сразу-то не обратил внимание на то, что это перевод Фаулера. Иначе бы сразу читал оригинал, с поправкой на, скажем так, весьма специфический взгляд Мартина на некоторые вещи :-)
Но, в любом случае, его вывод о том, чтоThe «cost» of high internal quality software is negative.
— лично с моей точки зрения — является очень сильным упрощением и весьма слабо связан с теми рассуждениями, которые он приводит в статье.bivo Автор
16.06.2019 23:44Кстати отличный поинт про перевод фразы =]
The «cost» of high internal quality software is negative.
Если есть идеи, как её можно перевести не используя «описательный приём» и не удлинняя предложение в 3 раза — буду премного благодарен и поправлю перевод.
(комментарий написан безотносительно сути и мысли предложения, исключтельно в целях повышения качества перевода)
(для справки) Сейчас переведено так:
Тратить лишние ресурсы на архитектуру и хороший код, с экономической точки зрения, в итоге, оказывается более выгодно.
EvgeniiR
17.06.2019 12:21И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно.
Скорость разработки новых фич с качеством кодовой базы связана самым прямым образом, потому что прежде чем новую фичу интегрировать в проект, нужно прочитать и разобраться с некоторой частью кодовой базы. Причем, чем лучше спроектирована система, тем меньше объём который нужно прочитать и разобрать — всё может свестить к прочтению одного файла на 100 строк с описанием интерфейса взаимодействия в лучшем случае, и к прочтению и изменению десятков файлов в худшем.
Ну а то что количество багов в программе связано исключительно с качеством кода, я думаю очевидно.
P.S. И да, читают код больше чем пишут.
IgorPie
Ответа на вопрос так и не прозвучало.
На свой страх и риск приведу свои жизненные наблюдения:
1. Время — деньги.
2. Популярность — важнее качества. (частный случай: «Легенда — важнее музыки»).
worldmind
Это уже про другое, про то, что в реальном успехе есть большоая доля случая независящая от таких факторов как качество.
DrPass
Потому что правильный ответ на этот вопрос один: бывает по-всякому, смотрите по ситуации.
Иногда нужно из говна и палок быстро решить задачу. Иногда ваш рынок таков, что жизненно важно, чтобы продукт был вылизан и блестел. Иногда хочется второе, но деньги есть только на первое, и выбирать не из чего.