Comments 22
Надеюсь, достаточно сильный AI скоро напишет относительно невысокую абстракцию, которая все стандартизирует и всех со всеми помирит.
В парадигме чистой архитектуры фреймворк это инфраструктура проекта, о которой есть смысл вспомнить в последнюю очередь, после того как будет разработан функционал. Создавая проект используя парадигму чистой архитектуры, нет смысла смотреть, что внутри фреймворка, как и любой библиотеки или пакета. В тоже время есть смысл создавать безопасные приложения и для этого есть смысл проверить библиотеку или фреймворк на безопасность или доверится информации из сети. Но просматривать все что приходит из компосера... только за деньги за деньги бизнеса.
Но в этом, кажется, и весь посыл статьи, что мы слишком многое заметаем под ковёр «инфраструктуры проекта, о которой есть смысл вспомнить в последнюю очередь», в то время как бизнес от нас требует разработки функционала и как можно скорее.
На своём опыте я такое видел в нескольких крипто(валютных)-проектах. Даже если проект не является запланированным скамом, то требования «релиза да побыстрее» часто приводят к печальным последствиям...
Смысл фреймворка в том числе и в том, чтобы разрабатывать используя код. Если нет доверия к фреймворку, можно выбрать другой или запилить что-то свое. В последнем случае не факт что получится лучше фреймворка. Также может быть небезопасно железо. В прочем кто, что заказывает и кто за что платит, тот то и получает.
Смысл фреймворка в том числе и в том, чтобы разрабатывать используя код.
Мне совершенно не понятно что это значит.
Фреймворк предлагает некоторый "способ разработки".
В теории - "хороший" подходящий вам и достаточно безопасный.
На практике - выясняется что таке фреймворки часто сырые (что уменьшает его преимущества). Его недостатки, в этом случае всё равно остаются.
В парадигме чистой архитектуры фреймворк это инфраструктура проекта, о которой есть смысл вспомнить в последнюю очередь, после того как будет разработан функционал.
когда от красивых слов перейдешь к практике в реальной компании, с коллегами, руководством, сроками, процессами — все это посыпется сквозь пальцы, и не поймаешь
Где-то здесь должна быть ссылка на закон дырявых абстракций.
@evil_HFT, спасибо за качественный перевод.
Описанная проблема характерна не только для it, но и например для инжиниринга - использование высокоуровневых абстракций (трёхмерных конечно-элементных расчетов) привело к тому, что многие инженеры забили на физику и расчеты в 1д (на бумажке, в Экселе и тд) при этом совершенно не интересуясь какие ограничения есть у физических моделей в новомодных "черных ящиках" и как там все работает. Компуктер посчитал и все ок. И так оно много где.
Ох уж эти тёплые ламповые расчёты на бумажке в качестве альтернативы холодным и бездушным решателям на конечных элементах.
Ведь как сакрализировать умение пользоваться конечно-элементным решателем? Особо никак: "я тут знаю секретную кнопку, ускоряющую всё в 1000 раз, про которую не рассказано в хелпе" - сомнительно и, главное, не архетипично.
Вот с аналитическими формулами - всё совсем по-другому! "Я знаю Секретную Формулу, которую прочёл в Священной Книге" - это прям позволяет почувствовать себя Гендельфом инженерии.
Тут, правда, вот какое дело
- простая аналитика, типа I=U/R, осталась в школе.
- чуть более сложная аналитика для простейших случаев, типа Z0=60/sqrt(e) * ln(Rэк/Rж), требует некоторых операций сверх сложения, вычитания, умножения и деления.
Будем на бумажке извлекать натуральный логарифм?
- чуть более сложная аналитика для практических случаев, представляет из себя полуэмпирическую подгонку под ответ со всякими прикольными ограничениями. Так, для импеданса копланарной линии есть, типа, аналитическая формула, которая сносно работает, если отношение ширины линии к толщине печатной платы лежит между 0,1 и 2,0. Что будет, если это отношение 1,99 или 2,01 - "ну-уэ-э-э, там смотреть надо". Весёлые операции, разумеется, никуда не деваются.
Можно было бы задаться вопросом: и в чём же тогда различие между конечно-элементным решателем и Excel, в который вбили полуэмпирическую формулу, с прикольными ограничениями по входным параметрам и операциями, которые всё равно не будут пересчитывать вручную? Ведь с точки зрения влияния на некое "понимание глубинных процессов" оба подхода практически идентичны. Как представляется, различия всё же есть. И они в следующем:
1. МКЭ при вполне допустимом времени вычислений, по точности уделает аналитику в хлам.
2. Но при этом из МКЭ не получится сделать косплей 1950-х годов - своего рода Dark Academia для инженеров.
@evil_HFT , спасибо за редкий в последнее время пост о здравом смысле.
Все эти недо-девопсы , не понимающие в основной массе "что там под капотом", вызывают только досаду и злость. Реальных девопсов - единицы на тысячу. Я знаю буквально пару-тройку. Основная масса - безответственные понторезы.
"Раработчики", а в реалии формошлёпы, из той же оперы.
Тенденции к обесцениванию инженерных навыков очень печальные и эти вопросы надо поднимать.
Ох уж эти эксперты из скорлупки со своими советами. Когда им тыкаешь, мол вон, Go всё популярнее с каждыйм годом, уже большая часть облаков на нём, а там куда ни плюнь - всё слайс (динамический массив) байт, буквально. А они "да это не при чём, Go популярен из-за пиара Google". На вопрос "как именно Google пиарит Go?" всегда тишина. Всегда.
Имхо всё в конце концов упирается в решение бизнес целей, в спрос и предложение. Держать штат людей, полностью разбирающихся во всех уровнях абстракций невыгодно и зачастую нецелесообразно. Держать штат людей умеющих работать только на самом высоком уровне абстракций - гораздо выгоднее с экономической точки зрения, ровно до того момента когда понадобится специалист, способный копнуть поглубже. Оптимум будет где-то между этими двумя крайностями.
"Сегодня «программистов» и «системных администраторов» практически не существует" - существуют. Причём в 99.9% компаний админ адмтнит только почту и файловый сервер, а в промежутках меняет картриджи и устраняет замятие в принтерах. И не этом все, никаких задач из "devops" никогда за всю жизнь. Видимо автор работал толко в ИТ-компаниях (обычных которых большинство, из-за чего и конкуренция в ИТ конторы по 100-200 человек на место), не в обычных. Что делает програмист не в ИТ компании это вообще отдельный эпос.
используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным,как обезьяна с динамометрическим ключом, когда что-то пойдет не так.
Для чего полезным то? Нет смысла ни в чем, разработчик работает всегда на компанию, а не на свои интересы. И ради зарплаты продвигает жизнь на работе приближая смерть. И пользы в обычной жизни, все офиса, от разработчика 0. Тут даже какой-нибудь учитель математике, интсрутор по фитнесу будет полезнее обществу.
Omne nimium nocet - все хорошо в меру.
Индустрия до сих пор бурно развивается. И до сих пор очень сильно нехватает стандартизации.
Мало какому инжинеру-строителю приходится задумываться почему у разных марок стали разная прочность, температура плавления, и какую из них надо взять чтобы отлить болт и гайку для крепления каждой балки моста.
В софтостроении до сих пор нет устоявшихся стандартных языков и библиотек. Комитет по C++ клепает новые стандарты каждые три года, писатели компиляторов не успевают все это реализовать, писатели библиотек ломают голову как это все подружить с железом. Прикладники замучавшись каждый пилит свою библиотеку под свои задачи и окружение. И все это сверху густо намазывается вебом, в котором вообще кто в лес, кто по дрова, рожая фреймворки со скоростью рожающей крольчихи. На безопасность вообще все забили.
В сумме это все дает адские тормоза которое приходится купировать ежегодным апгрейдом железа. И капитализм, и рынок это все пока устраивает - задачи худо-бедно решаются, прибыль идет. Хакнули из-за дыр в безопасности - сами виноваты, почаще обновляйтесь и делайте бэкапы...
Возможно когда это все грохнется, а событие это уже маячит на горизонте, тогда и придут эффективные и стандартные решения для минимизации издержек. А пока имеем, что имеем.
Лайк за одно только название, вечером дочитаю.
Хотя в дороге на работу дочитал. Актуальная тема поднята.
Единственный вопрос, который хочется задать, прочитав такие статьи - "И чО?!"
Уже в начале прошлого века ни один человек не знал всю производственную цепочку производства обычного карандаша. В 21 веке есть математические теоремы, судя по всему - превышающие когнитивные возможности человеческого мозга - "ГРУППА математиков доказала" - повторить, или хотя бы полностью понять всю цепочку "в одного" - неа. Только верить.
Мир пронизан уровнями абстракции сверху донизу - и это касается далеко не только IT. Сделать с этим можно - ну примерно "ничего", оно все и везде так. Посыл "делоите хорошо - а плохо не делоите!" конечно замечательный, но очень и очень условно реализуемый.
Также можно копнуть глубже.
Автор статьи (не перевода) пользуется операционной системой и я уверен что он не особо вникает в подробности того что там происходит под капотом, просто пользуется. При этом у ОС также бывают уязвимости и не без помощи сообщества (при обновлении macos даже пишут кто нашел уязвимость) эти уязвимости правятся в новых обновлениях.
То же самое относится и к любому популярному (например js) фреймворку. Сообщество находит уязвимости, отправляет PR, уязвимости фиксятся, dependabot сообщает о критических уязвимости. Если ядро фреймворка своевременно обновляется и в случае если в него не вносились правки (ну править ядро это конечно very bad practice), то при условия что сам код разработчика не уязвим все достаточно безопасно. Примерно как в ОС с последними обновлениями.
Совсем другое дело, что автор статьи столкнулся с ситуацией где разработчики не смогли найти уязвимость в самом ядре. Хотя для этого достаточно было сравнить файлы ядра, как я понял из статьи. Не знаю чем они занимались два месяца, тк за это время можно было накатить код и базу (при условии что она не была скомпроментирована) на новое ядро (попутно проверяю руками файлы на момент взлома) и тем самим решить проблему.
можно создать веб-сайт без инструмента развертывания и что вам вообще не нужен никакой JavaScript, даже когда веб-сайт принимает оплату
Ну так-то какой-то скрипт точно нужен. Не обязательно JavaScript, но что-то на back-end нужно.
Мы использовали слишком много абстракций, и будущее выглядит мрачным