Введение
Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки. Такое случается в потрясающе огромном проценте компаний и проектов. Даже если компании знают о существовании такого понятия, как QA, и что его нужно выполнять, все усилия обычно приводят лишь к большому спринту QA прямо перед релизом. Это стрессовый период, в который мы пытаемся заставить ПО хотя бы немного работать. Разумеется, весь этот хаос повторяется на следующем цикле релиза без малейших улучшений.
Чему нас учат в вузах
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО. Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее. Кроме того, по крайней мере, в моей учёбе, был семестр, посвящённый методикам управления проектами и Scrum. Всё это замечательно, но тут совершенно отсутствует QA. Пренебрежение QA — это огромная потеря, потому что больше 90% всех студентов после завершения учёбы работает в контексте компаний. Они должны будут выпускать ПО вовремя и без багов.
Почему компании едва успевают выпускать ПО вовремя
Я сталкивался с этим бесконечное количество раз. Стандарты и меры обеспечения QA одними из первых попадают под нож, потому что для проектов важнее всего бюджет. Зачастую они планируются на конец проекта, но если разработка затягивается (а такое бывает часто) или происходит разрастание фич (что бывает всегда), на QA больше не остаётся времени. В конечном итоге мы получаем абсолютный минимум неструктурированного тестирования и выпускаем цифровой карточный домик с шатающимися стенами.
В некоторых компаниях и командах применяются некие стандарты QA. Обычно их внедрением занимается сотрудник сеньор‑уровня. Чаще всего он на своём горьком опыте знает, что без QA работа постепенно становится всё более сложной. К сожалению, даже наличия стандартов недостаточно. Очень часто команды просто пишут тесты, чтобы удовлетворить метрикам управления проектом.
Как сойти с этой карусели
Мне потребовались долгие годы опыта, чтобы набраться уверенности и начать говорить об отсутствии мер обеспечения QA в проектах. До этого мне приходилось спорить с менеджерами, ночевать на работе перед релизами, иметь дело с разваливающимися в продакшене системами и искать отсутствующий мониторинг. Всё это было невесело. Эти ситуации схожи с другими улучшениями кодовой базы или проекта, которые незаметны менеджерам, например с рефакторингом. Но в случае с QA это было особенно сложно, потому что если мы не внедряли никаких мер его обеспечения, мы так и не учились делать это правильно.
Только высказывая своё мнение и поднимая это на обсуждение снова и снова, мы сможем сделать первые шаги, чтобы выйти из этого порочного круга.
Поговорим о деньгах
В какой-то момент я осознал, что использую неподходящие аргументы. Если говорить, что ПО будет «стабильнее» или что оно «сильно упростит поддержку», то эти доводы не будут иметь особого смысла для тех, кто не работает над самой кодовой базой. Нужно говорить о деньгах. Мы, разработчики, должны говорить о том, сколько стоит отсутствие QA. Это язык бизнеса и руководства в целом. Сейчас я всегда стараюсь объяснить меры обеспечения QA на таких примерах: «Если не заняться этим сейчас, то трудозатраты на разработку (а значит, и затраты) через четыре месяца увеличатся на 15%» или «Нам нужно реализовать юнит‑тесты для всех фич, или наши фазы стабилизации релизов с каждым разом будут становиться всё длиннее. Это напрямую относится ко всем создаваемым нами фичам, потому что нам приходится каждый раз вручную тестировать все побочные эффекты. В результате при каждом релизе наш прогресс будет всё меньше».
По моему опыту, переход на такие примеры помогает донести мысль. В конечном итоге, ваши усилия улучшат жизнь каждого, только пока это не все понимают.
Минимальная эффективная доза
Чтобы быть реалистичными, важно не оверинжинирить меры обеспечения QA, тратя на них предварительно большие суммы. Мы не должны мешать развитию проекта в целом; к тому же такой подход понравится не всем стейкхолдерам. Я всегда советую выделить самые жизненно важные части приложения. Обычно существует определённый сценарий использования, фича или нечто иное, на чём построено всё приложение. Это какая-то базовая функциональность, которая обязана работать корректно, чтобы ПО имело ценность для клиента или пользователя. Вот её-то и нужно тестировать. Придумайте меры и способы обеспечить её работу так, как это задумано.
Мне нравится термин «минимальная эффективная доза» (МЭД). Это минимальная доза, дающая желаемый результат. В области QA это может быть план ручного тестирования, автоматизированные тесты в конвейере или что-то другое. Вот с этого и стоит начинать. Если функциональность базовых фич обеспечена, можно постепенно расширять стабильность, например, добавлять для всех новых фич юнит-тесты. Кроме того, подумайте об источниках информации, которые вы не можете контролировать, например о внешних API или вводимых пользователем данных. Находите способы валидировать и их тоже, потому что это очевидные точки, в которых ваше ПО может вылетать из-за неправильного использования. Проводите итерации и работайте инкрементно. Это относится и к QA.
Что я ищу
В каждом новом проекте, который я начинаю или продолжаю, я ищу концепцию QA. Какой бы маленькой она ни была, команде нужно подумать о ней.
Что мы выпускаем?
Что нам нужно, чтобы это работало?
Как это сделать?
Какие из мер мы намеренно исключим и почему?
Наличие письменной документации плюс, возможно, плана тестирования — отличный фундамент, на котором может развиваться ПО. Они показывают, что мы, команда, подумали, как двигаться дальше. Подумали с точки зрения МЭД. Кроме того, я рекомендую регулярно пересматривать выбранные методики, допустим, раз в квартал.
При написании кода я не пользуюсь TDD, но крайне рекомендую писать тесты параллельно с написанием ПО. Это подходящее время для написания теста. Если вы пишете тесты в процессе реализации фичи, то получите дополнительное преимущество: код будет структурирован так, что его действительно можно тестировать. При написании тестов для уже готового ПО часто выясняется, что в его коде слишком много взаимных зависимостей или что нарушены принципы единственной ответственности. Благодаря тестам вы показываете, что поняли желаемое поведение и гарантировали, что всё работает, как ожидается. Это даже можно назвать документацией к коду.
Преимущества для проекта
Когда вы заводите об этом разговор, окружающие вас люди понимают, что вас заботит проект. Поднимая вопрос качества и предлагая возможные решения, вы расширяете свою сферу влияния как разработчика. Это может принести пользу и вам, и проекту. Качество жизни разработчиков и менеджеров повысится. Это определённо заметят.
Только при наличии мер обеспечения QA проект может расти здоровыми темпами.
Меняем проекты к лучшему
Вы уже используете меры обеспечения QA в своих проектах или в них всё очень шатко? Хотите расширить свои навыки разработчика и быть известным как человек, пишущий качественное ПО?
Начните с малого. Подумайте о МЭД своего проекта. Возьмите на себя ответственность и станьте в своей команде тем, кто меняет всё к лучшему. Не всем нужно быть проповедниками QA, но вы можете учить людей необходимым методикам, показывая их на своём примере. Станьте тем, кто начнёт это обсуждение.
Комментарии (36)
zubrbonasus
12.12.2023 17:56Должно быть как автотестирование, так и QA. В идеале один спринт на разработку + юниттесты, второй спринт на QA + functional + acceptance тесты.
muxa_ru
12.12.2023 17:56Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее.
А это значит, что логику написания качественного надо зашить в эти самые "концепции" - https://habr.com/ru/articles/776550/ .
Увы и ах, в современном мире, айтишник это не вершина интеллектуальной цепи, а один из массовых работников, недостаточно квалифицированный и достаточно индифферентный по отношению к тому что он делает.
aeder
12.12.2023 17:56Для начала надо надрючить всех ваших разработчиков на то, чтобы ВСЁ ПО писалось исключительно в стиле "защитного программирования".
Вам нужен аналог assert(), не исключающийся из релизного продукта, и абсолютно во всех случаях, когда есть какое-то условие или возвращаемое значение - оно должно быть проверено или нормальным кодом проверки ошибки, или добавлением неисключаемого из кода assert(). Который должен фиксировать строку/функцию/условие/файл/версию файла.
Таким образом, ваше ПО никогда не должно распространять ошибку дальше.
Использование исключений из кода удалить полностью - точнее, оставить только в модульных тестах.
Ваша программа/модуль должна немедленно паниковать (с сохранением стека и дампа) как только обнаружена ошибка, для которой не предусмотрены штатные условия устранения/восстановления.
Да, и ещё: заставьте своих разработчиков использовать достаточно старый стандарт языка. Ещё лучше: ограничьте используемое множество языка.
Разработчиков, которые тащатся от новейших фич языка - выпихивайте туда, где от них будет минимум вреда - желательно к конкурентам.
marapper
12.12.2023 17:56В общем, пишите медленно, дорого и так, чтобы программа у клиента падала в случае, если баг попадет в версию. Ну что, ок.
aeder
12.12.2023 17:56Ну да, ну да.
Пишите быстро, дёшево, и чтобы программа у клиента не падала ни в коем случае, зато глючила так, чтобы никто концов не нашёл.
Даже подскажу: обкручивайте всё try-catch, и игнорируйте все исключения. Продукт получится охренительный!
delicious
12.12.2023 17:56Вот сарказм разработчикам в 2023 не особо к лицу, когда большинство парадигм и инструментов уже доказали, в каких отраслях и условиях их стоит использовать (а когда - нет). Ваш подход вполне хорош, вот только желательно и его сужать до реального применения (но, к сожалению, в бизнесе сидят такие же люди, как программисты, с идеями).
ItsNickname
12.12.2023 17:56В вузе и не должны учить писать качественное ПО. Эти навыки вы получаете на отработках и первой работе, именно поэтому бесполезно начинать работу с ООО "Рога и Копыта". Вас учат науке, если вы хотите писать код вам в техникум надо было.
MountainGoat
12.12.2023 17:56В вузе по IT выдают бесформенный комок наукоподобных фактов для зубрения. Он чем-то неуловимо похож на те комки шерсти, что иногда выдаёт кот. Разрабатывать По не научат точно, это да. Если в техникуме по-другому (не знаю, не был) то будущему программисту действительно лучше в техникум.
Ilusha
12.12.2023 17:56Почему не должны? А почему на первой работе должны уметь? А почему там должны учить?
Вуз решает задачу подготовки кадров, которые необходимы индустрии. Сейчас это он делает плохо.
Когда вузы начнут делать это хорошо, тогда мы увидим серьезное изменение рынка труда. Когда условный джун сможет писать качественный код.
muxa_ru
12.12.2023 17:56Сейчас это он делает плохо.
"Забудьте всё, чему вас учили в институте" - эта формула старше чем некоторые из преподавателей современных ВУЗов.
Ilusha
12.12.2023 17:56Не «формула», а шуточная присказка.
muxa_ru
12.12.2023 17:56Её шуточность преувеличена.
В том числе потому, что реальные практики адаптированы к узким условиям реальных задач, а в ВУЗах должны давать широкий спектр знаний.
ItsNickname
12.12.2023 17:56В вузе должны давать широкие знания чтобы вы могли вообще осознавать все варианты решения узкой проблемы и чтобы вы тратили время исключительно на изучение специфики задач и областей вместо "ah shit, here we go again" от смены языка, фреймворка или финтеха на геймдев/медицину.
kh0
12.12.2023 17:56Ирония в том, что именно это ожидают от вуза и студенты и работодатели. Те граждане, которые хотят заниматься наукой идут специальные научные вузы, типа мгу, а большинству не надо этих лавров, они хотят создавать. Само-собой, что это еще понимать надо, и часто в мгу идут учиться писать код, а в мытищинский лесотехнический заниматься наукой. Ну так кто бы это еще объяснял молодёжи вовремя. Кстати, я не знаю, где учат писать хороший код в техникумах, чтобы "в любое дело гож, в любые двери вхож", в нашем техникуме программисты на выходе не способны, например написать игру с графикой уровня, какой в нашем вузе дают на курсовой на 3 курс. Максимум что из них выходит это переспективные эникеи, если будут продолжать образовываться дома и на работе. Т.е. он как собака: все понимает, сказать ничо не может, но лицо как бы смышленое, а делает - что попало, обычно - не то. Но у меня выборка маленькая. Может, где-то вузы настолько днище, что там тоже игры с графикой это космос, а выпускники техникумов в топ андроид-скачиваний. Причем по медианной, а не самородки, которым с рождения череп жмет. Я по ЗП еще знаю, что преподы айтишники в техникумах принципиально получают как неудачники, я иногда прохожу мимо техникума, там преподу по ИТ предлагают 30-40+ до вычетов, прям в окне объявление. Оно там давно висит, только по чуть-чуть цифры увеличивают. А раз так, это надо быть настоящим мммм фанатом святпросвета, чтобы вместо 1500000 бксов в наносек идти в образование за печенюшку к празднику.
А ирония в том, что эту глыбу не сдвинуть. Чтобы что-то изменить, это должно идти из самого верха: перетрясти учебные планы как минимум. А учебные планы у нас пока из прямиком из СССР, только научный коммунизм поменяли на физкультуру. Это про вузы. Про техникумы не знаю. Так вот Минобр как-то не замечен в инновациях в вузах, не популистких "мы купили 3д принтер", а вот чтобы выкинуть 90% гуманитарки, например, или химию у программистов отменить, да и начерталку тоже, а вместо этого запихать им туда солид с Барбарой и углубленное до гланд изучение линукса, докера, кубернетиса и прочих аджайлов. Ну либо опять же волевым решением перелопатить учебные планы техникумов и объявить: "граждане, наши вузы не учат программированию, для этого есть техникумы: не мучайтесь сами и не мучайте других. Либо езжайте в МИТ, там есть очень неплохие программы! (А у нас свой собственный путь парадоксов друг".
muxa_ru
12.12.2023 17:56мытищинский лесотехнический заниматься наукой
Вообще-то, это сейчас Бауманка :)
flancer
12.12.2023 17:56Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от применяемых критериев оценки. Возможно, что автор оригинала Florian Bellmann просто никогда не работал в проектах, где требовалось писать качественный софт. Кстати, как тут правильно заметили в комментах, при капитализме самый популярный критерий оценки правильности решения сложных задач - прибыль от инвестиций.
ABRogov
12.12.2023 17:56Проблема в том, что просто нет столько разработчиков, которые способны к высококачественной разработке. Ну вот нет их в товарных количествах. Очень мало. Хорошо разрабатывать сложно, этому учить надо.
В целом это напоминает ситуацию, когда в 19 веке, маститые врачи отказывались мыть руки между вскрытием и принятием родов. Объяснения были примерно такие же, в стиле "а зачем это лишнее действие, мы больше людей вылечим если не мыть руки".
Batalmv
12.12.2023 17:56Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки.
Мне кажется, автору просто не повезло. Я большую часть времени работаю в Enterprise проектах. Честно говоря, вспомнить примеры, когда на QA часть кто-то забивал практически нереально. Т.е. вопрос о каком-либо сокращении этого участка наверное не ставился никогда.
Просто все понимают, что ошибки потом вылезут дороже. пБывает конечно, когда либо проект совершенно распильный, либо ... ну не знаю, внутренний продукт для трех барышен из HR - тогда да.
Но надо тоже понимать, что тестирование очень сильно разное и это всегда компромис. Вы не делаете полный регресс после каждой запятой, вы не проводите полное тестирование периметра на уязвимости после обновления одного API и т.д. Но эти компромисы везде. Просто где-то они более формализированы (например в авиастроении, где очень развита методика сертификации), а где-то, как в программировании - принимается экспертное решение.
А тут часто уже вопрос к самим QA, которые не могут предложить оптимальный компромис, а понятно, что варианты в стиле "я буду перетестировать все" предсказуемо отправляются в урну.
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО
Как бы да, но нет. Есть види тестирования, есть много литературы на тему, как и что тестировать. Дальше вам решать, что тестировать и как. Тут теория не поможет, так как каждое ПО особенное. У всех разные функциональные требования, разная степень взаимной связности в виду, в том числе архитектуры ПО. У всех разные НЕ функциональные требования.
Тут надо работать
-------------------------------------
Я вот не понял одного. Автор вроде бы думает о "концепции тестирования". Пишет ее вначале, наверняка показывает всем. Т.е. все реально хорошо. Но почему то у него это не работает и тестирование "задвигается" в сторону. Может дело в качестве "концепции"?
------------------------------------
Про "МЭД" я не понял вобще. Цель тестирования - ответ на вопрос соответствия разработанного ПО требованиям. Т.е. скоуп совершенно понятен и определен. Откуда минимальное?
Ну хорошо, функции можно поделить на важные и не очень, или даже добавить много степеней важности. И проверять только на соответствие важным требованиям. Но это скорее крайняя мера в конце проекта, когда не успеваем
Grigorenkovic
12.12.2023 17:56Проблема создания качественного продукта глубже: преподаватели дают знания, но не дают навыков, как с ними работать дальше, кроме простых и зачастую далеких от реальности задач. Помню как испытывал трудности при изучении SQL, в основном потому что не понимал зачем все это до тех пор, пока не начал решать задачи с реальными данными. Только тогда возникло желание понять как все устроено и как я могу получить нужный мне результат
arTk_ev
12.12.2023 17:56Приходилось работать с топами, код писали по всем правилам чистого кода. С QA работали по парно и сидели за соседним столом.
Разработка настолько быстрая, что всю нашу тиму уволили. Помешали банкротству компании)
А вот каждый опыт работы на американские компании - всегда какой-то полный треш.
Обычно они неплохо платят, при этой работать вообще не надо, только 5мин митинга.
Ни о каком чистой коде, QA и разработке они не слышали.
NDA уже закончилось, теперь выложу их имена, их мутные схемы, и способы захвата компаний, схемы отмыва наркобабок с помощью донатов, про накрутку процентов в данатах, про внедрение идеи, про ящик скинера, и про их тупость.
Проблема системная. Разработка больший сложных систем требует специальнообученных архитекторов и системных аналитиков.
Вузы уже давно ничему не учат.
Ну и сами устаревшие императивные языки(с++, с# ) - являются корнем проблем с говнокодом.
Поэтому мы разработали новый язык, синергетический. Скоро анонсирует.
CodeRush
В производстве действительно качественного ПО самым главным механизмом обеспечения качества является не QA, и не TDD, и не прочие аббревиатуры, а предельно ясное понимание всеми участниками производства двух вещей:
- что именно производится
- каковы критерии успеха
Подавляющая часть современного ПО не производится, она выращивается из прототипов, которые затем переписываются на ходу, без какого-либо четкого плана, без критериев приемки, и без какой-либо цели кроме "может быть вот эта новая фича сделает еще полтора пользователя немного счастливее" или "может быть вот эта новая фича наконец приведет к повышению по карьерной лестнице". Фичи добавляются ради самих фич, разработка ведется ради самой разработки, каждые полгода меняется дизайн, все делается для удержания внимания пользователя, а не для решения его задач. И это все - неизбежно, потому что это приносит больше прибыли, и потому неизбежно задавит все альтернативы даже в самых зарегулированных нишах вроде автомобилестроения и авиации.
ПО - это не продукт, а сервис, и потому делать его законченным, цельным, отлаженным, быстрым, т.п. - не выгодно, потому что его купят один раз и будут пользоваться в таком виде. Поэтому жизненно необходимо выпускать новые версии, менять дизайн, добавлять фич, даже если продукт давно уже не просто "готов", а "трижды пережеван".
Всю эту индустрию, как и практически все остальные, пожирает один и тот же рак по имени "капитализм", и "нас не учили писать качественное ПО" - это потому, что никому не нужно качественное ПО, его очень дорого делать и оно никогда не принесет столько денег, сколько приносит некачественное ПО, которое получилось выпустить на рынок на полгода раньше, прорекламировать лучше, всучить хитрее, внедрить глубже и т.п. Некачественное ПО - это не вина исполнителей, это прямой результат того, что скорость доставки изменений (без лишних вопросов о том, если ли какой-то смысл в этих изменениях) - это главный критерий успеха.
Подход "move fast and break things" Цукерберга уже давно сожрал рынок ПО заживо, а вместо Computer Science и Software Engineering у нас теперь в основном Software Development и Continuous Delivery/Integration.
Ilusha
ПО это сервис - двумя руками за. Только не по по причине «купят один раз». А потому что потребность пользователей увеличиваются.
Каждый просто мечтает сделать «прогу», которую будут покупать и всё. И конкуренты не придут. И лучше никто не сделает.
фича ради фичи - ну это прогаммисты могут так сделать. Бизнес так не делает. Исключения бывают, но в них есть логика.
CodeRush
Над "потребности пользователя увеличиваются" работает нынче больше людей, чем собственно над ПО, закрывающим текущие потребности пользователей. Примерно 90% этих "потребностей" пользователю успешно навязаны извне, причем для этого используются самые грязные психологические трюки, FOMO, торговля "стилем жизни" и прочие эффективные приемы заставить пользователя в очередной раз купить продукт.
Новое значит лучшее, купи самый новый гаджет, а то будешь ходить со старым, как лох и нищеброд... Пацаны не поймут, девчонки отвернутся, покупай скорее, чего стоишь?! Вырази свою яркую индивидуальность при помощи цвета чехла и формы накладок на зеркала! Выделись из серой массы покупкой массового продукта! Ты этого достойна!
Пока что бизнес вокруг меня делает именно так, а тот, который не делает - либо очень нишевый, либо уже загнулся. Sun Microsystems вон делали хорошо - где они теперь? VmWare вон тоже неплохо делали, а теперь их купил бизнес побольше, и немедленно прекратил продажи бессрочных лицензий. Пользователь приучен этим же бизнесом к тому, что если продуктовая линейка не обновляется каждые полгода-год, значит производитель уже умер, потому что новое всегда лучше, чем такое же, только 200-400 дней назад. При этом тотальная эншитификация всего подряд - это, с точки зрения бизнеса, не просто отлично, а буквально необходимо, Diablo Immortal не даст соврать.
bert2000
Сан не делал хорошо. Он выбрасывал бабло на мифическую борьбу с Майкрософтом. Поддерживал Яву, одновременно плодя слухи о её свободе и проприетарности .нета
И как только солнце закатилось, оракля подмяла Яву под себя.
По это продукт. Сервисное по это отдельная модель. SaaS
un1t
Совсем мимо. Это как раз бизнес требует внедрять все новые и новые фичи на давая доделать как следует предыдущие. А некоторые фичи заставляет переделывать по 10 раз. В итоге все кривое косое, в костылях, доотлаживается прямо в проде.
lxsmkv
Я думаю тут не капитализм "виноват". Вон, если почитать протоколы с конференций пятидесятилетней давности --> http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
- там все тоже было забаговано :
Ведь понятно, что если мы хотим все качества по ISO 25010:
удобство пользования
отказоустойчивость
безопасность
функциональную полноту
производительность
совместимость
поддерживаемость / тестируемость
портируемость
по максимуму, то мы будем очень долго ждать этого продукта. Возможно до тех пор пока он не станет ненужным. Кроме этого, он скорее всего будет неоправданно дорогим в разработке.
И вот вы скажете причем тут стоимость разработки? Снижение "стоимости" это, мол, про капитализм. Вовсе нет. Стоимость это и трудозатраты. Это рациональное распределение ресурсов. Т.е. хочешь ли ты привязать лучшие умы страны к разработке очень качественной системы на 10 лет?
Поэтому ищут другие подходы. Как можно делать достаточно качественное ПО, доступными средствами. Всегда приходится чем-то жертвовать.
Ну и не надо забывать, что сегодня мы имеем высокоинтегрированные системы, и баги могут быть и присутствуют и в биосе и в операционной системе, и в библиотеках и в языке программирования, в инструментах. Т.е. то что вообще что-то работает это приблизительно чудо. Причем как я полагаю чудо это происходит по той причине что мы задействуем очень ограниченый спектр функций системы:
Как писал Edsger W. Dijkstra в Notes on Structured Programming (1970):
CodeRush
У меня нет никаких претензий к написанию достаточно качественного ПО доступными средствами, пока это ПО и мы сами находимся на одной стороне баррикад с пользователями этого ПО, и оба стремимся к общей цели.
Проблема же именно капитализма в том, что цель любой деятельности в нем - это получение прибыли, и не слишком важно, от кого эта прибыль получается, каким способом, насколько этот способ этичен, морален, человечен, эксплуатирует ли он самые животные потребности, использует ли "баги в прошивке" пользователей, и т.п. Там, где критерием успеха становится получение прибыли любой ценой, больше нет места заботе о пользователе, заботе о поставщике, заботе об окружающей среде, сохранению гомеостаза с остальной жизнью на планете, и т.п.
В результате действий "рациональных экономических агентов" уже сейчас большая часть ПО специально написана так, чтобы максимально затруднить его замену при наличии альтернатив, максимально привязать существующих пользователей к "платформе", максимально привязать денежные потоки к той же "платформе", использовать исключительно подписочную модель, запускать основную часть ПО исключительно у себя в облаке, чтобы пользователь не мог изучить ее или как-либо взаимодействовать с ней, решительно запретить изучение, декомпиляцию, дизассемблирование, обратную разработку, используя для этого любые инструменты, как программно-аппаратные, так и легально-маркетинговые, зачастую нанося прямой ущерб потребительским качествам собственного ПО.
Эпоха shareware закончилась, и вместо нее наступила эпоха платформ, в которой пользователь не владеет ничем, и вынужден платить постоянно, и теряет доступ к любой "купленной" продукции по мановению руки "правообладателя".
lxsmkv
Хм.. я понимаю эту аргументацию, что, мол, это целенаправленый "шантаж" со стороны производителей. Но, по принципу Бритвы Хэнлона, могу предложить и другую гипотезу:
Создать ПО заменяемым - можно. Кто заплатит за разработку этой возможности? Если этой возможностью воспользуется 0.02% пользователей, то не разбазаривание ли это ресурса?
Привязка к платформе - это интеграция. Гомогенные экосистемы это удобно для пользователя. Это снижает его трудозатраты на выполнение задачи. Есть конечно случаи где крупные игроки не могут договориться о стандартах. Например эта тема про RCS, где Гугл долго не могла склонить Эппл к поддержке технологии. Просто разный фокус, фирмы живут в разных мирах. То что важно одному, не важно другому. Вот например у Эппл есть Airdrop. И вообще не понятно, почему в винде такого нет. Я уверен, пользователи бы были в восторге от подобной функции, если бы она работала также просто. Но Майки этого не делают, хотя это увеличило бы привязку к платформе.
Поддержка систем платежей - тоже, уверен если бы это ничего не стоило все бы поддерживали все возможные системы платежей. Т.е. тут тоже нет никакой злонамеренности, простой рационализм. Правило Парето, например.
Подписочные модели - это сглаживание денежного потока, чтобы можно было держать штат. В играх тоже есть подписочные модели. Даже газеты эти аналоговые уже сколько лет предлагают подписочную модель. Людям удобно, что не надо мельтешить, куда-то бежать за обновлением. Тебе его доставят как только оно выйдет.
Использование облачных технологий - это эффективное использование вычислительных мощностей, это предоставление сервиса независимо от устройства пользователя. Это снижает затраты на поддержку разных платформ. Не для сокрытия кода это делают.
Защита кода от декомпиляции это в некоторой степени также мера по обеспечению безопасности. Security by obscurity. Так что тут тоже - как посмотреть.
Вот про авторское право возможно соглашусь - оно порой переходит все разумные границы. Патентный троллинг и все такое. Но это касается не только айтишной индустрии.
charypopper
Вопросы из 2ого абзаца вашего, противоречат тезису, что вы поняли аргументацию@CodeRush, да и дальше вы все время говорите про сокращение издержек и трудозатрат, "рациональность" и тп -- которые приводят к увеличению прибыли, а речь и о том что это единственный принцип капитализма для действия. Человек, который пишет ПО открытое антикапиталистичен в большинстве случаев, так как можно много где сократить издержки и выгода что он получает далека от максимальной, которую он бы мог извлечь из своих потраченных ресурсов (времени, мотивации, сил и тд вплоть до электричества копеешного). А тот движ в сторону опенсорса от крупных контор обусловлен нематериальными выгодами сопутствующими, это же показатель компетенций, зрелости компании, возможность отправить либу\продукт на ревью лучшим ученым и инженерам, и тому подобное, все это складывается в показатели для инвесторов, аргументы продаванам, лояльность на рынке труда от разрабов и тому подобное.
Ваши примеры о корпорациях, "то что важно одному неважно другому" это или конфликт интересов по деньгам, или нежелание выделять дефицитный ресурс без перспектив для прибыли в будущем - целые отделы сидят и считают какие перспективы, риски и прибыль итоговая при создании любых штук включая airDrop, и для apple это оправдано, а для майков - нет, потому что или издержки, или прибыль есть способы заработать получше, или ресурсов нет на разработку в соотношение прибыль\затраченные ресурсы. И то что вы понимаете про патенты, но ищите альтернативное объяснение в смежном вопросе от тех же участников процесса, говорит о том что лишь больше переменных в обеспечении максимизации прибыли и все эти процессы менее прозрачные
muxa_ru
И материальными тоже.
Открытый код и копилефт всю дорогу были способом одних корпораций забодать другие.
Ну и получить халявных разработчиков.
В этом случае очень показателен пример Mozilla:
в первой версии MPL было прямо написано "нам все права на то что вы там нам напишете, муа-ха-ха"
в основателях там люди из корпораций, пытавшихся забодать Microsoft
когда первая тусовка на сд.жила борьбу с Microsoft , пришёл Google и лил бабло и трафик на Firefox , а после того как Google сделал свой браузер и перестал лить бабло на Firefox, так тот и сдулся
Demon416
Чтобы писать качественное ПО быстро нужно начинать с качественного языка разработки и качественных программ для разработки, а что мы видим сейчас?
Подавляющее количество ПО пишется на языках родом из семидесятых с огромным грузом обратной совместимости, IDE деградировали, инструменты погрязли в аду несовместимых версий и неуместном применении пути юникса
kellas
Полностью согласен.
Как с этим смириться? Дело даже не в перфекционизме, прост какой-то постоянный диссонанс, вроде ты пишешь код и вроде нужно чтобы он хорошо работал, но одновременно с этим нужно делать быстрее и лучше плохо ) какой-то постоянный диссонанс.
CodeRush
На работе стараюсь и сам не писать говна, и не допускать говна к интеграции. Дома в свободное время пишу свободное ПО для души и вечности, самостоятельно управляя его качеством.
Не могу сказать, что прямо смирился полностью (не писал бы сюда ничего, если бы смирился), но пока что на качество результата никто не жаловался, и в основном хвалят, что на работе, что вне работы. Корпорация компенсирует свои хотелки деньгами, сообщество - признанием и уважением коллег.
Gryphon88
Приходите к нам в эмбеддед, тут есть уверенность, что готовый продукт проживет минимум год, и его действительно надо тестировать. Правда, платят почему-то сильно меньше...