Комментарии 16
TLDR: графомания.
Неудержимо повеселил тезис:
99.9% проблем, которые вы обнаружите у купленных продуктов (будь то вещи или ПО), были известны производителям при продаже и, вероятно, даже до производства (т.к. есть специальные аналитики, которые предсказывают возможные проблемы конфигураций продукта), а на прилавки продукты попали потому, что их уровень качества оказался допустимым по мнениям производителей.
Предпроектная аналитика в крупных проектах умерла. Полностью. По крайней мере, на постсоветском пространстве.
За его пределами свои заморочки и свой культурный контекст - но и там забег к воображаемой финишной черте скорейшей сдачи уже начинает застилать глаза. "Нет времени экономить время", бэклог потом разберём.
(если первее не сделает добивание Data Driven Development, или демонический Ленин, или ещё чего похлеще)
Наложите поверх хроническую асфиксию HR как института (даже у талантливых HR уже не хватает квалификации, чтобы адекватно оценить кандидатов самим, да и мысль о том, что инвестиция в HR - это инвестиция в долгосрочное благополучие коллектива, приходит бизнесу слишком поздно).
И хронический пофигизм выделенных на профильные собеседования кадров.
Добавим наверх козни Маркетингового Молоха, который требует увеличивать пользовательскую базу любой ценой, от явной лжи до стрёмной полуправды.
По-Мавродиевски ловкие манипуляции с отчётностью, когда, например, отдел техподдержки, выжравший вагонище ресурсов, умудряется не только не принести пользу для сопровождения проекта, но и не учесться в прибыльности этого проекта.
Что ещё забыл?
...опасную тему Вы затронули. Не принято о таком говорить в IT...
Предпроектная аналитика в крупных проектах умерла.
Есть такая информация. Но аналитика умерла не полностью. Например, при производстве смартфонов Samsung, Apple и др есть анализ конфигураций продукта (анализ компонентной базы, компоновки и др.) ещё на этапе проектирования нового устройства. Однако, как устроена их аналитика мне неизвестно, а даже если и было бы известно, то это NDA.
При разработке ПО аналитика тоже не совсем вымерла, иначе масштабирование и миграции стали по-истине адскими процессами. Пока ещё не совсем так.
Ну и последний момент: если бы аналитике не было, то допустимый уровень качества считался только эмпирически и... да, это уже происходит, но не совсем везде и не в полной мере...
Не принято о таком говорить в IT
Мне кажется, про описанное в статье (в общих чертах) стоит знать, по крайней мере, бОльшему числу связанных с IT людей.
А ещё я устал рассказывать это устно. Хочется, наконец, давать ссылку.
А ещё я устал рассказывать это устно. Хочется, наконец, давать ссылку.
Послушайте старого упёртого болвана.
Ведите дневник. Оффлайновый.
В текущей ситуации это будет хотя бы в плюс по эмоциональному состоянию (не нужно цапаться с нигилистами, кроме TLDR знающих только WASD, да и то не всегда), да и копипастить проще, чем искать "где же я это запостил", если подойти к делу творчески.
Ведите дневник. Оффлайновый.
Есть такое. В него записываю интересные мысли по разным темам.
Но дневника людей, кому рассказывал и что - пока нет.
да и копипастить проще
Не совсем. Тот же телеграмм будет не слишком рад сообщению длинной в несколько тысяч символов. Да и форматирование уплывёт.
Как вариант - хостить тексты на notabug или codeberg, которые, по идее, не должны удалять контент. Надеюсь, хабр до этого не доведёт.
Предпроектная аналитика в крупных проектах умерла.
Есть такая информация. Но аналитика умерла не полностью. Например, при производстве смартфонов Samsung, Apple и др есть анализ конфигураций продукта (анализ компонентной базы, компоновки и др.) ещё на этапе проектирования нового устройства. Однако, как устроена их аналитика мне неизвестно, а даже если и было бы известно, то это NDA.
При разработке ПО аналитика тоже не совсем вымерла, иначе масштабирование и миграции стали по-истине адскими процессами. Пока ещё не совсем так.
Ну и последний момент: если бы аналитике не было, то допустимый уровень качества считался только эмпирически и... да, это уже происходит, но не совсем везде и не в полной мере...
Спору нет, какие-то люди на этих позициях есть, что-то делают. Делают что могут с тем, что есть.
Samsung - не рассматриваю как удачный пример после того, как больше двух лет намаялся с их чудовищным A01.
"Современные версии Android не дают ставить приложения на карту" + "давайте загадим внутреннюю память фирмварью доверху" + кое-какие интимные трудности в собственно фирмваре - это ооооох... Хоть самому учись кастомные прошивки собирать...
Будь там хоть какое-то подобие предпроектной аналитики - такой фигни бы не случилось.
Apple - no comments. Зарёкся использовать после полного рта хлопот с их хвалёными эйрподсами и их же 5S (на тот момент всё ещё "официально поддерживаемым"!).
LG делали ничего такие смартфоны, G3s был крайне, крайне приятным - но это, может быть, исключение из правил...
При разработке ПО аналитика тоже не совсем вымерла, иначе масштабирование и миграции стали по-истине адскими процессами.
Расскажу притчу.
В World of Tanks после недавних событий очень долго не работал (может, и до сих пор не работает) внутриигровой чат.
На первый взгляд это было изящным решением проблемы "разогнали саппорт - жалобы на матерщинников ворочать некому".
Но проблема оказалась аппаратно-миграционного толка. А ведь это не мелкая рыбёшка...
Если же брать более серьёзное ПО...
Смотря что иметь в виду под масштабированием.
Если продуктовая команда не совсем томаты и проект лепился не совсем впопыхах - наверняка имеется какое-то внутреннее API (или его подобие), которое по большой нужде можно использовать для масштабирования экстенсивного (под этим я понимаю переход с работы одного инстанса софта на слаженную работу нескольких инстансов софта с или без какого-то центрального компонента-"дирижёра").
Вот с интенсивным (тут я понимаю распарралеливание работы одного инстанса по наличным поддерживающим разделение потоков мощностям) будет полная и необратимая попа. 100%.
Если у команды стейкхолдеры не оборудованы через одного нимбами - боюсь, закомонаетесь доказывать, что если не дай Бог проект выстрелит в таком виде - на его масштабирование придётся потратить совершенно некукуйские деньги. Потому, что "нет времени экономить время" + "ты чо тормозить, рынок без нас вперёд уйдёт".
Мне кажется, про описанное в статье (в общих чертах) стоит знать, по крайней мере, бОльшему числу связанных с IT людей.
Не хочу Вас расстраивать, но на этом ресурсе реальнее получить обратную связь от продавцов вагинальных чаш (кстати, куда они все запропастились...), чем от реально заинтересованных в таких экзотических темах для дебатов людей. Проверено на себе.
Берегите карму, выбирайте темы аккуратнее.
не рассматриваю как удачный пример
Удачных примеров, можно сказать, и нет. Практический любой продукт (и любой потребительский) производится не без доли "потом сообразим" и "и так сойдёт". Однако, предпроектная аналитика в то или иной мере есть, хоть, видимо, и в относительно пофигистской форме.
Совсем нет предпроектной (и межстадийной) аналитики только в очень быстрорастущих проектах, в которых допустимый уровень качества определяется исключительно эмпирически на основе текущих проблем. При этом, производится невообразимое количество технического долга, так что проекту начинает угрожать полное переписывание.
Смотря что иметь в виду под масштабированием.
Я подразумевал оба.
Экстенсивное просто не будет работать, если не предусмотреть хотя бы какие-то адекватные интерфейсы. Без адекватных интерфейсов и само масштабирование работает неадекватно.
С интенсивным, да, обычно, всегда большие проблемы. Но хотя бы какой-то части этих проблем удастся частично избежать при хотя бы какой-то структурной аналитике.
всё сложилось так, как сложилось и это сможет изменить либо катастрофа, либо чудо.
Все сложилось так, потому что по другому быть просто не могло. Самый лучший ответ на вопрос "почему" даёт книга Докинза "Эгоистичный ген".
Если лень читать книгу, то вот короткая выжимка: Все живые организмы, вся жизнь подчинена только одной цели - увеличить количество копий генов. Гены устроены так, что они любой ценой "хотят" увеличивать число своих копий. Любой ценой, вообще любой. Вся деятельность человеческого общества вытекает из этого факта. Генетический детерминизм обрекает нас на такое существование.
У этой проблемы есть только одно решение: 1 Достижение бессмертия. 2 Запрет на размножение. 3 Возможно евгеника.
Т.е. по сути нужно остановить неконтролируемую биологическую эволюцию.
Все сложилось так, потому что по другому быть просто не могло.
Увы, сложилось так, как сложилось :) Биология сложилась... Природа сложилась...
Достижение бессмертия
Если это случится, но не случится запрета на размножение, то будет перенаселение. Если и на размножение запрет будет, то мышление перестанет развиваться. Каждый новый человек - это новый взгляд (хотя бы у 1 из 10). Нет новых людей - нет новых взглядов.
К тому же, вероятно, бессмертие получат только избранные. И это только усугубит дело, так как их эгоистические (и ещё много какие) взгляды и принципы будут управлять веками.
Возможно евгеника
А вот этого наше толерантное общество точно не примет...
У меня сложилось мнение, что человек который написал статью явно не является программистом. То что губит большие проекты с технической точки зрения(а программист может отвечать только за это), это нелинейный рост сложности и технический долг. И по поводу библиотечного кода, и феймворков, как-то совсем не внятно обозначена позиция. Если мы не говорим про потомков left-pad, то во многие эти решения вложены годы, а иногда и десятилетия опыта и экспертизы не самых глупых людей(а возможно как раз тех самых талантливых о чем упоминается в начале статьи). Многие из них лежат в опен сорсе, с адекватными лицензиями, не использовать эти компоненты просто глупо. (если только не NIH синдром и очередная "фатальная ошибка")
У меня сложилось мнение, что человек который написал статью явно не является программистом.
Хм, отчасти вы правы. Я чаще занимаюсь работой над архитектурой, то есть, работаю с диаграммами, документацией и др. Однако, и программистские задачи выполняю. Так что могу взглянуть с разных сторон.
нелинейный рост сложности и технический долг
Если я правильно понял мысль, то эти вещи связаны. Технический долг и приводит к нелинейной сложности. Есть ещё нюансы предметной области и ТЗ. Про ТЗ - отдельная история, которой я не касался в статье. Не очень хочу и в комментарии. Усложнение предметной области - ситуация не очень распространённая - я бы даже назвал её немного экзотической.
программист может отвечать только за это
Пожалуй, единственное, что относится непосредственно к программисту (из того, что я упоминал в статье) - образование (знания, опыт, навыки) и желание делать качественно. Другой вопрос, что поддерживать желание программиста делать качественно может далеко не любой менеджмент, а без поддержки менеджмента, я считаю, нужно положить это желание в коробку "for future purposes" и делать так, как удобно, иначе - выгорание.
И по поводу библиотечного кода, и феймворков, как-то совсем не внятно обозначена позиция.
Я описал ситуацию со стороны. Как можно более объективно (но всё равно субъективно).
Основная мысль в том, что фремворки - не панацея. Сточки же зрения программиста в фреймворках нет ничего плохого (опять же за исключением необходимости изучать локальную систему абстракций).
во многие эти решения вложены годы, а иногда и десятилетия опыта и экспертизы не самых глупых людей
И есть надежда, что все эти человеко-часы вложены эффективно (т.е. в дело). Во всяком случае, я такую надежду имею. В статье же бросается камень больше в пользователей фреймворков, чем в их создателей.
Против вдумчивого использования фреймворков ничего не имею.
если только не NIH синдром и очередная "фатальная ошибка"
Скорее, синдром "доверяй, но проверяй". Здоровый скептицизм и недоверие никогда не повредят.
Многие программисты не доверяют пользователям, но чересчур доверяют другим программистам.
Где-то между бизнесом и религией стоит упомянуть внерыночные механизмы, которые создает государство. Например, дает привилегии тому бизнесу, который помогает обучать специалистов, нужных государству (но не бизнесу). Это не совсем институт права, который вы упомянули, это государственная стратегия.
Где-то между бизнесом и религией стоит упомянуть внерыночные механизмы
Если придерживаться статьи, я бы отнёс эти механизмы к подклассу законов, а именно "law jailbreak", т.е. своеобразных "взломов" закона, находящихся на самом краю института права. В кавычках, потому что изначально в законе заложена возможность такого "взлома" (иными словами, бэкдор). И это никем не скрывается. Достаточно грамотный юрист всё это понимает и знает как использовать.
Я бы назвал внерыночные механизмы инструментом института права, но не отдельным институтом. Государство как отдельный институт я бы тоже не обозначил, так как с точки зрения обеспечения прав оно является надклассом институтом права (включает в себя закон).
Про внерыночные механизмы я не говорил и не очень хочу, потому что это слишком близко-политическая тема, а в политике заморочек (как я считаю) больше, чем где бы то ни было ещё. Трактовать то или иное довольно сложно.
Как любой инструмент, эти механизмы могут действовать как в пользу, так и во вред, добавляя "случайности" (хоть и не случайной) в институт права, поэтому они где-то с краю, на грани.
Это деловой подход