По мере взросления человеку требуется поддержка. В начале это ходунки jQuery, потом костыли Angular.
Большинство перерастает этот этап и осознаёт что данная поддержка им более не нужна, и можно просто тяп ляп и в продакшен.
Меньшинство растёт дальше, до осознания: стандартов, требования бизнеса, в том числе к заменяемости сотрудников(опять же стандарты), или поддержке с прогнозируемым временем на внесение изменений и там или иначе приходит к четкой структуре, я бы даже сказал диктатуре, кода.
Хотя буду честен - в то время как Angular это именно диктатура структуры кода, чего очень не хватает рандомным React приложениям, многие основополагающие принципы, следуя которым эта диктатура может сделать «хорошо», товарищи проигнорировали.
1) Когда отапливается кондиционером — то это вообще полная жесть.
HeatPumps, или Ducted Air conditioners как их чаще называют тут, на каждый 1кв электричества дают 5кв тепла. Ими даже бассейны греют.
Плюс половина домов даже зимой могут питать кондеры с солнечных батарей, которых тут очень много
2) через несколько часов за окном меняется язык, менталитет, архитектура
Едем вверх — меняется — начинается "white australia"
Едем влево — меняется — там горы и старые города
Едем вниз — меняется — там больше зелени и раслабона
"Качество" местных "домов" — два термина в кавычках. Совершенно не понятно о чем думали люди когда строили себе жилье, но точно не о зиме (она тут есть), и не о лете (и она тут есть)
Насколько я знаю Curiosity написан на state-charts, которые вообще не так чтобы язык программирования, зато надежности дает — огого! Boingи вроде летают на Rational Tau, которые в ядре своем — SDL диаграммы.
Окей — в Rust например система типов достаточно ясно дает понять, когда ты не прав. Но то никоим образом не защищает от того, что бы просто делаешь что-то не так чтобы очень правильно.
Слои юнит тестирования не исключают друг друга.
Тем же датчикам надо ещё физические тесты устраивать, когда жестокая реальность(кривой пайки) потопчется по полностью протестированному коду.
Но ведь именно это главный аргумент сторонников TDD, которые были упомянуты в самом начале.
Если кратко резюмировать их логику — написание тестов отдельно/после кода требует сильно больше времени и сил через правильное написание кожа и тестов в параллель.
Те результаты статьи совершенно правильные — написание тестов классическим образом — пустая трата времени и денег.
Быть может их просто как-то по другому писать надо?
Если плана нет, это будет приводить к большому количеству исправлений, зачёркиваний (на бумаге) и переписыванию больших кусков кода.
По своему опыту могу сказать, что умение писать "по плану" является признаком плохого программиста. Это называется Остапа понесло.
Закрыть скобочку, вынести код во внешнюю функцию, зафиксировать интерфейс, написать тестик и только потом продолжить работу — в общем делать много исправлений — признак хорошего. Конечный код выйдет лучше и быстрее.
Разница тут как между нарисовать сову методом scan line, и "итеративным" классическим образом. Можно даже сказать — по agile.
Коллективное бессознательное давным давно записало Ерика в TDD-наркоманы, и его зацикленность на этом немного подтвержает тот факт, что он более продает себя (кому?), чем обьясняет или двигает технологию в массы.
Буду честен — я прочитал все его статьи, и продолжаю почитывать как они выходят (это не так просто, так как он постоянно перепубликовывает старые). Ничего полезного за последний год там не было.
Зато без «сюрпризов» - в библиотеках основанных на Proxy каждые пару лет находят по паре багов и их решение часто стоит скорости.
Писал про что-то похожее, примерно теми же словами 5 лет назад - https://blog.cloudboost.io/why-react-is-better-than-vue-js-and-when-9545049652d8
Главная проблема была в том что я думал - «я знаю React» и могу его использовать. Могу честно признать - был не прав.
По мере взросления человеку требуется поддержка. В начале это ходунки jQuery, потом костыли Angular.
Большинство перерастает этот этап и осознаёт что данная поддержка им более не нужна, и можно просто тяп ляп и в продакшен.
Меньшинство растёт дальше, до осознания: стандартов, требования бизнеса, в том числе к заменяемости сотрудников(опять же стандарты), или поддержке с прогнозируемым временем на внесение изменений и там или иначе приходит к четкой структуре, я бы даже сказал диктатуре, кода.
Хотя буду честен - в то время как Angular это именно диктатура структуры кода, чего очень не хватает рандомным React приложениям, многие основополагающие принципы, следуя которым эта диктатура может сделать «хорошо», товарищи проигнорировали.
А что случилось с проблемой 1? История прерывается на самом интересном месте!
На самом деле эта строчка стоит целой статьи.
можно попросить немного развить мысль?
Без особых проблем:
https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BF%D0%BB%D0%BE%D0%B2%D0%BE%D0%B9_%D0%BD%D0%B0%D1%81%D0%BE%D1%81#%D0%9E%D0%B1%D1%89%D0%B8%D0%B5_%D1%81%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D1%8F
Да, но не совсем
1) Когда отапливается кондиционером — то это вообще полная жесть.
HeatPumps, или Ducted Air conditioners как их чаще называют тут, на каждый 1кв электричества дают 5кв тепла. Ими даже бассейны греют.
Плюс половина домов даже зимой могут питать кондеры с солнечных батарей, которых тут очень много
2) через несколько часов за окном меняется язык, менталитет, архитектура
Едем вверх — меняется — начинается "white australia"
Едем влево — меняется — там горы и старые города
Едем вниз — меняется — там больше зелени и раслабона
"Качество" местных "домов" — два термина в кавычках. Совершенно не понятно о чем думали люди когда строили себе жилье, но точно не о зиме (она тут есть), и не о лете (и она тут есть)
В Сиднее небо всегда голубое, море синее, а деревья зеленые.
Скукота
Конечно же это неправда, более того — неправда два раза
Так что можно продолжать использовать старый добрый script.
Окей — в Rust например система типов достаточно ясно дает понять, когда ты не прав. Но то никоим образом не защищает от того, что бы просто делаешь что-то не так чтобы очень правильно.
Именно по этому самые глюченный системы были написаны на строго типизированных языках.
Слои юнит тестирования не исключают друг друга.
Тем же датчикам надо ещё физические тесты устраивать, когда жестокая реальность(кривой пайки) потопчется по полностью протестированному коду.
Но ведь именно это главный аргумент сторонников TDD, которые были упомянуты в самом начале.
Если кратко резюмировать их логику — написание тестов отдельно/после кода требует сильно больше времени и сил через правильное написание кожа и тестов в параллель.
Те результаты статьи совершенно правильные — написание тестов классическим образом — пустая трата времени и денег.
Быть может их просто как-то по другому писать надо?
Уже более трех лет проживаю в Австралии и местные "нативы" с тобой не согласятся:
Прости незнакомец, но писать такие вот статейки для меня самый лучший способ писать их лучше.
Вот так делать не надо. Этот момент следует автоматизировать и показывать визуальные дифы, если они есть.
В банд будет добавляться тот код, что использовался когда-либо — https://github.com/webpack/webpack/issues/4453
По своему опыту могу сказать, что умение писать "по плану" является признаком плохого программиста. Это называется Остапа понесло.
Закрыть скобочку, вынести код во внешнюю функцию, зафиксировать интерфейс, написать тестик и только потом продолжить работу — в общем делать много исправлений — признак хорошего. Конечный код выйдет лучше и быстрее.
Разница тут как между нарисовать сову методом scan line, и "итеративным" классическим образом. Можно даже сказать — по agile.
Буду честен — я прочитал все его статьи, и продолжаю почитывать как они выходят (это не так просто, так как он постоянно перепубликовывает старые). Ничего полезного за последний год там не было.