Comments 44
В производстве действительно качественного ПО самым главным механизмом обеспечения качества является не QA, и не TDD, и не прочие аббревиатуры, а предельно ясное понимание всеми участниками производства двух вещей:
- что именно производится
- каковы критерии успеха
Подавляющая часть современного ПО не производится, она выращивается из прототипов, которые затем переписываются на ходу, без какого-либо четкого плана, без критериев приемки, и без какой-либо цели кроме "может быть вот эта новая фича сделает еще полтора пользователя немного счастливее" или "может быть вот эта новая фича наконец приведет к повышению по карьерной лестнице". Фичи добавляются ради самих фич, разработка ведется ради самой разработки, каждые полгода меняется дизайн, все делается для удержания внимания пользователя, а не для решения его задач. И это все - неизбежно, потому что это приносит больше прибыли, и потому неизбежно задавит все альтернативы даже в самых зарегулированных нишах вроде автомобилестроения и авиации.
ПО - это не продукт, а сервис, и потому делать его законченным, цельным, отлаженным, быстрым, т.п. - не выгодно, потому что его купят один раз и будут пользоваться в таком виде. Поэтому жизненно необходимо выпускать новые версии, менять дизайн, добавлять фич, даже если продукт давно уже не просто "готов", а "трижды пережеван".
Всю эту индустрию, как и практически все остальные, пожирает один и тот же рак по имени "капитализм", и "нас не учили писать качественное ПО" - это потому, что никому не нужно качественное ПО, его очень дорого делать и оно никогда не принесет столько денег, сколько приносит некачественное ПО, которое получилось выпустить на рынок на полгода раньше, прорекламировать лучше, всучить хитрее, внедрить глубже и т.п. Некачественное ПО - это не вина исполнителей, это прямой результат того, что скорость доставки изменений (без лишних вопросов о том, если ли какой-то смысл в этих изменениях) - это главный критерий успеха.
Подход "move fast and break things" Цукерберга уже давно сожрал рынок ПО заживо, а вместо Computer Science и Software Engineering у нас теперь в основном Software Development и Continuous Delivery/Integration.
ПО - это не продукт, а сервис, и потому делать его законченным, цельным, отлаженным, быстрым, т.п. - не выгодно, потому что его купят один раз и будут пользоваться в таком виде
ПО это сервис - двумя руками за. Только не по по причине «купят один раз». А потому что потребность пользователей увеличиваются.
Каждый просто мечтает сделать «прогу», которую будут покупать и всё. И конкуренты не придут. И лучше никто не сделает.
фича ради фичи - ну это прогаммисты могут так сделать. Бизнес так не делает. Исключения бывают, но в них есть логика.
Над "потребности пользователя увеличиваются" работает нынче больше людей, чем собственно над ПО, закрывающим текущие потребности пользователей. Примерно 90% этих "потребностей" пользователю успешно навязаны извне, причем для этого используются самые грязные психологические трюки, FOMO, торговля "стилем жизни" и прочие эффективные приемы заставить пользователя в очередной раз купить продукт.
Новое значит лучшее, купи самый новый гаджет, а то будешь ходить со старым, как лох и нищеброд... Пацаны не поймут, девчонки отвернутся, покупай скорее, чего стоишь?! Вырази свою яркую индивидуальность при помощи цвета чехла и формы накладок на зеркала! Выделись из серой массы покупкой массового продукта! Ты этого достойна!
Пока что бизнес вокруг меня делает именно так, а тот, который не делает - либо очень нишевый, либо уже загнулся. Sun Microsystems вон делали хорошо - где они теперь? VmWare вон тоже неплохо делали, а теперь их купил бизнес побольше, и немедленно прекратил продажи бессрочных лицензий. Пользователь приучен этим же бизнесом к тому, что если продуктовая линейка не обновляется каждые полгода-год, значит производитель уже умер, потому что новое всегда лучше, чем такое же, только 200-400 дней назад. При этом тотальная эншитификация всего подряд - это, с точки зрения бизнеса, не просто отлично, а буквально необходимо, Diablo Immortal не даст соврать.
Сан не делал хорошо. Он выбрасывал бабло на мифическую борьбу с Майкрософтом. Поддерживал Яву, одновременно плодя слухи о её свободе и проприетарности .нета
И как только солнце закатилось, оракля подмяла Яву под себя.
По это продукт. Сервисное по это отдельная модель. SaaS
Да, «над потребности увеличиваются» работают больше людей. Конечно да! И это же прекрасно. Создавать что-то лучшее, чем это было вчера.
«Купи новый гаджет, иначе ты лох» - эта маркетинговая стратегия стара как мир. Ничего нового. По сути - игра на человеческих комплексах. Но это лишь небольшая часть людей, которые таким способом закрывают свои психологические проблемы. Они всегда найдут способ, который поможет им стать счастливее, вместо того, чтобы пойти к психологу.
Им в противовес я наблюдаю других людей, которые наоборот кайфуют от «хорошей сделки»: выбить скидку, купить качественную поделку «бренда» на садоводе, за 5-10% цены оригинала, или просто качественную вещь. Добавим сюда мем «сяоми топ за свои деньги». Добавим сюда хейт айфонов, где люди искреннне не понимают «какого черта это стоит так дорого».
Бренды «стиль жизни» - это создание некоторой товарной экосистемы, которая за деньги позволяют тебе не думать: за тебя выбирают, а ты просто платишь, экономя время на поиски и выбор. По сути - плата за удобство. Одежда, еда, гаджеты, техника, ПО, услуги и т.д.
А про VMWare - хороший бизнес редко продают. Значит у них были проблемы. Это b2b. А их клиент-покупатель, бизнес голосует деньгами. И очень редко руководствуется эмоциями.
Мне кажется, вы ищите простое объяснение очень сложным процессам, происходящим в обществе(в широком смысле).
фича ради фичи - ну это прогаммисты могут так сделать.
Совсем мимо. Это как раз бизнес требует внедрять все новые и новые фичи на давая доделать как следует предыдущие. А некоторые фичи заставляет переделывать по 10 раз. В итоге все кривое косое, в костылях, доотлаживается прямо в проде.
Я думаю тут не капитализм "виноват". Вон, если почитать протоколы с конференций пятидесятилетней давности --> http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF
- там все тоже было забаговано :
Hopkins: We face a fantastic problem in big systems. For instance, in OS/360 we have about 1000 errors each release and this number seems reasonably constant.
[...]Schorr: It is not quite right that the rate is constant; it seems in fact to be slowly increasing!
(стр. 15)
Ведь понятно, что если мы хотим все качества по ISO 25010:
удобство пользования
отказоустойчивость
безопасность
функциональную полноту
производительность
совместимость
поддерживаемость / тестируемость
портируемость
по максимуму, то мы будем очень долго ждать этого продукта. Возможно до тех пор пока он не станет ненужным. Кроме этого, он скорее всего будет неоправданно дорогим в разработке.
И вот вы скажете причем тут стоимость разработки? Снижение "стоимости" это, мол, про капитализм. Вовсе нет. Стоимость это и трудозатраты. Это рациональное распределение ресурсов. Т.е. хочешь ли ты привязать лучшие умы страны к разработке очень качественной системы на 10 лет?
Поэтому ищут другие подходы. Как можно делать достаточно качественное ПО, доступными средствами. Всегда приходится чем-то жертвовать.
Ну и не надо забывать, что сегодня мы имеем высокоинтегрированные системы, и баги могут быть и присутствуют и в биосе и в операционной системе, и в библиотеках и в языке программирования, в инструментах. Т.е. то что вообще что-то работает это приблизительно чудо. Причем как я полагаю чудо это происходит по той причине что мы задействуем очень ограниченый спектр функций системы:
Как писал Edsger W. Dijkstra в Notes on Structured Programming (1970):
[...] The naive answer to this is: “Well, the number of different multiplications this multiplier is claimed to perform correctly is finite, viz. 2 ˆ54, so let us try them all". [...] the total time needed for this finite set of multiplications would add up to more than 10 000 years.
[...]
A first consequence of the 10 000 years is that during its life-time the multiplier will be asked to perform only a negligeable fraction of the vast number of all possible multiplications it could do: practically none of them! Funnily enough, we still require that it would do any multiplication correctly when ordered to do so.
У меня нет никаких претензий к написанию достаточно качественного ПО доступными средствами, пока это ПО и мы сами находимся на одной стороне баррикад с пользователями этого ПО, и оба стремимся к общей цели.
Проблема же именно капитализма в том, что цель любой деятельности в нем - это получение прибыли, и не слишком важно, от кого эта прибыль получается, каким способом, насколько этот способ этичен, морален, человечен, эксплуатирует ли он самые животные потребности, использует ли "баги в прошивке" пользователей, и т.п. Там, где критерием успеха становится получение прибыли любой ценой, больше нет места заботе о пользователе, заботе о поставщике, заботе об окружающей среде, сохранению гомеостаза с остальной жизнью на планете, и т.п.
В результате действий "рациональных экономических агентов" уже сейчас большая часть ПО специально написана так, чтобы максимально затруднить его замену при наличии альтернатив, максимально привязать существующих пользователей к "платформе", максимально привязать денежные потоки к той же "платформе", использовать исключительно подписочную модель, запускать основную часть ПО исключительно у себя в облаке, чтобы пользователь не мог изучить ее или как-либо взаимодействовать с ней, решительно запретить изучение, декомпиляцию, дизассемблирование, обратную разработку, используя для этого любые инструменты, как программно-аппаратные, так и легально-маркетинговые, зачастую нанося прямой ущерб потребительским качествам собственного ПО.
Эпоха shareware закончилась, и вместо нее наступила эпоха платформ, в которой пользователь не владеет ничем, и вынужден платить постоянно, и теряет доступ к любой "купленной" продукции по мановению руки "правообладателя".
Хм.. я понимаю эту аргументацию, что, мол, это целенаправленый "шантаж" со стороны производителей. Но, по принципу Бритвы Хэнлона, могу предложить и другую гипотезу:
Создать ПО заменяемым - можно. Кто заплатит за разработку этой возможности? Если этой возможностью воспользуется 0.02% пользователей, то не разбазаривание ли это ресурса?
Привязка к платформе - это интеграция. Гомогенные экосистемы это удобно для пользователя. Это снижает его трудозатраты на выполнение задачи. Есть конечно случаи где крупные игроки не могут договориться о стандартах. Например эта тема про RCS, где Гугл долго не могла склонить Эппл к поддержке технологии. Просто разный фокус, фирмы живут в разных мирах. То что важно одному, не важно другому. Вот например у Эппл есть Airdrop. И вообще не понятно, почему в винде такого нет. Я уверен, пользователи бы были в восторге от подобной функции, если бы она работала также просто. Но Майки этого не делают, хотя это увеличило бы привязку к платформе.
Поддержка систем платежей - тоже, уверен если бы это ничего не стоило все бы поддерживали все возможные системы платежей. Т.е. тут тоже нет никакой злонамеренности, простой рационализм. Правило Парето, например.
Подписочные модели - это сглаживание денежного потока, чтобы можно было держать штат. В играх тоже есть подписочные модели. Даже газеты эти аналоговые уже сколько лет предлагают подписочную модель. Людям удобно, что не надо мельтешить, куда-то бежать за обновлением. Тебе его доставят как только оно выйдет.
Использование облачных технологий - это эффективное использование вычислительных мощностей, это предоставление сервиса независимо от устройства пользователя. Это снижает затраты на поддержку разных платформ. Не для сокрытия кода это делают.
Защита кода от декомпиляции это в некоторой степени также мера по обеспечению безопасности. Security by obscurity. Так что тут тоже - как посмотреть.
Вот про авторское право возможно соглашусь - оно порой переходит все разумные границы. Патентный троллинг и все такое. Но это касается не только айтишной индустрии.
Вопросы из 2ого абзаца вашего, противоречат тезису, что вы поняли аргументацию@CodeRush, да и дальше вы все время говорите про сокращение издержек и трудозатрат, "рациональность" и тп -- которые приводят к увеличению прибыли, а речь и о том что это единственный принцип капитализма для действия. Человек, который пишет ПО открытое антикапиталистичен в большинстве случаев, так как можно много где сократить издержки и выгода что он получает далека от максимальной, которую он бы мог извлечь из своих потраченных ресурсов (времени, мотивации, сил и тд вплоть до электричества копеешного). А тот движ в сторону опенсорса от крупных контор обусловлен нематериальными выгодами сопутствующими, это же показатель компетенций, зрелости компании, возможность отправить либу\продукт на ревью лучшим ученым и инженерам, и тому подобное, все это складывается в показатели для инвесторов, аргументы продаванам, лояльность на рынке труда от разрабов и тому подобное.
Ваши примеры о корпорациях, "то что важно одному неважно другому" это или конфликт интересов по деньгам, или нежелание выделять дефицитный ресурс без перспектив для прибыли в будущем - целые отделы сидят и считают какие перспективы, риски и прибыль итоговая при создании любых штук включая airDrop, и для apple это оправдано, а для майков - нет, потому что или издержки, или прибыль есть способы заработать получше, или ресурсов нет на разработку в соотношение прибыль\затраченные ресурсы. И то что вы понимаете про патенты, но ищите альтернативное объяснение в смежном вопросе от тех же участников процесса, говорит о том что лишь больше переменных в обеспечении максимизации прибыли и все эти процессы менее прозрачные
А тот движ в сторону опенсорса от крупных контор обусловлен нематериальными выгодами сопутствующими
И материальными тоже.
Открытый код и копилефт всю дорогу были способом одних корпораций забодать другие.
Ну и получить халявных разработчиков.
В этом случае очень показателен пример Mozilla:
в первой версии MPL было прямо написано "нам все права на то что вы там нам напишете, муа-ха-ха"
в основателях там люди из корпораций, пытавшихся забодать Microsoft
когда первая тусовка на сд.жила борьбу с Microsoft , пришёл Google и лил бабло и трафик на Firefox , а после того как Google сделал свой браузер и перестал лить бабло на Firefox, так тот и сдулся
Чтобы писать качественное ПО быстро нужно начинать с качественного языка разработки и качественных программ для разработки, а что мы видим сейчас?
Подавляющее количество ПО пишется на языках родом из семидесятых с огромным грузом обратной совместимости, IDE деградировали, инструменты погрязли в аду несовместимых версий и неуместном применении пути юникса
Полностью согласен.
Как с этим смириться? Дело даже не в перфекционизме, прост какой-то постоянный диссонанс, вроде ты пишешь код и вроде нужно чтобы он хорошо работал, но одновременно с этим нужно делать быстрее и лучше плохо ) какой-то постоянный диссонанс.
На работе стараюсь и сам не писать говна, и не допускать говна к интеграции. Дома в свободное время пишу свободное ПО для души и вечности, самостоятельно управляя его качеством.
Не могу сказать, что прямо смирился полностью (не писал бы сюда ничего, если бы смирился), но пока что на качество результата никто не жаловался, и в основном хвалят, что на работе, что вне работы. Корпорация компенсирует свои хотелки деньгами, сообщество - признанием и уважением коллег.
Приходите к нам в эмбеддед, тут есть уверенность, что готовый продукт проживет минимум год, и его действительно надо тестировать. Правда, платят почему-то сильно меньше...
Должно быть как автотестирование, так и QA. В идеале один спринт на разработку + юниттесты, второй спринт на QA + functional + acceptance тесты.
Основную часть времени тратят на изучение алгоритмов, принципов работы компьютера, историю каких-то языков и концепций и так далее.
А это значит, что логику написания качественного надо зашить в эти самые "концепции" - https://habr.com/ru/articles/776550/ .
Увы и ах, в современном мире, айтишник это не вершина интеллектуальной цепи, а один из массовых работников, недостаточно квалифицированный и достаточно индифферентный по отношению к тому что он делает.
Для начала надо надрючить всех ваших разработчиков на то, чтобы ВСЁ ПО писалось исключительно в стиле "защитного программирования".
Вам нужен аналог assert(), не исключающийся из релизного продукта, и абсолютно во всех случаях, когда есть какое-то условие или возвращаемое значение - оно должно быть проверено или нормальным кодом проверки ошибки, или добавлением неисключаемого из кода assert(). Который должен фиксировать строку/функцию/условие/файл/версию файла.
Таким образом, ваше ПО никогда не должно распространять ошибку дальше.
Использование исключений из кода удалить полностью - точнее, оставить только в модульных тестах.
Ваша программа/модуль должна немедленно паниковать (с сохранением стека и дампа) как только обнаружена ошибка, для которой не предусмотрены штатные условия устранения/восстановления.
Да, и ещё: заставьте своих разработчиков использовать достаточно старый стандарт языка. Ещё лучше: ограничьте используемое множество языка.
Разработчиков, которые тащатся от новейших фич языка - выпихивайте туда, где от них будет минимум вреда - желательно к конкурентам.
В общем, пишите медленно, дорого и так, чтобы программа у клиента падала в случае, если баг попадет в версию. Ну что, ок.
Ну да, ну да.
Пишите быстро, дёшево, и чтобы программа у клиента не падала ни в коем случае, зато глючила так, чтобы никто концов не нашёл.
Даже подскажу: обкручивайте всё try-catch, и игнорируйте все исключения. Продукт получится охренительный!
Вот сарказм разработчикам в 2023 не особо к лицу, когда большинство парадигм и инструментов уже доказали, в каких отраслях и условиях их стоит использовать (а когда - нет). Ваш подход вполне хорош, вот только желательно и его сужать до реального применения (но, к сожалению, в бизнесе сидят такие же люди, как программисты, с идеями).
Использование исключений из кода удалить полностью - точнее, оставить только в модульных тестах.
Ваша программа/модуль должна немедленно паниковать (с сохранением стека и дампа) как только обнаружена ошибка, для которой не предусмотрены штатные условия устранения/восстановления.
А что значит паниковать в вашем понимании? И что вы понимаете под исключениями?
И что это за "assert()"? Какая-то магическая функция?
В вузе и не должны учить писать качественное ПО. Эти навыки вы получаете на отработках и первой работе, именно поэтому бесполезно начинать работу с ООО "Рога и Копыта". Вас учат науке, если вы хотите писать код вам в техникум надо было.
В вузе по IT выдают бесформенный комок наукоподобных фактов для зубрения. Он чем-то неуловимо похож на те комки шерсти, что иногда выдаёт кот. Разрабатывать По не научат точно, это да. Если в техникуме по-другому (не знаю, не был) то будущему программисту действительно лучше в техникум.
Почему не должны? А почему на первой работе должны уметь? А почему там должны учить?
Вуз решает задачу подготовки кадров, которые необходимы индустрии. Сейчас это он делает плохо.
Когда вузы начнут делать это хорошо, тогда мы увидим серьезное изменение рынка труда. Когда условный джун сможет писать качественный код.
Сейчас это он делает плохо.
"Забудьте всё, чему вас учили в институте" - эта формула старше чем некоторые из преподавателей современных ВУЗов.
Отличная формула, чтобы пожалеть о потраченном времени!
Не «формула», а шуточная присказка.
Её шуточность преувеличена.
В том числе потому, что реальные практики адаптированы к узким условиям реальных задач, а в ВУЗах должны давать широкий спектр знаний.
В вузе должны давать широкие знания чтобы вы могли вообще осознавать все варианты решения узкой проблемы и чтобы вы тратили время исключительно на изучение специфики задач и областей вместо "ah shit, here we go again" от смены языка, фреймворка или финтеха на геймдев/медицину.
ВУЗ дает специальность, а не профессию. Болонская система еще шире.
Возможно, только в химии осталось еще «забудьте школу», потому что в школе учат не очень правильно, что-ли. Упрощенно.
Знакомые, в компании которая занимается производством, когда искали выпускника, конкретно гоняли их на собесе по дисциплинам вуза.
Реальные практики не отменяют, а дополняют.
Программисту после универа говорят «забудь ооп, сети, реляционную алгебру»? Юристу «забудь римское право»? Инженеру «забудь сопромат»? Что должен забыть математик? А бухгалтер?
Эта фраза «забудьте …», она имеет смысл только в одном случае: необходимость сказать, что паттерны и мироустройство шире известных знаний. Например, что ньютонов в механика не работает на масштабах. Или что на ноль делить можно. Когда нужно сказать «откройте разум».
Ирония в том, что именно это ожидают от вуза и студенты и работодатели. Те граждане, которые хотят заниматься наукой идут специальные научные вузы, типа мгу, а большинству не надо этих лавров, они хотят создавать. Само-собой, что это еще понимать надо, и часто в мгу идут учиться писать код, а в мытищинский лесотехнический заниматься наукой. Ну так кто бы это еще объяснял молодёжи вовремя. Кстати, я не знаю, где учат писать хороший код в техникумах, чтобы "в любое дело гож, в любые двери вхож", в нашем техникуме программисты на выходе не способны, например написать игру с графикой уровня, какой в нашем вузе дают на курсовой на 3 курс. Максимум что из них выходит это переспективные эникеи, если будут продолжать образовываться дома и на работе. Т.е. он как собака: все понимает, сказать ничо не может, но лицо как бы смышленое, а делает - что попало, обычно - не то. Но у меня выборка маленькая. Может, где-то вузы настолько днище, что там тоже игры с графикой это космос, а выпускники техникумов в топ андроид-скачиваний. Причем по медианной, а не самородки, которым с рождения череп жмет. Я по ЗП еще знаю, что преподы айтишники в техникумах принципиально получают как неудачники, я иногда прохожу мимо техникума, там преподу по ИТ предлагают 30-40+ до вычетов, прям в окне объявление. Оно там давно висит, только по чуть-чуть цифры увеличивают. А раз так, это надо быть настоящим мммм фанатом святпросвета, чтобы вместо 1500000 бксов в наносек идти в образование за печенюшку к празднику.
А ирония в том, что эту глыбу не сдвинуть. Чтобы что-то изменить, это должно идти из самого верха: перетрясти учебные планы как минимум. А учебные планы у нас пока из прямиком из СССР, только научный коммунизм поменяли на физкультуру. Это про вузы. Про техникумы не знаю. Так вот Минобр как-то не замечен в инновациях в вузах, не популистких "мы купили 3д принтер", а вот чтобы выкинуть 90% гуманитарки, например, или химию у программистов отменить, да и начерталку тоже, а вместо этого запихать им туда солид с Барбарой и углубленное до гланд изучение линукса, докера, кубернетиса и прочих аджайлов. Ну либо опять же волевым решением перелопатить учебные планы техникумов и объявить: "граждане, наши вузы не учат программированию, для этого есть техникумы: не мучайтесь сами и не мучайте других. Либо езжайте в МИТ, там есть очень неплохие программы! (А у нас свой собственный путь парадоксов друг".
Сложные задачи имеют более одного правильного решения, оптимальность которых зависит от применяемых критериев оценки. Возможно, что автор оригинала Florian Bellmann просто никогда не работал в проектах, где требовалось писать качественный софт. Кстати, как тут правильно заметили в комментах, при капитализме самый популярный критерий оценки правильности решения сложных задач - прибыль от инвестиций.
Проблема в том, что просто нет столько разработчиков, которые способны к высококачественной разработке. Ну вот нет их в товарных количествах. Очень мало. Хорошо разрабатывать сложно, этому учить надо.
В целом это напоминает ситуацию, когда в 19 веке, маститые врачи отказывались мыть руки между вскрытием и принятием родов. Объяснения были примерно такие же, в стиле "а зачем это лишнее действие, мы больше людей вылечим если не мыть руки".
Способных дохрена. Обученных нет. И программ обучения нет. Нет качественных схем передачи опыта.
В узких направлениях даже информацию собираешь по крупицам.
Плюс информация быстро устаревает.
Самое попсовое - веб-разработка(фронт + бэк). Задыхается от сложности уже на уровне небольшого продукта, который выглядит как «за неделю сделаю MVP”.
Вы когда-нибудь участвовали в проекте разработки ПО, в котором отсутствовали жизненно необходимые меры по обеспечению качества? Вы в этом не одиноки.
Мне кажется, автору просто не повезло. Я большую часть времени работаю в Enterprise проектах. Честно говоря, вспомнить примеры, когда на QA часть кто-то забивал практически нереально. Т.е. вопрос о каком-либо сокращении этого участка наверное не ставился никогда.
Просто все понимают, что ошибки потом вылезут дороже. пБывает конечно, когда либо проект совершенно распильный, либо ... ну не знаю, внутренний продукт для трех барышен из HR - тогда да.
Но надо тоже понимать, что тестирование очень сильно разное и это всегда компромис. Вы не делаете полный регресс после каждой запятой, вы не проводите полное тестирование периметра на уязвимости после обновления одного API и т.д. Но эти компромисы везде. Просто где-то они более формализированы (например в авиастроении, где очень развита методика сертификации), а где-то, как в программировании - принимается экспертное решение.
А тут часто уже вопрос к самим QA, которые не могут предложить оптимальный компромис, а понятно, что варианты в стиле "я буду перетестировать все" предсказуемо отправляются в урну.
Проблема в том, что при изучении computer science вас не учат, как обеспечить стандарты качества ПО
Как бы да, но нет. Есть види тестирования, есть много литературы на тему, как и что тестировать. Дальше вам решать, что тестировать и как. Тут теория не поможет, так как каждое ПО особенное. У всех разные функциональные требования, разная степень взаимной связности в виду, в том числе архитектуры ПО. У всех разные НЕ функциональные требования.
Тут надо работать
-------------------------------------
Я вот не понял одного. Автор вроде бы думает о "концепции тестирования". Пишет ее вначале, наверняка показывает всем. Т.е. все реально хорошо. Но почему то у него это не работает и тестирование "задвигается" в сторону. Может дело в качестве "концепции"?
------------------------------------
Про "МЭД" я не понял вобще. Цель тестирования - ответ на вопрос соответствия разработанного ПО требованиям. Т.е. скоуп совершенно понятен и определен. Откуда минимальное?
Ну хорошо, функции можно поделить на важные и не очень, или даже добавить много степеней важности. И проверять только на соответствие важным требованиям. Но это скорее крайняя мера в конце проекта, когда не успеваем
Проблема создания качественного продукта глубже: преподаватели дают знания, но не дают навыков, как с ними работать дальше, кроме простых и зачастую далеких от реальности задач. Помню как испытывал трудности при изучении SQL, в основном потому что не понимал зачем все это до тех пор, пока не начал решать задачи с реальными данными. Только тогда возникло желание понять как все устроено и как я могу получить нужный мне результат
Приходилось работать с топами, код писали по всем правилам чистого кода. С QA работали по парно и сидели за соседним столом.
Разработка настолько быстрая, что всю нашу тиму уволили. Помешали банкротству компании)
А вот каждый опыт работы на американские компании - всегда какой-то полный треш.
Обычно они неплохо платят, при этой работать вообще не надо, только 5мин митинга.
Ни о каком чистой коде, QA и разработке они не слышали.
NDA уже закончилось, теперь выложу их имена, их мутные схемы, и способы захвата компаний, схемы отмыва наркобабок с помощью донатов, про накрутку процентов в данатах, про внедрение идеи, про ящик скинера, и про их тупость.
Проблема системная. Разработка больший сложных систем требует специальнообученных архитекторов и системных аналитиков.
Вузы уже давно ничему не учат.
Ну и сами устаревшие императивные языки(с++, с# ) - являются корнем проблем с говнокодом.
Поэтому мы разработали новый язык, синергетический. Скоро анонсирует.
Мне нравится термин «минимальная эффективная доза» (МЭД). Это минимальная доза, дающая желаемый результат.
Товарищ Парето определил же эту минимальную дозу.
20% усилий дают 80% результата.
Никто никогда не учит писать качественный софт