Comments 100
Ответа на вопрос так и не прозвучало.
На свой страх и риск приведу свои жизненные наблюдения:
1. Время — деньги.
2. Популярность — важнее качества. (частный случай: «Легенда — важнее музыки»).
На свой страх и риск приведу свои жизненные наблюдения:
1. Время — деньги.
2. Популярность — важнее качества. (частный случай: «Легенда — важнее музыки»).
Это уже про другое, про то, что в реальном успехе есть большоая доля случая независящая от таких факторов как качество.
Ответа на вопрос так и не прозвучало.
Потому что правильный ответ на этот вопрос один: бывает по-всякому, смотрите по ситуации.
Иногда нужно из говна и палок быстро решить задачу. Иногда ваш рынок таков, что жизненно важно, чтобы продукт был вылизан и блестел. Иногда хочется второе, но деньги есть только на первое, и выбирать не из чего.
В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не примениместь ещё мир бизнеса, в котором, если не выпустить в срок, то можно уже не выпускать (иногда на самом деле, иногда только в воспалённом воображении менеджеров). поэтому и приходится искать компромисс между качеством и сроками (или же компромисс между краткосрочным и долгосрочным).
Про качество уже много написано и оно легко доказуемо.
А вот интересная тема «расширяемость» и «заделки на будущее»
Есть 2 провальных примера:
1. Аутсорсер, который нескольким клиентам делает очень похожие приложения. Но при этом у них есть набор не пересекающихся фитч и у каждого есть «видение» дальнейшего развития продукта (как оказывается дальше это просто фантазии)
У аутсорсера накопилось N лищних баксов и за эти деньги они посадили программистов напилить продукт, который бы удовлетворял требованиям всех клиентов + заделки на будущее
В итоге продукт никто не купил. Может быть продавать не умели, а может быть заказчик не хотел переплачивать за лишние фитчи и туманные перспективы (которые уже из коробки работали)
2. Был запрос от бизнеса — сделать сличение 2-х наборов данных (сейчас пользователи сличают руками, но устали — хотим автоматом)
И тут на пользователей набросилась толпа бизнес аналитиков, которые быстренько нафантазировали огромный и расширяемый продукт, с кучей плюшек и кнопкой «сделать все хорошо». Но сначала основные требования — сделать сверку двух наборов данных.
Разработчики увидев крупные перспективы проекта организовали не малую команду и начали пилить крутой расширяемый продукт с автотестами и блекджеком. В котором сначала будет один отчет, а потом надуманные бизнес аналитиками фитчи будут лепится одна за другой по одному щелчку мыши.
В итоге:
— Пользователь получил свой отчет через польтора года (1.5 года КАРЛ!!! 1.5 года один отчет!!!)
— Ситуация поменялась и пользователь захотел уже другое
— Измененная ситуация никак не ложилась в парадигму «того самого мега продукта» в минималистическом исправлении и требовала либо серьезной переделки продукта либо быстро сделать что-то в сторонке (терпение бизнеса на исходе — выбор очевиден)
Я все к чему: Не думайте что во главе бизнеса сидят дяди, которые видят дальше чем месяц в перед! Делайте качественно, но согласно текущих потребностей бизнеса!!!
А вот интересная тема «расширяемость» и «заделки на будущее»
Есть 2 провальных примера:
1. Аутсорсер, который нескольким клиентам делает очень похожие приложения. Но при этом у них есть набор не пересекающихся фитч и у каждого есть «видение» дальнейшего развития продукта (как оказывается дальше это просто фантазии)
У аутсорсера накопилось N лищних баксов и за эти деньги они посадили программистов напилить продукт, который бы удовлетворял требованиям всех клиентов + заделки на будущее
В итоге продукт никто не купил. Может быть продавать не умели, а может быть заказчик не хотел переплачивать за лишние фитчи и туманные перспективы (которые уже из коробки работали)
2. Был запрос от бизнеса — сделать сличение 2-х наборов данных (сейчас пользователи сличают руками, но устали — хотим автоматом)
И тут на пользователей набросилась толпа бизнес аналитиков, которые быстренько нафантазировали огромный и расширяемый продукт, с кучей плюшек и кнопкой «сделать все хорошо». Но сначала основные требования — сделать сверку двух наборов данных.
Разработчики увидев крупные перспективы проекта организовали не малую команду и начали пилить крутой расширяемый продукт с автотестами и блекджеком. В котором сначала будет один отчет, а потом надуманные бизнес аналитиками фитчи будут лепится одна за другой по одному щелчку мыши.
В итоге:
— Пользователь получил свой отчет через польтора года (1.5 года КАРЛ!!! 1.5 года один отчет!!!)
— Ситуация поменялась и пользователь захотел уже другое
— Измененная ситуация никак не ложилась в парадигму «того самого мега продукта» в минималистическом исправлении и требовала либо серьезной переделки продукта либо быстро сделать что-то в сторонке (терпение бизнеса на исходе — выбор очевиден)
Я все к чему: Не думайте что во главе бизнеса сидят дяди, которые видят дальше чем месяц в перед! Делайте качественно, но согласно текущих потребностей бизнеса!!!
Тут нужно помнить, что Фаулер из мира enterprise. Из того мира, где системы в стадии разработки и поддержки могут существовать годами и десятилетиями, количество строк кода исчисляется сотнями тысяч и миллионами, а писали их сотни и тысячи разных людей.
Для стартапов статья применима меньше, но всё же актуальна.
Когда код хороший и техдолги постепенно вычищаются, разрабатывать быстрее, проще, да и просто фановее.
Багов меньше, фич больше,котики PM'ы довольны :)
Для стартапов статья применима меньше, но всё же актуальна.
Когда код хороший и техдолги постепенно вычищаются, разрабатывать быстрее, проще, да и просто фановее.
Багов меньше, фич больше,
На самом деле в стартапах она применима ничуть не меньше, а иногда и больше. Потому что часто меняющиеся и зачастую противоречивые требования порождают необходимость в гибкой архитектуре. Чтобы можно было выкинуть одну фичу и безболезненно прикрутить на ее место другую. А потом вернуть первую, но на два экрана дальше. Энтерпрайз может планировать продукты годами и выпускать стабильные требования, по которым потом все работают и которые уже предусматривают возможность расширения функциональности в ту или иную сторону. Т.е. «мы делаем приложение расширяемым, потому что у нас есть требование, чтобы оно было расширяемым, и заказчик платит за это в явном виде». В стартапах это выглядит как «мы должны делать приложение расширяемым, хотя нас об этом и не просили, потому что в отсутствие четкого плана непредсказуемые изменения добьют нас через полгода и мы останемся без проекта и без денег вообще».
порождают необходимость в гибкой архитектуре.
По моему опыту как раз с гибкой архитектурой — и с любой другой — в стартапах проблемы. Потому что сколько ни планируй, все равно окажется что в реальности людям нужно совершенно иное. И гибкость, придуманная еще до начала работ, оказывается нерабочей — гибко не там, где в итоге оказывается нужно.
> Единственное отличие заключается в том, что исходный код приложения от Ребекки чётко структурирован и организован, а код, созданный моей командой, представляет из себя беспорядочный набор классов и методов
Значит, вы гораздо раньше выйдите на рынок и начнёте продавать свое приложение, зарабатывать деньги и нанимать ещё программистов, в то время как у Ребекки сырая нерабочая альфа. Дополнительные руки позволят вам заново переписать приложение, при этом продолжая получать деньги за старое. А если вдруг окажется, что приложение никому не нужно — у вас будут мЕньшие потери по расходам, чем у Ребекки. Во всех раскладах — вы останетесь в выигрыше.
> Есть и ещё одно отличие: я продаю своё приложение за $6, а Ребекка продаёт почти такое же приложение за $10.
Никто не запрещает вам продавать ваше приложение по $10, загрести деньги лопатой, нанять +10 программистов на переписывание кода. И никто не запрещает Ребекке пытаться выжать вас с рынка, продавая в убыток для себя по $6. Ведь вы(блин, это же перевод) сами написали, что приложения внешне одинаковые, зачем продавать его дешевле?
Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку и используя её код переходите на него.
Если бюджет Ребекки больше, то захватив рынок вы продаете всю компанию и клиентскую базу — Ребекке, быстро поднимаете деньги, которые зарабатывали бы ещё несколько лет, и начинаете новый перспективный стартап.
Ну и все эти красивые графики не показывают одного важного пункта — когда будет готовое рабочее приложение. Например, у вас это 3 месяца, а у Ребекки 10 лет. Ребекка все равно в выигрыше?
Значит, вы гораздо раньше выйдите на рынок и начнёте продавать свое приложение, зарабатывать деньги и нанимать ещё программистов, в то время как у Ребекки сырая нерабочая альфа. Дополнительные руки позволят вам заново переписать приложение, при этом продолжая получать деньги за старое. А если вдруг окажется, что приложение никому не нужно — у вас будут мЕньшие потери по расходам, чем у Ребекки. Во всех раскладах — вы останетесь в выигрыше.
> Есть и ещё одно отличие: я продаю своё приложение за $6, а Ребекка продаёт почти такое же приложение за $10.
Никто не запрещает вам продавать ваше приложение по $10, загрести деньги лопатой, нанять +10 программистов на переписывание кода. И никто не запрещает Ребекке пытаться выжать вас с рынка, продавая в убыток для себя по $6. Ведь вы(блин, это же перевод) сами написали, что приложения внешне одинаковые, зачем продавать его дешевле?
Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку и используя её код переходите на него.
Если бюджет Ребекки больше, то захватив рынок вы продаете всю компанию и клиентскую базу — Ребекке, быстро поднимаете деньги, которые зарабатывали бы ещё несколько лет, и начинаете новый перспективный стартап.
Ну и все эти красивые графики не показывают одного важного пункта — когда будет готовое рабочее приложение. Например, у вас это 3 месяца, а у Ребекки 10 лет. Ребекка все равно в выигрыше?
UFO just landed and posted this here
А вы готовы платить в 2-3 раза больше за чуть менее глючное ПО?
UFO just landed and posted this here
>А вы готовы платить в 2-3 раза больше за чуть менее глючное ПО?
Фаулер пишет о том что грамотное проектирование как раз таки окупается со временем.
Так с чего пользователю придется платить больше?)
Фаулер пишет о том что грамотное проектирование как раз таки окупается со временем.
Так с чего пользователю придется платить больше?)
Не надо пугать всякими «2-3 раза», это миф. Менее глючное ПО отличается от более глючного не стоимостью разработки, не сроками разработки, а всего лишь культурой разработки. При нормальной организации даже наоборот, стоимость и сроки могут быть меньше, чем у корявых глючных монстров.
Подогнали все условия, чтобы Ребекка проиграла, хотя ничего подобного в статье не было. И альфа у нее сырая, и приложение дороже, и расходы больше, и сроки она затянула, а бюджеты одинаковые. Конечно, Ребекка проиграет, о чем тут говорить вообще?
Прочитайте внимательно — я рассмотрел разные варианты. Когда бюджет у Ребекки больше, она спокойно вытягивает и выкупает конкурента.
Вам уже выше ответили — написание качественного кода и использование best practices не меняет качественно затраты. Конечно, при условии, что вы не пытаетесь внедрить их на проекте, где их невозможно внедрить. Если у вас огромный legacy-монстр, где компонент А зависит от Б, Б от В, В от Г, и все прибито гвоздями, а вы пытаетесь протестить компонент А юнит-тестом — тогда, согласен на 150%, вас ждет боль, много боли, и много затрат, и потеря огромного количества времени. Но причина этого в данном случае не в правильном подходе, который дорог, а в том, что вы не использовали его с самого начала и написали нетестируемое, негибкое, нерасширяемое нечто.
Ну вот совсем не факт, большинство современных технологических лидеров не были первыми. Они были первыми нормальными.
Ну было оно у Yahoo раньше чем у Google, у MySpace раньше чем у Facebook, у Flick раньше чем у Instagram, а толку то?
готовое рабочее приложение.
Ну было оно у Yahoo раньше чем у Google, у MySpace раньше чем у Facebook, у Flick раньше чем у Instagram, а толку то?
Толк в том, что они начали нормально так зарабатывать с этого деньги, и стали жить хорошо, и почти все они могли выкупить конкурента ещё в начале их развития.
Проблема в плохом руководстве и остановке развития проекта — она вообще никакого отношения к качеству кода не имеет.
Проблема в плохом руководстве и остановке развития проекта — она вообще никакого отношения к качеству кода не имеет.
На место выкупленного конкурента всегда может прийти новый, у которого процесс разработки поставлен как надо, и уделает монополиста, потому что он будет быстрее внедрять фичи, выпускать релизы с меньшим количеством багов, легче находить разработчиков в команду и т.п… Такой сценарий тоже возможен, хотя, конечно, надо смотреть на конкретный рынок и конкретный продукт.
Если руководство ставит приоритетом скорость запила новых фич и насаждает культуру пренебрежения к качеству кода (это все теории, а на практике у нас все не так), то это подобно тому, как гонять таксомотор, перевыполняя норму по заказам, но не заботясь о ТО и амортизации. Рано или поздно (скорее рано) таксомотор загнется, и зарабатывать заказами станет не на чем. Метафора кредита в статье тоже очень хороша: не имеет значения, как быстро и как легком вы можете получить новый кредит, если необходимость выплаты прошлых кредитов уже сделала вас банкротом.
Значит, вы гораздо раньше выйдите на рынок и начнёте продавать свое приложение, зарабатывать деньги и нанимать ещё программистов, в то время как у Ребекки сырая нерабочая альфа. Дополнительные руки позволят вам заново переписать приложение, при этом продолжая получать деньги за старое. А если вдруг окажется, что приложение никому не нужно — у вас будут мЕньшие потери по расходам, чем у Ребекки. Во всех раскладах — вы останетесь в выигрыше.
Или у вас спустя несколько месяцев после выхода на рынок будет ужасная нерасширяемая поделка, в которой кнопочки в интерфейсе до сих пор ссылаются на #, а Ребекка как раз выйдет на рынок с удобным приложением и стабильнами поставками нового функционала без багов, и пользователи уйдут к ней.
Если бюджеты у вас с Ребеккой одинаковые, то ей очень сложно развиваться дальше, тк она больше ресурсов тратит на вылизывание кода. То есть: у Вас и у Р. По 10 миллионов. Вы сделали бету и уже тестируете на пользователях, а Ребека за те же деньги только закончила архитектуру и бэкенд. Вам и Ребекке нужны ещё деньги, но вам — чтобы пилить дальше фишки, а Ребекке чтобы закончить то же приложение что у вас уже было. Рано или поздно, вы поглощаете Ребекку
Или, рано или поздно, разработка схожей по объёму фичи у вас начнёт занимать кратно больше времени и денег, а Ребекка продолжит стабильно выкатывать новые фичи укладываясь в бюджет
Раз уж мы под статьёй Фаулера, процитирую его же книжку, абзац написанный в контексте старой басни Эзопа про черепаху и зайца:
Spoiler
Современные разработчики также участвуют в похожей гонке и проявляют
похожую самонадеянность. О нет, они не спят, нет. Многие современные
разработчики работают как проклятые. Но часть их мозга действительно
спит — та часть, которая знает, что хороший, чистый, хорошо проработанный
код играет немаловажную роль.
Эти разработчики верят в известную ложь: «Мы сможем навести порядок потом, нам бы только выйти на рынок!»
В результате порядок так и не наводится, потому что давление конкуренции на рынке никогда не
ослабевает. Выход на рынок означает, что теперь у вас на хвосте висят
конкуренты и вы должны стремиться оставаться впереди них и бежать
вперед изо всех сил.
Поэтому разработчики никогда не переключают режим работы. Они
не могут вернуться и навести порядок, потому что должны реализовать
следующую новую функцию, а потом еще одну, и еще, и еще. В результате
беспорядок нарастает, а продуктивность стремится к своему пределу около
нуля
А вообще, к чему это всё — есть такое понятие как анализ рисков, на основе чего можно принимать решения. Если его нет — в какую крайность не ударяйся, ни к чему хорошему это не приведёт.
Во всех раскладах — вы останетесь в выигрыше.Это так, но только при нескольких условиях:
1. Глючный говнокод получилось довести до состояния «готового» продукта, до состояния когда его начнут покупать
2. У вас действительно получилось написать это поделие заметно быстрее
3. У вас действительно получилось захватить заметную долю рынка пока Ребекка допиливала свой вариант
4. Процесс переделки не занял слишком много времени и вы не потеряли фору которую получили выпустив продукт раньше
5. Пользователи не разочаровались медленным процессом исправления ошибок и допиливания новых фич и не ушли на продукт Ребекки когда он появился вместо того чтобы дожидаться вашей новой идеальной версии. Это скорее 4а впрочем чем самостоятельный 5, но все же.
Эти условия далеко не всегда будут выполняться. Хотя, возможно, что они будут выполняться достаточно часто, статистики у меня конечно же нет.
Практика показывает, что никто не будет переписывать MVP заново, когда он начнет приносить прибыль. Менеджмент будет раз за разом требовать откопать стюардессу вносить изменения в уже работающую версию (ровно по той же причине — написать с нуля занимает время, а фичи нужны вчера), а она на это не рассчитана. Даже если две версии будут развиваться параллельно, это гонка Ахиллеса и черепахи. В итоге деньги они будут терять, потому что фичи пилятся дольше, чем могли бы.
Эта концепция подходит для уже работающего бизнеса. А вот для прощупывания рынка достаточно выкатить quick-n-dirty решение. Но главное быстро. А то время уйдёт и будет поздно. Это не значит, что в быстром решении нужно плевать вообще на все best practices и критерии качества, но чем-то можно поступиться, да.
Такие кривенькие внутри прототипы мы часто показываем на выставках, чтобы привлечь потенциальных клиентов. И пока они раскачаются и доберутся до покупки, мы можем все это по-нормальному запилить в основной продукт.
А если не взлетит, то и не сильно жалко — времени на прототип потрачено относительно немного.
Да, оно внутри кривое-косое, иногда буквально руками приходится поддерживать работоспособность, но оно и предназначено отработать 2-3 дня по 10 часов выставки и уйти на полку.
А если не взлетит, то и не сильно жалко — времени на прототип потрачено относительно немного.
Да, оно внутри кривое-косое, иногда буквально руками приходится поддерживать работоспособность, но оно и предназначено отработать 2-3 дня по 10 часов выставки и уйти на полку.
По сути, это отдельный проект, который только выглядит как реальный, но таковым не является. Иногда хватает презентации мокапов дизайна, даже без реально работающего прототипа.
Было немного страшно в первые 2 раза, когда небрежно накидывал прототип, его показывали заказчику в стиле «смотрите, оно может делать так и так, а ещё мигать лампочкой. Что вы ещё хотите и как часто мигать?», а заказчик говорил «Супер, заверните. Только лампочку на прожектор поменяйте и удалённое управление поставьте, мы от такой штуке 2 года мечтали. Что? Ждать пока перепилите? Некогда, нам и так сойдёт, внедряйте быстрее.»
Поэтому пришлось найти баланс, чтоб прототип не ломался от пролетающих рядом птиц, собирался быстро и при этом, не выглядел как месть команде.
Поэтому пришлось найти баланс, чтоб прототип не ломался от пролетающих рядом птиц, собирался быстро и при этом, не выглядел как месть команде.
Наши заказчики довольно долго раскачиваются, так сложилось. Пока ТЗ, пока пилотный проект, пока поставка пройдет.
Поэтому так можно. Но это для чего-то совсем нового, попонтоваться, а вот смотрите, у нас уже есть, а у всех остальных нет и пока не предвидится.
Застолбить рынок и перетянуть на себя внимание заказчика.
Поэтому так можно. Но это для чего-то совсем нового, попонтоваться, а вот смотрите, у нас уже есть, а у всех остальных нет и пока не предвидится.
Застолбить рынок и перетянуть на себя внимание заказчика.
Про скорость и качество - лучший коммент на хабре на эту тему:
Собственно в этом и суть. Автор статьи пишет
Но он не учитывает несколько ключевых факторов:
Поэтому и имеем то что имеем — выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
Я серьёзно изменил своё отношение к происходящему, когда у меня появился собственный проект с собственными всамделишными клиентами. И, на самом деле, если вот прямо здесь и сейчас надо подпереть стенку бомбой с часовым механизмом, за неимением ничего другого подходящего по размеру и весу, надо брать и подпирать — потому что иначе завтра вся конструкция потеряет свой смысл. Да, потом надо будет если не заменить бомбу, например, мешком с гантелями (наивно считать, что теперь туда влезет что-то стандартное без перестройки половины фундамента), то хотя бы перерезать провода таймера и, по возможности, выкрутить взрыватель и поставить пару тройку табличек «НЕ ТРОГАЙ!» для потомков. Но это всё потом, а сейчас — не с менеджером, а с разъярённым живым человеком на проводе и пальцами на клавиатуре надо очень быстро решить проблему любым доступным способом.
Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики.
Собственно в этом и суть. Автор статьи пишет
Наши с Ребеккой приложения выглядят сейчас почти одинаковыми, но через несколько месяцев высокое качество кода Ребекки позволит ей выпускать каждую неделю по новой фиче, а я застряну на месте, стараясь справиться с техдолгом и пытаясь запустить хотя бы одну новую фичу. Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки, несмотря на то, что оно стоит дороже.
Но он не учитывает несколько ключевых факторов:
- Приложение Ребекки может банально не прожить несколько месяцев чтобы выйти вперед по качеству фич — так как всех пользователей уже собрал автор. В итоге ее стартап обанкротится, закроется и будет выкуплен автором, нахватавшим денег своим кривым-косым, но вышедшим раньше приложением
- Люди консервативны. К тому моменту как Ребекка выпустит свое отлаженное приложение на рынок, у приложения автора уже будет обширная пользовательская база и коммьюнити, которые уже не будут гореть желанием менять знакомое (пусть и не самое лучшее) на что-то новое и непривычное
Поэтому и имеем то что имеем — выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
Уже несколько раз на этой странице упоминают проекты, которые «выходят на новые рынки» и захватывают их. И если не зарелизился за месяц — все, поезд ушел, другие уже заняли нишу. А можно конкретные примеры?
Вот Wandex был первой поисковой системой. По вашей логике, он должен был занять рынок, а все остальные остались бы в пролете. Но почему-то рынок занял другой поисковик.
В России тоже самое — когда-то топ-1 поисковиком и сайтом был Рамблер, а где он сейчас?
Фейсбук так же не был первой социальной сетью.
На моей практике, все слова о том, что «Надо зарелизиться как можно скорее, иначе поезд уедет», отражают только капризные хотелки менеджмента, которым хочется побыстрее. И больше ничего.
Вы забываете о том, что после захвата рынка у вас, скорее всего, не будет уже ни времени, ни денег на его исправление. Будут другие задачи и другие затраты. И для их реализации вам придется говнокодить дальше, потому что архитектура обязывает. Ком технического долга будет только расти и расти, разработка новых фич будет становиться сложнее и сложнее, цена ошибочных решений все выше и выше, пока ваш проект не загниет окончательно.
Но он не учитывает несколько ключевых факторов:
Приложение Ребекки может банально не прожить несколько месяцев чтобы выйти вперед по качеству фич — так как всех пользователей уже собрал автор.
Поэтому и имеем то что имеем — выгоднее наговнокодить сейчас, продать, захватить рынок, а потом уже исправлять.
Лихо вы, однако, сначала высказываете предположение(«может банально не прожить»), а потом строите утверждение так, будто предположение доказано и уже превратилось превратилось в 100%-ную истину.
Люди консервативны. К тому моменту как Ребекка выпустит свое отлаженное приложение на рынок, у приложения автора уже будет обширная пользовательская база и коммьюнити, которые уже не будут гореть желанием менять знакомое (пусть и не самое лучшее) на что-то новое и непривычное
Тем не менее, живут ведь как-то новые соц. сети, месседжеры и т.п., и далеко не все «первые» продукты в популярных нынче сферах до текущего дня дожили в принципе.
И много сейчас новых соцсетей и мессенджеров?
У тех же мессенджеров мы видели смену пальмы первенства из-за полного и абсолютного продалбывания всех полимеров старым чемпионом. Как ICQ потеряла лидерство и уступило скайпу, как скайп продолбал все вотсапу — это совершенно эпичные, но разовые истории. И опять же тут ни при чем особо архитектура и красота кода, скорее новые фичи и изначально новый подход.
В то же время вон даже на хабре были статьи про какие-то новые мессенджеры, с идеальной структурой и стандартами, продуманные и т.п., но нафиг никому не нужные. Потому что у них нет киллер фич, а к переделу рынка они уже опоздали.
У тех же мессенджеров мы видели смену пальмы первенства из-за полного и абсолютного продалбывания всех полимеров старым чемпионом. Как ICQ потеряла лидерство и уступило скайпу, как скайп продолбал все вотсапу — это совершенно эпичные, но разовые истории. И опять же тут ни при чем особо архитектура и красота кода, скорее новые фичи и изначально новый подход.
В то же время вон даже на хабре были статьи про какие-то новые мессенджеры, с идеальной структурой и стандартами, продуманные и т.п., но нафиг никому не нужные. Потому что у них нет киллер фич, а к переделу рынка они уже опоздали.
«На любой заголовок, который заканчивается вопросительным знаком, можно ответить словом нет».
Попробуем:
— Что важнее в разработке ПО: скорость или качество?
— Нет.
Превосходно.
На тему холивара «Качество vs Скорость» бывшие коллеги замутили целый рэп-батл: youtu.be/L19wvjOcW9E
Попробуем:
— Что важнее в разработке ПО: скорость или качество?
— Нет.
Превосходно.
На тему холивара «Качество vs Скорость» бывшие коллеги замутили целый рэп-батл: youtu.be/L19wvjOcW9E
Статья вышла какая-то непонятная.
С одной стороны автор постоянно утверждает что качество того стоит, с другой стороны не было представлено ни одного внятного обоснования этого утверждения. А просто описано несколько историй которые не подтверждают и не опровергают весьма спорное утверждение.
Еще хотелось бы обратить внимание что задачи решаемые разработчиками ооочень разнообразны.
Кейс №1. Есть конторы которые делают плагины для чего-то и это их основной вид деятельности. Они изначально не выбирают архитектуру, но обычно у них есть некий свод правил или стандартов которым они обязаны следовать чтобы удовлетворять требованиям материнского продукта (WordPress, 1C, Jira, Github, Jenkins, Apache и проч.)
Кейс №2. Предположим что контора занимается разработкой софта для спутника для какой-либо космической программы. Конечно инженерам бы хотелось верить и разрабатывать с учетом перспективы. Но на практике скорость разработки, внедрения и запуска таких систем показывает, что заказчик хочет решение на 100% отвечающее сегодняшним требованиям. И его до достаточно объективным причинам абсолютно не интересует будет ли это решение кроссплатформенным или масштабируемым или будет ли оно работать на следующем поколении процессоров и как оно себя поведет если… Заказчика не интересует увеличение производительности в N раз просто потому что система не предполагает никаких скачкообразных нагрузок.
Кейс №3 Есть задача создать сайт, скажем блог или социальную сеть. Соответственно есть 2 варианта: взять уже готовое и обкатанное решение или начать писать с нуля с правильной и кастомизированной под себя архитектурой. Первый вариант однозначно дешевле и первый вариант системы будет готов в разы или десятки раз быстрее. Второй вариант «правильнее» и чище и «качественнее» в долгосрочной перспективе, потому что любой устоявшийся продукт на рынке всегда имеет свои ограничения и помимо фич свои баги и уязвимости, а написанный с нуля под наши нужды теоретически может учитывать все известные проблемы существующих аналогов.
Мне кажется я могу продолжать довольно долго. Моя позиция состоит в том, что я согласен с автором по основному утверждению:
Но не согласен с его попыткой аргументировать в пользу:
Этот компромисс и принцип вполне применим. Просто всегда надо рассматривать конкретный проект и решаемую задачу. Именно от задачи зависит чем мы можем пожертвовать, а чем не можем.
В каких-то ситуациях можно обойтись без тестирования (как фазы) вообще и положиться на то что «оно же работает». А в каких-то надо стать практически параноиком и изобретать тесты на все возможные и невозможные сценарии.
В каких-то ситуациях можно и нужно использовать типовые решения, а в каких-то надо писать систему с нуля с минимумом зависимостей.
Опять же размер и качество команды тоже накладывает свой отпечаток на конечный продукт и от этого нельзя просто отмахнуться. Код после какого-нибудь реального гения разработки который заложил архитектуру на десятилетия вперед потом кто-то должен поддерживать и этот кто-то иногда может за неделю или месяц не разобраться что там к чему и где заканчивается одна абстракция и начинается другая. Люди приходят и уходят, а проект остается.
С одной стороны автор постоянно утверждает что качество того стоит, с другой стороны не было представлено ни одного внятного обоснования этого утверждения. А просто описано несколько историй которые не подтверждают и не опровергают весьма спорное утверждение.
Еще хотелось бы обратить внимание что задачи решаемые разработчиками ооочень разнообразны.
Кейс №1. Есть конторы которые делают плагины для чего-то и это их основной вид деятельности. Они изначально не выбирают архитектуру, но обычно у них есть некий свод правил или стандартов которым они обязаны следовать чтобы удовлетворять требованиям материнского продукта (WordPress, 1C, Jira, Github, Jenkins, Apache и проч.)
Кейс №2. Предположим что контора занимается разработкой софта для спутника для какой-либо космической программы. Конечно инженерам бы хотелось верить и разрабатывать с учетом перспективы. Но на практике скорость разработки, внедрения и запуска таких систем показывает, что заказчик хочет решение на 100% отвечающее сегодняшним требованиям. И его до достаточно объективным причинам абсолютно не интересует будет ли это решение кроссплатформенным или масштабируемым или будет ли оно работать на следующем поколении процессоров и как оно себя поведет если… Заказчика не интересует увеличение производительности в N раз просто потому что система не предполагает никаких скачкообразных нагрузок.
Кейс №3 Есть задача создать сайт, скажем блог или социальную сеть. Соответственно есть 2 варианта: взять уже готовое и обкатанное решение или начать писать с нуля с правильной и кастомизированной под себя архитектурой. Первый вариант однозначно дешевле и первый вариант системы будет готов в разы или десятки раз быстрее. Второй вариант «правильнее» и чище и «качественнее» в долгосрочной перспективе, потому что любой устоявшийся продукт на рынке всегда имеет свои ограничения и помимо фич свои баги и уязвимости, а написанный с нуля под наши нужды теоретически может учитывать все известные проблемы существующих аналогов.
Мне кажется я могу продолжать довольно долго. Моя позиция состоит в том, что я согласен с автором по основному утверждению:
что постановка вопроса из заголовка этой статьи просто не имеет смысла
Но не согласен с его попыткой аргументировать в пользу:
что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.
Этот компромисс и принцип вполне применим. Просто всегда надо рассматривать конкретный проект и решаемую задачу. Именно от задачи зависит чем мы можем пожертвовать, а чем не можем.
В каких-то ситуациях можно обойтись без тестирования (как фазы) вообще и положиться на то что «оно же работает». А в каких-то надо стать практически параноиком и изобретать тесты на все возможные и невозможные сценарии.
В каких-то ситуациях можно и нужно использовать типовые решения, а в каких-то надо писать систему с нуля с минимумом зависимостей.
Опять же размер и качество команды тоже накладывает свой отпечаток на конечный продукт и от этого нельзя просто отмахнуться. Код после какого-нибудь реального гения разработки который заложил архитектуру на десятилетия вперед потом кто-то должен поддерживать и этот кто-то иногда может за неделю или месяц не разобраться что там к чему и где заканчивается одна абстракция и начинается другая. Люди приходят и уходят, а проект остается.
В общем автор не разобрался в рыночной экономике. Для рассейских коллег это вполне понятно, многие — выходцы из СССР, а некоторые — жертвы ЕГЭ. Но западенец-то что-ж такой безграмотный?
Вот он пишет:
>> Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки
Эту фразу выше уже откомментировали, но несколько огульно. На самом деле необходимо указать нишу, в которой предложенный западным автором подход всё-таки будет работать. И эта ниша очень узкая.
Подход будет работать в конкурентной среде для пары фирм с серьёзными финансовыми возможностями. То есть конкуренция не даст банально пользоваться монополистическим положением, а крупные финансовые средства дадут возможность вкладываться в долгую. Вот только тогда из идеи что-то выйдет. Во всех же остальных случаях идея нереализуема. Причины уже перечислены в комментариях выше. Главное — действуют много дополнительных факторов, которые нивелируют разницу в качестве ПО. Поэтому (если помечтать) некий второй гугл мог бы вложиться сегодня во второй ведроид и сделать его намного лучше, но реальность такова, что рынок ОС для мобилок весьма убогий, контролируется устоявшимися монополистами, а инвесторы совершенно не готовы просто поверить неким программистам, мол они сделают что-то лучше и только за счёт этого всё взлетит.
В общем ситуация из статьи как минимум редка. Где в мире есть конкурентный рынок с равными финансовыми возможностями для участников и готовностью топов слушать программистов?
Хотя вот тот же «телеграм» вполне взлетел. Не знаю на счёт качества нутра, но снаружи выглядит неплохо, фичи добавляются, вышел на рынок много позже конкурентов. Но за счёт чего вышел? Это вопрос. Большие деньги там точно были, но на что их тратили? На архитектуру или на рекламу? В общем знаю лишь отдалённо напоминающие предложенный в статье варианты, но не уверен в качестве кода. Может кто-то лично что-то внутри ковырял? Хотя бы качество выставленного API может оценить?
Вот он пишет:
>> Я не смогу конкурировать с Ребеккой по скорости развития, и её приложение быстро обгонит моё по функциональности. В конечном счёте пользователи удалят моё приложение и будут пользоваться приложением Ребекки
Эту фразу выше уже откомментировали, но несколько огульно. На самом деле необходимо указать нишу, в которой предложенный западным автором подход всё-таки будет работать. И эта ниша очень узкая.
Подход будет работать в конкурентной среде для пары фирм с серьёзными финансовыми возможностями. То есть конкуренция не даст банально пользоваться монополистическим положением, а крупные финансовые средства дадут возможность вкладываться в долгую. Вот только тогда из идеи что-то выйдет. Во всех же остальных случаях идея нереализуема. Причины уже перечислены в комментариях выше. Главное — действуют много дополнительных факторов, которые нивелируют разницу в качестве ПО. Поэтому (если помечтать) некий второй гугл мог бы вложиться сегодня во второй ведроид и сделать его намного лучше, но реальность такова, что рынок ОС для мобилок весьма убогий, контролируется устоявшимися монополистами, а инвесторы совершенно не готовы просто поверить неким программистам, мол они сделают что-то лучше и только за счёт этого всё взлетит.
В общем ситуация из статьи как минимум редка. Где в мире есть конкурентный рынок с равными финансовыми возможностями для участников и готовностью топов слушать программистов?
Хотя вот тот же «телеграм» вполне взлетел. Не знаю на счёт качества нутра, но снаружи выглядит неплохо, фичи добавляются, вышел на рынок много позже конкурентов. Но за счёт чего вышел? Это вопрос. Большие деньги там точно были, но на что их тратили? На архитектуру или на рекламу? В общем знаю лишь отдалённо напоминающие предложенный в статье варианты, но не уверен в качестве кода. Может кто-то лично что-то внутри ковырял? Хотя бы качество выставленного API может оценить?
В общем автор не разобрался в рыночной экономике. Для рассейских коллег это вполне понятно, многие — выходцы из СССР, а некоторые — жертвы ЕГЭ. Но западенец-то что-ж такой безграмотный?
Как мне кажется,
В таком случае, вера в «законы рынка», который сам все решит наилучшим образом, ближе к религиозным воззрениям, а не научным теориям. Вот он и не питает иллюзий на этот этот счет.
В общем ситуация из статьи как минимум редка. Где в мире есть конкурентный рынок с равными финансовыми возможностями для участников и готовностью топов слушать программистов?
Если не касаться всяких хобби проектов, а рассматривать более-менее нормальный бизнес, то эта ситуация не сильно редка. Обычно, если бизнесу нужно проверить гипотезу, то они делают MVP, это и быстро, и значительно дешевле. Если идея стреляет, пишут, по большей части, заново, на основе и с учетом результатов MVP.
Этапы развития полноценного продукта уже планируют с учетом влияние «внутреннего качества ПО», так как это ощутимо будет влиять на скорость и стоимость разработки в долгосрок.
У такого продукта есть шансы получить хороший результат, который сможет приносить прибыль и быть конкурентноспособным.
Если MVP с низким «внутренним качеством» начинают развивать и насыщать фичами, забив на проблемы архитектуры, то такой продукт достаточно быстро приходит в негодность и экспоненциально увеличивает стоимость своего обслуживания. Успех такого продукта будет зависеть только от мастерства продажников, сколько они смогут продать этого «товара», пока он не протухнет окончательно.
Хотя вот тот же «телеграм» вполне взлетел. Не знаю на счёт качества нутра, но снаружи выглядит неплохо, фичи добавляются, вышел на рынок много позже конкурентов. Но за счёт чего вышел?
У них нутро закрытое, поэтому навряд ли кто-то ответит на этот вопрос в контексте качества ПО.
>> дело в том, что он понимает, что не наступило еще на планете этой «рыночной экономики»
Нет, это просто технарь, он не знает, что такое экономика, не то что рынок. Самая обычная для технарей ситуация.
>> то эта ситуация не сильно редка
И где же примеры? Я вот вижу постоянное ухудшение. Ожидания пользователей банально игнорируются. Но как это возможно? Да очень просто — рынок монополизирован. Возьмите например браузеры — они в принципе не настраиваемы. То есть теоретически можно попытаться, но сам набор настроек просто крошечный. А казалось бы — вот поляна для бизнеса, вложился в хороший браузер и окучивай миллиарды пользователей. Но нет там никакой конкуренции, даже если «рассматривать более-менее нормальный бизнес».
>> если бизнесу нужно проверить гипотезу, то они делают MVP
Один делает, а десять других покупают готовую основу у тех же хобби или неудачных стартапов. Бизнес склонен сильно экономить деньги, а потому mvp сделают лишь если это стоит <1% от R&D бюджета. А вот покупка, помимо собственно продукта, даёт ещё и возможность перепродажи если что не так.
>> Этапы развития полноценного продукта уже планируют с учетом влияние «внутреннего качества ПО»
Это вы откуда взяли? В одном единственном случае на планете наблюдали? И да, это «учёт влияния» как вычисляется? И кем? Вы в деталях-то хоть немного разбирались? Или ляпнули первый рекламный текст «за всё хорошее»?
>> У такого продукта есть шансы получить хороший результат
Ну да, в точности по какой-то модной книжке — обтекаемо и абсолютно бездоказательно. Ведь кто может поспорить — теоретически у всего на свете «есть шанс».
>> Если MVP с низким «внутренним качеством» начинают развивать и насыщать фичами…
Купленное гуано обычно как раз «с низким «внутренним качеством»», а насыщать фичами надо, потому что покупали для некой ниши, для которой определили нужный набор фич, а в купленном этого нет.
Повторюсь — mvp по большей части ваша фантазия (ну или из рекламной книжки). Идеи отрабатывают на хобби да стартапах, а потом покупают, либо инвестируют. Хотя может покажете известный пример, выстреливший именно по методике mvp? Но сомневаюсь. А вот купленных да проинвестированных совсем не mvp — огромное количество.
Нет, это просто технарь, он не знает, что такое экономика, не то что рынок. Самая обычная для технарей ситуация.
>> то эта ситуация не сильно редка
И где же примеры? Я вот вижу постоянное ухудшение. Ожидания пользователей банально игнорируются. Но как это возможно? Да очень просто — рынок монополизирован. Возьмите например браузеры — они в принципе не настраиваемы. То есть теоретически можно попытаться, но сам набор настроек просто крошечный. А казалось бы — вот поляна для бизнеса, вложился в хороший браузер и окучивай миллиарды пользователей. Но нет там никакой конкуренции, даже если «рассматривать более-менее нормальный бизнес».
>> если бизнесу нужно проверить гипотезу, то они делают MVP
Один делает, а десять других покупают готовую основу у тех же хобби или неудачных стартапов. Бизнес склонен сильно экономить деньги, а потому mvp сделают лишь если это стоит <1% от R&D бюджета. А вот покупка, помимо собственно продукта, даёт ещё и возможность перепродажи если что не так.
>> Этапы развития полноценного продукта уже планируют с учетом влияние «внутреннего качества ПО»
Это вы откуда взяли? В одном единственном случае на планете наблюдали? И да, это «учёт влияния» как вычисляется? И кем? Вы в деталях-то хоть немного разбирались? Или ляпнули первый рекламный текст «за всё хорошее»?
>> У такого продукта есть шансы получить хороший результат
Ну да, в точности по какой-то модной книжке — обтекаемо и абсолютно бездоказательно. Ведь кто может поспорить — теоретически у всего на свете «есть шанс».
>> Если MVP с низким «внутренним качеством» начинают развивать и насыщать фичами…
Купленное гуано обычно как раз «с низким «внутренним качеством»», а насыщать фичами надо, потому что покупали для некой ниши, для которой определили нужный набор фич, а в купленном этого нет.
Повторюсь — mvp по большей части ваша фантазия (ну или из рекламной книжки). Идеи отрабатывают на хобби да стартапах, а потом покупают, либо инвестируют. Хотя может покажете известный пример, выстреливший именно по методике mvp? Но сомневаюсь. А вот купленных да проинвестированных совсем не mvp — огромное количество.
Бизнес склонен сильно экономить деньги, а потому mvp сделают лишь если это стоит <1% от R&D бюджета.
А это данные какой-то статистики или вы тоже ляпнули какую-то чепуху с потолка?
Говорить про этап MVP, что это рекламный булшит и он не работает, это бредятина чистой воды. Customer Development сложно представить без MVP или его подобия. CustDev тоже не делается никогда?
То что вы описали, вкладываться в стартапы, которые на 95% это очковтирательство и поедание бабок инвестора до очередного раунда, не есть модель успешного выхода на рынок. Это слишком примитивно.
На счет того, что рынок монополизирован, согласен, это есть, и во многих сферах приводит к отсутствую конкуренции и нездоровым тенденциям.
Я не ради спора написал свой комментарий, а потому что считаю мнение автора недалеким от реальности.
>> А это данные какой-то статистики или вы тоже ляпнули какую-то чепуху с потолка?
Это из личного опыта, наблюдений. Более или менее известные продукты в основном перекупались у их авторов (небольших фирм).
>> Говорить про этап MVP, что это рекламный булшит и он не работает, это бредятина чистой воды.
Я не говорил «не работает», но точно, что работает крайне редко. Выкидывать прототип мало кто решается, потому что считают, что дорого. А на уровне больших контор — покупают, а не прототипируют.
>> вкладываться в стартапы, которые на 95% это очковтирательство и поедание бабок инвестора до очередного раунда, не есть модель успешного выхода на рынок
Ну вам виднее, только капитализация некоторых из подобных стартапов сегодня под пол триллиона долларов. А так — да, многие дадут убытки. Но пример всяческих фэйсбуков у вас перед глазами. Но глаза смотрят куда-то не туда. Вы про какой-то малый бизнес поди? Но там как раз очень мало денег, а потому очень сложно обеспечить вложение в долгую. А там, где денег много — тупо покупают готовое. Почти все известные фэйсбуки — результат именно таких инвестиций.
>> Я не ради спора написал свой комментарий, а потому что считаю мнение автора недалеким от реальности.
Ну так в этом суть — далеко или не далеко. И я считаю, что далеко. Назовёте пример конкурентной среды, где есть деньги и их вкладывают в качество? Что-то я кроме не совсем понятного старта телеграма ничего более и вспомнить-то не могу. То есть я реально не вижу подтверждений вашей уверенности. Просто не вижу. Но вы можете показать пример.
Это из личного опыта, наблюдений. Более или менее известные продукты в основном перекупались у их авторов (небольших фирм).
>> Говорить про этап MVP, что это рекламный булшит и он не работает, это бредятина чистой воды.
Я не говорил «не работает», но точно, что работает крайне редко. Выкидывать прототип мало кто решается, потому что считают, что дорого. А на уровне больших контор — покупают, а не прототипируют.
>> вкладываться в стартапы, которые на 95% это очковтирательство и поедание бабок инвестора до очередного раунда, не есть модель успешного выхода на рынок
Ну вам виднее, только капитализация некоторых из подобных стартапов сегодня под пол триллиона долларов. А так — да, многие дадут убытки. Но пример всяческих фэйсбуков у вас перед глазами. Но глаза смотрят куда-то не туда. Вы про какой-то малый бизнес поди? Но там как раз очень мало денег, а потому очень сложно обеспечить вложение в долгую. А там, где денег много — тупо покупают готовое. Почти все известные фэйсбуки — результат именно таких инвестиций.
>> Я не ради спора написал свой комментарий, а потому что считаю мнение автора недалеким от реальности.
Ну так в этом суть — далеко или не далеко. И я считаю, что далеко. Назовёте пример конкурентной среды, где есть деньги и их вкладывают в качество? Что-то я кроме не совсем понятного старта телеграма ничего более и вспомнить-то не могу. То есть я реально не вижу подтверждений вашей уверенности. Просто не вижу. Но вы можете показать пример.
Современный рынок похож на стаю птиц: Налетели, погалдели, оставили после себя кучу, сами понимаете чего и полетели в другое место. Кто-то приходит с лопатой и из этого бесполезного делает удобрение для своего садика.
И практически все сосредоточены на фичах, живой пример ядро линукса. Хорошо это или плохо не знаю но оправдало себя. БСД тихо умер. А вот Windows живет и здравствует. Как впрочем и андроид.
И практически все сосредоточены на фичах, живой пример ядро линукса. Хорошо это или плохо не знаю но оправдало себя. БСД тихо умер. А вот Windows живет и здравствует. Как впрочем и андроид.
Согласен со статьей, обычно выбирают тактический выигрыш, но получают стратегический проигрыш. Экономят сегодня, чтобы потратить гораздо больше завтра.
По моему скромному опыту могу сказать, что написание качественного кода отнюдь не настолько сильно отличается от говнокода по затратам времени и денег. Тесты экономят время на отладке и сильно ускоряют саму разработку. Создание абстракций, продумывание контрактов и DI практически ничего не стоят, но повышают тестируемость и снижают зацепление частей системы, что сильно увеличивает скорость внедрения новых фич.
И наоборот, затраты на перелопачивание говнокода обычно очень сильно недооцениваются:
В общем, чаще всего причины ситуации — обычные лень, невежество и неуважение к времени других разработчиков и деньгам работодателя, а вовсе не радение об экономии или поиск компромисса. Компромисс можно искать, если вы знаете и понимаете альтернативы. Если вы умеете писать только говнокод и не понимаете плюсы и минусы альтернативных подходов — не надо искать себе и своему продукту оправданий.
По моему скромному опыту могу сказать, что написание качественного кода отнюдь не настолько сильно отличается от говнокода по затратам времени и денег. Тесты экономят время на отладке и сильно ускоряют саму разработку. Создание абстракций, продумывание контрактов и DI практически ничего не стоят, но повышают тестируемость и снижают зацепление частей системы, что сильно увеличивает скорость внедрения новых фич.
И наоборот, затраты на перелопачивание говнокода обычно очень сильно недооцениваются:
- во-первых, это чаще всего делают не те, кто этот говнокод написал, да и кто признается, что написал Big Ball of Mud, который проще переписать с нуля, чем переделать?
- во-вторых, работа с легаси — непрестижный и неблагодарный труд, об этом статьи обычно не пишут; книг про работу с legacy — раз-два, и обчелся, зато про новые технологии выходят каждый месяц по несколько;
- при перелопачивании плохого кода никакой ценности для пользователей в продукт не добавляется, это чистые расходы времени команды и денег фирмы;
- затраты на переписывание обычно выше, чем на то, чтобы сразу сделать хорошо: приходится думать об обратной совместимости (не сломать API, оставить тот же UX и т.п.) и исправлять возникающие регрессии; надо ли говорить, что раз на тестах сэкономили, то значит, баги можно выловить только ручным тестированием или на продакшне?
В общем, чаще всего причины ситуации — обычные лень, невежество и неуважение к времени других разработчиков и деньгам работодателя, а вовсе не радение об экономии или поиск компромисса. Компромисс можно искать, если вы знаете и понимаете альтернативы. Если вы умеете писать только говнокод и не понимаете плюсы и минусы альтернативных подходов — не надо искать себе и своему продукту оправданий.
Очень верно отмечено. Я бы добавил еще одну возможную причину: сам бизнес, который осознанно требуют минимизировать этап проектирования и делать продукт, который можно показать быстро уже сейчас. Торопыги-дилетанты.
книг про работу с legacy — раз-два, и обчелся
Одной книги типа такой примерно достаточно: www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
Можно сделать быстро, но плохо, а можно — медленно, но хорошо. Через некоторое время все забудут, что было быстро, но будут помнить, что было плохо. И наоборот.
C. П. Королев
C. П. Королев
Полагаю, что качественно просто не умеет рынок делать… Мало таких специалистов.
Аргумент "давайте сделаем быстро, плохо и заработаем денег быстрее" совершенно понятен! Но, меня никто никогда не сможет заставить сделать плохо, я вот не умею так… Пускай так и будет. Каждый должен занять свое место!
Есть еще часто неосознаваемая некомпетентность, сталкивался на своем собственном опыте множество раз. Это когда смотришь на код, написанный тобой же год назад, и понимаешь, что так больше не пишешь, никогда писать не будешь, а если увидишь у кого-то из коллег — объяснишь, почему так писать нельзя. А ведь год назад считал, что крут, и гордился этим кодом, вот поди ж ты.
UFO just landed and posted this here
UFO just landed and posted this here
Это полезная модель для лабы по эконометрике, но она никакого отношения не имеет к выпуску и продажам ПО в реальной жизни. Хотя бы потому, что
а) объективная стоимость разработки — параметр в общем случае неизвестный, и есть лишь его приближенные оценки, кроме того, это даже не одно число, а функция, меняющаяся в широком диапазоне в зависимости от массы других параметров.
б) у пользователя в общем случае нет никакой субъективной выражаемой численно оценки, по крайней мере, на основе «Качества» продукта. Популярность продукта основывается не столько на его функционале, сколько на его маркетинге, на его доступности, на его соответствии ожиданиям и т.д.
а) объективная стоимость разработки — параметр в общем случае неизвестный, и есть лишь его приближенные оценки, кроме того, это даже не одно число, а функция, меняющаяся в широком диапазоне в зависимости от массы других параметров.
б) у пользователя в общем случае нет никакой субъективной выражаемой численно оценки, по крайней мере, на основе «Качества» продукта. Популярность продукта основывается не столько на его функционале, сколько на его маркетинге, на его доступности, на его соответствии ожиданиям и т.д.
UFO just landed and posted this here
Вы, если честно, смешиваете в одну кучу разные понятия.
Что такое «договор купли-продажи готового ПО»? Это покупка коробочной версии у поставщика ПО? Это покупка ПО, написанного под заказ для конкретного покупателя? Это покупка ПО индивидуальным потребителем по публичной оферте на массовом маркете? Стоимость разработки коррелирует с ценой продажи во втором варианте (и то, только если речь идет не об отечественном рынке индивидуальной энтерпрайз-разработки). Но этот вариант значительно уступает первому и третьему по объему продаж. При этом в первом варианте нередко заложены сверхприбыли, а в третьем нередко продажи и в минус идут. При этом отношения на этом рынке, извините за каламбур, не слишком рыночные.
Ок, значит, вы в вашей модели не указали рамки её применимости. Что она подходит, но лишь для описания ценообразования для 0.01% доли рынка ПО.
Что такое «договор купли-продажи готового ПО»? Это покупка коробочной версии у поставщика ПО? Это покупка ПО, написанного под заказ для конкретного покупателя? Это покупка ПО индивидуальным потребителем по публичной оферте на массовом маркете? Стоимость разработки коррелирует с ценой продажи во втором варианте (и то, только если речь идет не об отечественном рынке индивидуальной энтерпрайз-разработки). Но этот вариант значительно уступает первому и третьему по объему продаж. При этом в первом варианте нередко заложены сверхприбыли, а в третьем нередко продажи и в минус идут. При этом отношения на этом рынке, извините за каламбур, не слишком рыночные.
б) Грамотные пользователи-Организации проводят серьёзный многосторонний анализ с интеграционной оценкой выбора планируемого к приобретению стороннего ПО требуемого качества,
Ок, значит, вы в вашей модели не указали рамки её применимости. Что она подходит, но лишь для описания ценообразования для 0.01% доли рынка ПО.
UFO just landed and posted this here
Кажется я понял, что Вы не совсем понимаете, что такое «объективная стоимость разработки», поясню
Как я могу понимать, если это определение вы сами придумали и сами используете :)
Я считаю его лишним. Есть общепринятое понятие «равновесная цена», которое используется в том смысле, в котором вы выше пытаетесь применить эту «объективную стоимость разработки». Но эта самая равновесная цена имеет смысл только для рынков, приближенных к рынкам свободной конкуренции. Рынок ПО многогранен, имеет массу секторов с разными правилами, и правила рынка свободной конкуренции там действуют лишь на некоторых из них, в частности, на онлайновых маркетах мобильного ПО, и то не в полной мере, т.к. там активно вмешиваются регуляторы.
UFO just landed and posted this here
Исходя из этого определения вы приравниваете термин «объективная стоимость» к общепринятому и устоявшемуся «рыночная стоимость».
Для меня как человека обыкновенного и понимающего современный русский язык, было бы в разы понятнее если бы вы сразу и использовали термин «рыночная цена» или «рыночная стоимость».
А вот термин «объективная стоимость разработки» звучит для мен почти противоположно по смыслу. Несмотря и, даже получается, вопреки, вашему приведенному определению, исходя из моего понимания норм русского языка и контекста, я бы связал термин «объективная стоимость разработки» скорее с «совокупной себестоимостью затрат необходимых для разработки», с учетом некоего набора лимитирующих критериев, которые позволят говорить о заявленной объективности.
Но исходя из вашего определения продолжение дискуссии для меня не имеет смысла, поскольку на лицо явная подмена понятий и жонглирование терминами, за которой непонятны ни утверждение само по себе, ни контраргументы оппонента.
Для меня как человека обыкновенного и понимающего современный русский язык, было бы в разы понятнее если бы вы сразу и использовали термин «рыночная цена» или «рыночная стоимость».
А вот термин «объективная стоимость разработки» звучит для мен почти противоположно по смыслу. Несмотря и, даже получается, вопреки, вашему приведенному определению, исходя из моего понимания норм русского языка и контекста, я бы связал термин «объективная стоимость разработки» скорее с «совокупной себестоимостью затрат необходимых для разработки», с учетом некоего набора лимитирующих критериев, которые позволят говорить о заявленной объективности.
Но исходя из вашего определения продолжение дискуссии для меня не имеет смысла, поскольку на лицо явная подмена понятий и жонглирование терминами, за которой непонятны ни утверждение само по себе, ни контраргументы оппонента.
Живой пример Microsoft. Там код сразу никто не вылизывает, а сразу кидают в production. Потом годами заплатки делают. И ничего себе безбедно живут уже много лет. Такая стратегия себя оправдывает, как мы видим. Остальное все теории.
Вот не надо про Microsoft. У них как раз до недавнего времени был очень строгий контроль качества, и по отношению количества багов к сложности ПО их не в чем упрекнуть. Сейчас да, невооруженным взглядом можно заметить ухудшение. Но как это скажется/не скажется на их доходах, увидим позже, ещё рано судить.
А у них были серьёзные конкуренты? Такая стратегия себя оправдывает, когда пользователи сидят на продукте как торчки на герыче, и никуда слезть не могут. Да и со времён винды 9х дела с качеством софта у них всё-таки получше стали.
Опытные команды отличаются тем, что они вполне бывает, что пишут говнокод, но держат этот говнокод под контролем.
Практически всегда некий огромный проект можно разбить на много маленьких кусков, у каждого из которых своя зона ответственности. Каждый из маленьких кусков в свою очередь делится на еще несколько маленьких кусков, и так далее. И опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
И вот у нас получается побитый на модули проект, и модули как-то между собой взаимодействуют (и это не обязательно микросервисы, в монолите код тоже можно побить на модули). И тут стоит уделить внимание именно формату взаимодействия, сделать его максимально продуманным и удобным с учетом возможных хотелок в будущем.
Дальше начинаем писать эти модули, и вот тут бизнесу может потребоваться выпустить продукт побыстрее, чем мы это сделаем, если будем писать весь код максимально качественно. Что делать? Бывают ситуации, когда некоторые не самые важные модули можно сделать из говна и палок на основе готовых решений очень быстро — делаем так. Иногда бывает такое, что мы не уверены, а нужен ли нам какой-то конкретный функционал, и если нужен, то в каком виде, нет определенности, или мы просто хотим провести какой-то эксперимент. Тут нет смысла писать максимально качественно, можно не покрывать тестами. В будущем требования могут измениться, или вообще мы поймем что этим никто не пользуется и выкинем. Какие-то критически важные модули всегда пишутся максимально качественно, покрываются тестами, на них не экономим.
Ну и конечно эти все решения принимаются в обсуждении с бизнесом. Мы рассказываем бизнесу, что вот тут мы сейчас идем на компромисс ради скорости, но у нас копится техдолг, сейчас мы сделаем по-простому, но если мы захотим в дальнейшем развивать эту часть, то нам нужно будет дополнительное время, чтобы этот техдолг разгрести.
И если вот так гибко лавировать между качеством и скоростью, то у нас получается, что где-то код написан качественно, где-то нет, но мы это все держим под контролем и не скатываемся в ситуацию, когда у нас весь сервис — куча говна, в которой никто уже не может нормально ориентироваться.
Практически всегда некий огромный проект можно разбить на много маленьких кусков, у каждого из которых своя зона ответственности. Каждый из маленьких кусков в свою очередь делится на еще несколько маленьких кусков, и так далее. И опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
И вот у нас получается побитый на модули проект, и модули как-то между собой взаимодействуют (и это не обязательно микросервисы, в монолите код тоже можно побить на модули). И тут стоит уделить внимание именно формату взаимодействия, сделать его максимально продуманным и удобным с учетом возможных хотелок в будущем.
Дальше начинаем писать эти модули, и вот тут бизнесу может потребоваться выпустить продукт побыстрее, чем мы это сделаем, если будем писать весь код максимально качественно. Что делать? Бывают ситуации, когда некоторые не самые важные модули можно сделать из говна и палок на основе готовых решений очень быстро — делаем так. Иногда бывает такое, что мы не уверены, а нужен ли нам какой-то конкретный функционал, и если нужен, то в каком виде, нет определенности, или мы просто хотим провести какой-то эксперимент. Тут нет смысла писать максимально качественно, можно не покрывать тестами. В будущем требования могут измениться, или вообще мы поймем что этим никто не пользуется и выкинем. Какие-то критически важные модули всегда пишутся максимально качественно, покрываются тестами, на них не экономим.
Ну и конечно эти все решения принимаются в обсуждении с бизнесом. Мы рассказываем бизнесу, что вот тут мы сейчас идем на компромисс ради скорости, но у нас копится техдолг, сейчас мы сделаем по-простому, но если мы захотим в дальнейшем развивать эту часть, то нам нужно будет дополнительное время, чтобы этот техдолг разгрести.
И если вот так гибко лавировать между качеством и скоростью, то у нас получается, что где-то код написан качественно, где-то нет, но мы это все держим под контролем и не скатываемся в ситуацию, когда у нас весь сервис — куча говна, в которой никто уже не может нормально ориентироваться.
Статья не понравилась, со статьёй полностью не согласен. Слишком много в последнее время появляется подобных мантр.
1. Что такое качество кода? Я могу сориентироваться, что чашка сделана некачественно, неправильно сделан шиномонтаж. А что вы скажете о качестве кода? Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.
2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем. Наоборот, всё время существования проекта он может изрядно его тормозить. Пока вы будете думать о том, в какой слой вынести этот метод, успеет поменяться задание целиком.
3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.
4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.
5. Хоть с архитектурой, хоть без вы можете написать ужасный код.
6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.
7. «Некоторым командам удаётся даже получить обратный эффект, когда каждая новая фича выпускается быстрее предыдущей за счёт того, что удаётся переиспользовать уже написанный код».
Какое счастье, что такое происходит редко. Неудачное изменение в одном месте поломает весь код.
8. «Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Вы серьёзно? А что такое „правильно“? Почему его „правильное“ решение не устареет через полгода и не станет неправильным?
9. Я видел один проект, где чистота архитектуры была выставлена на первый план. Это отнимало очень много моральных сил со всеми тестированиями, методологиями, абстракциями. Я не видел более медленного проекта. По моим оценкам, всё должно было делаться раза в три быстрее и без „архитектуры“.
1. Что такое качество кода? Я могу сориентироваться, что чашка сделана некачественно, неправильно сделан шиномонтаж. А что вы скажете о качестве кода? Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.
2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем. Наоборот, всё время существования проекта он может изрядно его тормозить. Пока вы будете думать о том, в какой слой вынести этот метод, успеет поменяться задание целиком.
3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.
4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.
5. Хоть с архитектурой, хоть без вы можете написать ужасный код.
6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.
7. «Некоторым командам удаётся даже получить обратный эффект, когда каждая новая фича выпускается быстрее предыдущей за счёт того, что удаётся переиспользовать уже написанный код».
Какое счастье, что такое происходит редко. Неудачное изменение в одном месте поломает весь код.
8. «Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Вы серьёзно? А что такое „правильно“? Почему его „правильное“ решение не устареет через полгода и не станет неправильным?
9. Я видел один проект, где чистота архитектуры была выставлена на первый план. Это отнимало очень много моральных сил со всеми тестированиями, методологиями, абстракциями. Я не видел более медленного проекта. По моим оценкам, всё должно было делаться раза в три быстрее и без „архитектуры“.
Что такое качество кода?
Влияние совокупности принятых и реализованных на какой-то момент времени решений, на объём трудозатрат требуемый для внедрения последующих фич в проект.
Его можно сравнить с написанием книг. Эта книга написана качественно, а эта некачественно (видимо, автор был пьян). Никакого качества кода нет.
Получается, сфера разработки ПО развивается в сторону управления сложностью последние пол века абсолютно не плодородно, программы не стали больше?
2. «Качественный» код не обязательно даёт какие-то ускорения проекту в будущем.
Если проект не будет развиваться то ему ничего уже на даст ускорения, а если будет то Качественный Код здорово поможет ему в развитии, потому что читать код обычно приходится больше чем писать.
Наоборот, всё время существования проекта он может изрядно его тормозить.
Это некачественный код, либо излишний идеализм разработчиков.
Пока вы будете думать о том, в какой слой вынести этот метод, успеет поменяться задание целиком.
А это уже говорит о проблемах менеджмента
3. Следование методологии TDD, «чистой архитектуре» ради архитектуры, абстракциям ради абстракций значительно замедлит проект.
Абстракции нужны не ради абстракций, а для сокрытия несущественных деталей, чтобы упростить понимание логики системы, облегчить дальнейшее усовершенствование системы, и упростить процедуру входа новичков в проект, как и архитектура.
4. Грамотное написание комментариев, разделение проекта по функциям упрощает чтение кода, ускоряет его развитие.
Статистики у вас конечно же нет?
Большое количество комментариев в коде уже говорит о проблемах.
Забавно, кстати, этот абзац — он ведь про то, чего по вашим же словам — «нет»
5. Хоть с архитектурой, хоть без вы можете написать ужасный код.
Хоть с архитектурой хоть без вы можете построить некачественно здание(речь вообще вроде шла о качественной архитектуре)
6. Архитектура ПО — это не строительство небоскрёба. Это строительство велосипеда, в котором наличие насоса, ремнабора влияет на то, доедете ли вы вообще. Всё на всё влияет, от установки шин до руля.
Ответ который я скрыл после написания upd
Решения, сложность которых обусловлена и оправдана сложностью предметной области, и которые действительно являются принципиально новыми пилит пара калек в гугле, энтерпрайза всякого это касается кратно меньше.
upd: Перечитал и понял что вообще не понял что вы хотели донести данным абзацем.
7. «Некоторым командам удаётся даже получить обратный эффект, когда каждая новая фича выпускается быстрее предыдущей за счёт того, что удаётся переиспользовать уже написанный код».
Какое счастье, что такое происходит редко. Неудачное изменение в одном месте поломает весь код.
1. Общая логика != Общий код
2. В одном только языке PHP, каждый будний день, используя его пакетный менеджер, устанавливается 25-30 млн готовых пакетов чтобы переиспользовать их код packagist.org/statistics
3. Понятие «Чистый код» оно вообще не о переиспользовании, оно больше про сложность понимания кода и количество кода который нужно изменить для внедрения новых решений, а эти две вещи прямым образом влияют на скорость развития проекта.
8. «Он ответил так, как ответил бы любой опытный архитектор: «Мы принимали хорошие решения, но только сейчас понимаем, как нужно было делать правильно».
Вы серьёзно? А что такое „правильно“? Почему его „правильное“ решение не устареет через полгода и не станет неправильным?
Вся разработка сейчас об относительных понятиях лучше/хуже, и нет ничего страшного в том что решение выбранное пол года назад кажется уже не таким хорошим.
«There is no Silver Bullet»
9. Я видел один проект, где чистота архитектуры была выставлена на первый план. Это отнимало очень много моральных сил со всеми тестированиями, методологиями, абстракциями. Я не видел более медленного проекта. По моим оценкам, всё должно было делаться раза в три быстрее и без „архитектуры“.
Я видел один проект(на самом не один), где разработка новых фич была выставлена на первый план и разработчиками в том числе. Они не тратили время на тестирование, методологии, абстракции, они в лучшем случае не пушили с локалки в мастер и имели ручного тестировщика или пачку приёмочных/smoke тестов.
Каждый раз проводя ретроспективу своих действий в одиночку или с командой, я понимал что больше половины(процентов 70, а то и 90) затраченного мною или командой времени уходило на разбор текущей кодовой базы с целью понять как приспособить её к новым требованиям, а не на саму часть имплементации этих требований в коде, не говоря уже об отдельных задачах на рефакторинг существующей кодовой базы, так как без этого эффективность работы падала бы и дальше, вплоть до уровня полной неокупаемости внедрения новых фич и остановки развития проекта.
Я сейчас работаю во фронтенд команде одного проекта, где в одном нашем фронтовом репозитории каждый день пишут код больше 25 человек, каждый день собираются и катаются релизы. И этот проект живет уже не один год. И у нас есть архитектура, методологии, абстракции, юнит тесты, функциональные тесты, статическая типизация и т.д.
Вы знаете, как в таких условиях без этого всего годами поддерживать код на таком уровне, чтобы я мог легко поправить что-нибудь в той части, где код писался полтора года назад неизвестно кем, и быть абсолютно уверенным, что я нигде ничего не сломал при этом?
Вы знаете, как в таких условиях без этого всего годами поддерживать код на таком уровне, чтобы я мог легко поправить что-нибудь в той части, где код писался полтора года назад неизвестно кем, и быть абсолютно уверенным, что я нигде ничего не сломал при этом?
Очередное «ожидание vs реальность», к сожалению.
Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(
В этой статье я докажу, что к миру разработки компьютерных систем этот компромисс не применим и, в действительности, создавать ПО высокого качества оказывается в конечном счёте дешевле.Прочитаешь вот такое — удивишься, конечно — но таки ждешь «ниже» хотя бы попытку показать *связь* между качеством *продукта* и качеством его *кодовой базы*. А натыкаешься на
Поэтому я разделяю критерии качества на две категории: внешние (например, UI/UX или наличие багов) и внутренние (архитектура).Ну ок… пусть хоть так. Но, связь-то покажите…
Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать.И? Это чтоль что-то говорит о качестве *продукта*?! О качестве «внешнем»?! Ну можем «фичи» быстрее делать… наверное. Дальше-то что?
При обсуждении качества кода с менеджментом, я призываю к тому чтобы рассматривать его исключительно как экономический показатель. Если программа внутри сделана качественно, то будет проще и дешевле добавлять в неё новые фичиЭто — далеко — не факт. Ибо это — внезапно — от конкретной «фичи» зависит не меньше, чем от качества *кодовой базы* или архитектуры. Я это вам как «менеджмент» говорю.
Это означает, что вложения в написание качественного кода, в конечном счёте, снижают общие затраты на разработку.На *разработку*?! Really?
Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(
Высокое внутреннее качество способствует более быстрому выпуску новых фич, потому что их проще, быстрее и дешевле делать.
И? Это чтоль что-то говорит о качестве *продукта*?! О качестве «внешнем»?! Ну можем «фичи» быстрее делать… наверное. Дальше-то что?
Я вам так скажу… качество кодовой базы *реально* важно только в одном единственном случае. Если вы *зарабатываете* именно на нем :-) Во всех остальных случаях, качество продукта — первично. А оно — скорее, к сожалению — от качества кодовой базы не зависит. По крайней мере, пока наличие этой зависимости нам выявить не удалось :-(
Я это вам как «менеджмент» говорю.
Ответьте, как «менеджмент», какой продукт сочтут более качественным пользователи — работающее стабильно и без багов приложение с регулярной поставкой новых фич в обещанные сроки, или приложение в котором релизы и новые фичи выходят с затяжкой в месяцы, а баги обкатываются на живых пользователях(которое, наверняка, ещё и стоить будет дороже)?
А можно я, как тоже «менеджмент», отвечу?
Пользователи хотят быстрое и стабильное, с регулярной поставкой заказанных фич в обещанные сроки, но ограничения по ресурсам практически всегда заставляют чем-то жертвовать. А чем именно, уже зависит от конкретного продукта, конкретного рынка, конкретной задачи. Я не могу сказать, что важнее, качество кода, скорость разработки фич, отсутствие багов, легкость сопровождения. Везде по-разному. Если какая-то бизнес-фича критична для заказчика, её, бывает, приходится делать на коленке и потом год ещё подпирать костылями на продакшене. Если какой-то сервис приносит деньги 24х7, то заказчик скажет «вы хоть два месяца эту мелкую фичу вылизывайте и обматывайте тестами, но чтобы деплой был без единого сучка и задоринки». А бывает и так, что проект делается тесно с заказчиком, который решил, что негоже ему ещё и глубокое тестирование оплачивать, когда своих сотрудников толпа сидит бездельничает, и да, тогда баги обкатываются на живых пользователях в продакшене.
Вот чего я ни разу в жизни не замечал, чтобы это было нужно и интересно пользователям, так это Continuous Delivery. Наоборот, почти все просят вернуться к редким, но крупным обновлениям версий. А те, кто не просит, просто молча терпят. Но это как бы мой опыт, у кого-то может быть иначе.
Пользователи хотят быстрое и стабильное, с регулярной поставкой заказанных фич в обещанные сроки, но ограничения по ресурсам практически всегда заставляют чем-то жертвовать. А чем именно, уже зависит от конкретного продукта, конкретного рынка, конкретной задачи. Я не могу сказать, что важнее, качество кода, скорость разработки фич, отсутствие багов, легкость сопровождения. Везде по-разному. Если какая-то бизнес-фича критична для заказчика, её, бывает, приходится делать на коленке и потом год ещё подпирать костылями на продакшене. Если какой-то сервис приносит деньги 24х7, то заказчик скажет «вы хоть два месяца эту мелкую фичу вылизывайте и обматывайте тестами, но чтобы деплой был без единого сучка и задоринки». А бывает и так, что проект делается тесно с заказчиком, который решил, что негоже ему ещё и глубокое тестирование оплачивать, когда своих сотрудников толпа сидит бездельничает, и да, тогда баги обкатываются на живых пользователях в продакшене.
Вот чего я ни разу в жизни не замечал, чтобы это было нужно и интересно пользователям, так это Continuous Delivery. Наоборот, почти все просят вернуться к редким, но крупным обновлениям версий. А те, кто не просит, просто молча терпят. Но это как бы мой опыт, у кого-то может быть иначе.
UFO just landed and posted this here
Разработка, Разработчик, Пользователь — и всё с большой буквы, это прекрасно (без иронии)
Если бы вписать в эту идею-формулу ещё Продукт и Менеджмент, будет вообще чудесно (внезапно, тоже не ирония)
Если бы вписать в эту идею-формулу ещё Продукт и Менеджмент, будет вообще чудесно (внезапно, тоже не ирония)
UFO just landed and posted this here
Вообще, в правилах русской орфографии и пунктуации забыли написать один важный раздел: «Злоупотребление прописными буквами при выделении акцентов на некоторых именах нарицательных». И это даже не ирония.
UFO just landed and posted this here
А в ваших руках одним комментарием выше этот топорный прием внезапно превращается в тонкую аргументацию, да?
По теме я написал выше. Впрочем, я не питаю особых иллюзий по поводу нашей дискуссии, т.к. судя по вашим рассуждениям и уровню подготовки, вы явно пытаетесь изучать прикладную отрасль, работая при этом в академической среде. И хуже того, пытаетесь ещё и прикладные решения какие-то создавать. Это вообще парадокс наших ВУЗов, когда экономическим наукам учат люди, которые никогда не решали экономические вопросы, а разработке ПО учат те, кто никогда не занимался профессиональной разработкой.
По теме я написал выше. Впрочем, я не питаю особых иллюзий по поводу нашей дискуссии, т.к. судя по вашим рассуждениям и уровню подготовки, вы явно пытаетесь изучать прикладную отрасль, работая при этом в академической среде. И хуже того, пытаетесь ещё и прикладные решения какие-то создавать. Это вообще парадокс наших ВУЗов, когда экономическим наукам учат люди, которые никогда не решали экономические вопросы, а разработке ПО учат те, кто никогда не занимался профессиональной разработкой.
Лучше бы вы не ограничивались философией, а чуть больше времени уделяли математической оптимизации и микроэкономике. В любой экономической/инженерной сфере мы можем найти массу примеров дуализма, и разработка тут не исключение. Вот только нам это никак не поможет принимать решения, какую стратегию разработки выбрать.
И да, правильный ответ: высокое качество ПО стоит затрат на его разработку. Иногда. А иногда не стоит. А иногда оно обязательно. А иногда оно приведет к смерти вашего бизнеса. Поэтому надо изучать текущую ситуацию и принимать решение на основании имеющихся фактов, а не искать серебряную пулю в законах философии.
И да, правильный ответ: высокое качество ПО стоит затрат на его разработку. Иногда. А иногда не стоит. А иногда оно обязательно. А иногда оно приведет к смерти вашего бизнеса. Поэтому надо изучать текущую ситуацию и принимать решение на основании имеющихся фактов, а не искать серебряную пулю в законах философии.
UFO just landed and posted this here
Это образец хаотичного мышления, иллюстрация действий «методом тыка», позволяющего решать, мягко выражаясь, не все задачи.
Тут возможно лишь одно из двух — вы либо специально цепляетесь к моим словам, либо у вас отсутствует здравый смысл.
В том, что я написал, вообще нет никакой «иллюстрации действий», и никакого «метода». Я просто перечислил возможные варианты. Вы не знаете, что такое варианты? Вы не отличаете их от последовательности действий? Насколько я понял, вы хоть и не практикующий специалист в этой сфере, а ВУЗовский теоретик, но уж точно не идиот. Но тогда зачем вы цепляетесь к словам?
Да запросто :-)
Для *пользователя*, качество продукта — вещь сугубо утилитарная. В том смысле, что он его (это качество) осознает и воспринимает исключительно в области своих *потребностей*. И — отвечая на ваш вопрос — *пользователям*, в общем случае, те вещи, о которых вы пишите, вообще «сугубо фиолетовы».
Хотя, я вполне допускаю, что могу быть пользователи, для которых «регулярная поставка новых фич» и лежит в области их потребности, но, гораздо важнее то, что — в любом случае — эта вещь интересует как раз «менеджмент». По другим, правда, причинам.
И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно. Например, качество процессов на это оказывает несравнимо более сильное влияние.
Я, к своему сожалению, сразу-то не обратил внимание на то, что это перевод Фаулера. Иначе бы сразу читал оригинал, с поправкой на, скажем так, весьма специфический взгляд Мартина на некоторые вещи :-)
Но, в любом случае, его вывод о том, что
Для *пользователя*, качество продукта — вещь сугубо утилитарная. В том смысле, что он его (это качество) осознает и воспринимает исключительно в области своих *потребностей*. И — отвечая на ваш вопрос — *пользователям*, в общем случае, те вещи, о которых вы пишите, вообще «сугубо фиолетовы».
Хотя, я вполне допускаю, что могу быть пользователи, для которых «регулярная поставка новых фич» и лежит в области их потребности, но, гораздо важнее то, что — в любом случае — эта вещь интересует как раз «менеджмент». По другим, правда, причинам.
И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно. Например, качество процессов на это оказывает несравнимо более сильное влияние.
Я, к своему сожалению, сразу-то не обратил внимание на то, что это перевод Фаулера. Иначе бы сразу читал оригинал, с поправкой на, скажем так, весьма специфический взгляд Мартина на некоторые вещи :-)
Но, в любом случае, его вывод о том, что
The «cost» of high internal quality software is negative.— лично с моей точки зрения — является очень сильным упрощением и весьма слабо связан с теми рассуждениями, которые он приводит в статье.
Кстати отличный поинт про перевод фразы =]
Если есть идеи, как её можно перевести не используя «описательный приём» и не удлинняя предложение в 3 раза — буду премного благодарен и поправлю перевод.
(комментарий написан безотносительно сути и мысли предложения, исключтельно в целях повышения качества перевода)
(для справки) Сейчас переведено так:
The «cost» of high internal quality software is negative.
Если есть идеи, как её можно перевести не используя «описательный приём» и не удлинняя предложение в 3 раза — буду премного благодарен и поправлю перевод.
(комментарий написан безотносительно сути и мысли предложения, исключтельно в целях повышения качества перевода)
(для справки) Сейчас переведено так:
Тратить лишние ресурсы на архитектуру и хороший код, с экономической точки зрения, в итоге, оказывается более выгодно.
И «проблема» в том, что именно с качеством *кодовой базы* (наличием отсутствия технического долга, если хотите… хоть это и из области «не научной фантастики») это все связано (если вообще связано) весьма условно.
Скорость разработки новых фич с качеством кодовой базы связана самым прямым образом, потому что прежде чем новую фичу интегрировать в проект, нужно прочитать и разобраться с некоторой частью кодовой базы. Причем, чем лучше спроектирована система, тем меньше объём который нужно прочитать и разобрать — всё может свестить к прочтению одного файла на 100 строк с описанием интерфейса взаимодействия в лучшем случае, и к прочтению и изменению десятков файлов в худшем.
Ну а то что количество багов в программе связано исключительно с качеством кода, я думаю очевидно.
P.S. И да, читают код больше чем пишут.
Скорость разработки новых фич с качеством кодовой базы связана самым прямым образом, потому что прежде чем новую фичу интегрировать в проект, нужно прочитать и разобраться с некоторой частью кодовой базы.Да с тем, что качество кодовой базы влияет на трудоемкость анализа и качество оценок — никто же не спорит. Просто, вы, судя по всему, считаете эти факторы определяющими «скорость разработки новых фич». А это — далеко не так. Их влияние на эту «скорость» весьма опосредовано и ограничено.
Ну а то что количество багов в программе связано исключительно с качеством кода, я думаю очевидно.?! Это же вообще никак с *качеством* кодовой базы не связано.
Да с тем, что качество кодовой базы влияет на трудоемкость анализа и качество оценок — никто же не спорит. Просто, вы, судя по всему, считаете эти факторы определяющими «скорость разработки новых фич». А это — далеко не так. Их влияние на эту «скорость» весьма опосредовано и ограничено.
Про анализ и качество оценок тоже всё так.
Но я говорю о времени затраченном на период с момента когда отдел разработки берется за выполнение задачи, до момента когда она будет выполнена и протестирована. В большинстве случаев (если нет блокирующих зависимостей от каких-то внешних сервисов) это время зависит именно от кодовой базы.
Чем хуже текущая кодовая база, тем:
1 — больше времени нужно затратить в среднем на разбор одинакого объёма кода
2 — больше, причём в разы, объём кода который нужно разобрать
Ну а то что количество багов в программе связано исключительно с качеством кода, я думаю очевидно.
?! Это же вообще никак с *качеством* кодовой базы не связано.
А с чем же ещё? Во первых чем больше кода мы правим — тем больше шансы что-то поломать, а чем кодовая база хуже — тем больше кода нам приходится править.
Ну и часто баги случаются из-за неожидаемого, незадокументированного(и я сейчас не про техническую документацию) поведения от каких-то частей текущей кодовой базы.
Именно об этом тот же «Design Stamina Hypothesis» график от Фаулера
Но я говорю о времени затраченном на период с момента когда отдел разработки берется за выполнение задачи, до момента когда она будет выполнена и протестирована.Да я-то это понял уже :-) Но я вам уже в который раз говорю — это время не является ключевым фактором для «скорости разработки новых фич». Например, постановка задачи для «отдела разработки» — которая, как минимум, требует формализации в терминах модели предметной области — более затратна по времени, и от кодовой базы не зависит вообще никак. Или, например, качество самих процессов разработки — оно тоже от кодовой базы не зависит. При этом, по влиянию на «скорость», это перекрывает вообще любое качество кодовой базы.
В большинстве случаев (если нет блокирующих зависимостей от каких-то внешних сервисов) это время зависит именно от кодовой базы.Не надо забывать, что в первую очередь, это время зависит от самой фичи. А качество кодовой базы — это лишь один из «поправочных коэффициентов».
Чем хуже текущая кодовая база, тем:Ну пункт 2 — он, скажем так, немножечко спорный :-) Низкое качество кодовой базы, вообще говоря, не значит, что вырастает «объём кода который нужно разобрать». Всё таки мы уже достаточно давно умеем стоить control flow для большинства языков :-) Не суть. Пусть все так, как вы говорите. Но ведь «больше времени» нужно и на то, чтобы *хотя бы* поддерживать текущее качество. И это ведь не разовые затраты. Это каждый раз нужно делать.
1 — больше времени нужно затратить в среднем на разбор одинакого объёма кода
2 — больше, причём в разы, объём кода который нужно разобрать
Еще раз… я ведь не говорю, что высокое качество кодовой базы — это «плохо» :-) Речь лишь о том, что оно ни разу не бесплатно. И уж, тем более, не «is negative», как утверждает Мартин.
Во первых чем больше кода мы правим — тем больше шансы что-то поломать, а чем кодовая база хуже — тем больше кода нам приходится править.Уже второй раз у вас качество кодовой базы ассоциируется с объемом кода. Лично для меня, это выглядит как-то странно. Меня учили, что качество кода — это, грубо говоря, его *понятность*. А понятность, в нашем деле, это — в первую очередь — цикломатическая сложность, и производные от неё. Есть, конечно, ещё «куча всего», но это уже вещи специфичные для конкретного языка, платформы и т.п. Я хоть и «старый человек», но, вроде как, с того времени у нас ничего не поменялось. Но вы, судя по всему, под качеством кодовой базы понимаете что-то другое. И из этого, насколько я понимаю, и родилась эта «дискуссия» :-)
Полностью согласен со статьей с одной оговоркой. Мне не нравится термин качество кода. На больших проектах хорошая абстракция/проектирование могут выдержать довольно большое кол-во говнокода на низком уровне, обратное зачастую не так. Но проблема в том, что те кто может проектировать — и так проектируют, а те кому не дано- нет, либо проектируют, но фигово.
Ну и дополнение про техдолг. Далеко в него залезать опасно, потому что есть точка невозврата, после которой остановиться уже анрил и проект начнет превращаться в болото…
Ну и дополнение про техдолг. Далеко в него залезать опасно, потому что есть точка невозврата, после которой остановиться уже анрил и проект начнет превращаться в болото…
Sign up to leave a comment.
Стоит ли высокое качество ПО затрат на его разработку?