Большой процент так называемых «экспертов» сегодня знают только, как использовать какой-нибудь хайповый инструмент, но они ничего не понимают в том, как все работает на более глубоком уровне. Это реальный вызов и большая проблема на будущее.
Рулевое колесо — это абстракция, которая облегчает управление автомобилем. Усилитель руля — это еще один уровень абстракции, который еще больше улучшает впечатления от вождения. Абстракции хороши, они обычно повышают качество жизни. Однако у нас в Дании есть пословица, которая гласит:
«Слишком мало» и «слишком много» испортят всё.
Что толку от абстракции, когда она ломается и никто больше не понимает, как работает технология, лежащая в её основе?
Слишком много в IT-индустрии сосредоточено на извлечении прибыли и слишком мало — на всём остальном. Вам нужно иметь возможность выпускать новые продукты или новые услуги всё быстрее и быстрее. А это означает ещё больше абстракций и больше автоматизации, меньше и меньше людей и меньше глубокого понимания.
Сегодня «программистов» и «системных администраторов» практически не существует, вместо них у нас теперь есть должности DevOps и даже DevSecOps, в которые индустрия очень старается втиснуть все возможные задачи и повесить их на одного человека. Технические специалисты должны заниматься и разработкой (Dev), и безопасностью (Sec), и «операциями» (Ops), то есть системным администрированием. Но поскольку ни один человек не может по-настоящему всё это освоить, приходится максимально всё автоматизировать, чтобы сэкономить деньги и избежать сложностей человеческого взаимодействия между различными отделами. В результате современного технического специалиста учат только тому, как использовать конкретные инструменты, но тогда он или она получает очень мало знаний о технологиях, на которых такие инструменты работают.
Совсем не кстати и то, что технологии становятся все более трудными для понимания, а все больше и больше современной жизни сильно зависит от используемых нами технологий. Так что же произойдет, когда уровень понимания в технологической индустрии достигнет такой низкой точки, при которой большинство людей даже не будут знать, как починить инструменты, которые они используют?
Люди привыкли к такому количеству абстракций, и они думают, что такой подход правильный, и они с радостью вносят свой вклад в этот бардак, добавляя еще больше абстракций.
Да, да, давайте все снова кодить на ассемблере!
— саркастический комментарий надменного разработчика
Абстракции нам нужны, без сомнения, но за каждый уровень абстракции приходится платить, что, по иронии судьбы, в конечном итоге может привести к огромной потере прибыли.
Уже сейчас большинство «специалистов по безопасности» очень мало знают о собственно безопасности, а знают только о том, как использовать какой-то готовый инструмент для пентеста. Инструмент для пентеста показывает кучу зеленых огоньков в своем веб-интерфейсе, и предполагается, что все хорошо. Тем не менее, настоящий эксперт по безопасности со злыми намерениями давным-давно взломал систему и всё это время распродаёт ценные данные в даркнете. Ничто не утекает и ничто не обнаруживается. Это может продолжаться годами, и никто об этом не узнает, ну, потому что графический интерфейс говорит, что ????все в порядке.
Один простой пример
Одна компания, которой я помогал с безопасностью, использовала стороннюю фирму-подрядчика, которая наняла именно таких людей. Разработчики знали, как собрать сайт и API, используя «современный фреймворк», но мало что понимали в устройстве самого фреймворка и совершенно ничего — о безопасности. И как только начали возникать проблемы, никто не мог разобраться, что происходит. Если точнее, они мучались с этой ситуацией в течение нескольких месяцев, прежде чем, наконец, решили обратиться за помощью.
Одного взгляда на то, насколько плохо все работало, хватило, чтобы понять что что-то не так. Я скопировал всё для проверки в оффлайне и первым делом начал смотреть код этой системы. Я провел вечер, просматривая строки кода, файл за файлом, сравнивая оригинальные файлы фреймворка с теми, что работали на хост-машинах компании. Просто просматривая код и файлы.
Конечно, в мои намерения не входило просматривать все подряд, но часто удивительно, как много можно узнать из небольшого ручного осмотра. Часто правда лежит прямо на поверхности, и, проявив немного терпения, вы можете найти ее. Для этого, конечно, требуется нечто большее, чем просто базовое понимание того, как работает технология. Некоторые студенты сегодня, по-видимому, даже не знают, что такое файлы и папки?
Короче говоря, в данном случае оказалось, что они были взломаны, и система использовалась как своего рода бэкенд для распространения порно и прочего хлама. Проблемы же с производительностью были вызваны не взломом, а самим фреймворком, который был ужасно медленным (в этом нет ничего удивительного, но это уже другая история). Взлом был довольно скрытным и, скорее всего, никогда бы не был обнаружен, если бы я не решил «поковыряться» и фактически просмотреть файлы и код.
ПРИМЕЧАНИЕ
Я намеренно не вдаюсь в подробности этого случая с примерами кода и т. д., поскольку для этого понадобится отдельный пост, явно посвященный теме безопасности (и, возможно, конкретным проблемам с производительностью), что не тема этого поста.
Советы тем, кто изучает технологии
Никогда не следуйте просто хайпу или тенденциям;
Будьте любопытны. Не просто изучайте инструменты, попытайтесь понять, как работает лежащая в их основе технология;
Если возможно, попробуйте хотя бы раз вручную сделать то, что, делает за вас инструмент;
Если возможно, попробуйте взглянуть на код инструмента. Даже базовое понимание кода может быть очень ценным;
Оставайтесь любознательными. Продолжайте учиться. Экспериментируйте. Погрузитесь глубже в технологию, которая вас интересует. Если возможно, создайте домашнюю лабораторию и используйте ее как площадку для обучения и совершенствования;
Подвергайте сомнению все. Особенно то, что кажется не имеет никакого смысла. Не просто предполагайте, что кто-то другой знает лучше — так вы быстро превращаетесь в слепого последователя. Иногда кто-то другой действительно знает лучше, но не стоит просто предполагать, что так оно и есть. И будьте храбры! Отстаивайте правду и свои убеждения, даже если это заставляет вас чувствовать себя одиноким.
P.S.:
В этом посте я хочу сказать не о том, что все должны понимать все «с нуля» или что вам не следует использовать какие-либо инструменты. Как я уже сказал, нам нужны абстракции. Кроме того, у нас есть люди, которые специализируются в различных областях, например, механик ремонтирует грузовик, а водитель им управляет.
Скорее, я говорю о том как важно инженерное отношение к технологии со стороны людей, работающих с технологиями.
Например, в разработке программного обеспечения слишком много специалистов были абстрагированы и заменены инструментами и автоматизацией, и все меньше и меньше людей понимают что-либо хотя-бы на один уровень ниже, чем уровень, на которым они работают.
Это серьезная проблема, потому что в конечном итоге мы достигнем точки, когда очень немногие люди смогут что-либо починить на нижележащих уровнях. И в том-то и дело, что мы уже отчасти дошли до этой точки!
Около полугода назад я наткнулся на некоторых веб-разработчиков, которые не знали, что можно создать веб-сайт без инструмента развертывания и что вам вообще не нужен никакой JavaScript, даже когда веб-сайт принимает оплату. Я спросил об этом своего друга, который в то время преподавал класс по Python, и он сказал:
Не удивляйтесь этому. Таков сегодняшний уровень. Индустрия хочет, чтобы мы массово выпускали людей, которые знают, как «нажимать кнопки», а не людей, которые понимают что-либо на более глубоком уровне. Они более или менее заинтересованы только в быстром внедрении.
Я знаю, всегда найдутся люди, которые проявят интерес к более низкоуровневой разработке программного обеспечения, но дело не в этом. Дело в том, что конкретно в разработке программного обеспечения мы давно достигли точки, когда добавили слишком много уровней абстракции и слишком мало людей понимают, что они делают. Индустрия простреливает себе ногу.
Если, например, я веб-разработчик, будь то front-end или back-end, или занимаюсь так называемой «интеграционной работой», и я создаю веб-сайты без особого кодирования или каких-либо знаний о TCP/IP, DNS, HTTP, TLS, безопасности и т.д., используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным, как обезьяна с динамометрическим ключом, когда что-то пойдет не так.
Комментарии (19)
zubrbonasus
23.10.2023 09:49-2В парадигме чистой архитектуры фреймворк это инфраструктура проекта, о которой есть смысл вспомнить в последнюю очередь, после того как будет разработан функционал. Создавая проект используя парадигму чистой архитектуры, нет смысла смотреть, что внутри фреймворка, как и любой библиотеки или пакета. В тоже время есть смысл создавать безопасные приложения и для этого есть смысл проверить библиотеку или фреймворк на безопасность или доверится информации из сети. Но просматривать все что приходит из компосера... только за деньги за деньги бизнеса.
evil_HFT Автор
23.10.2023 09:49+3Но в этом, кажется, и весь посыл статьи, что мы слишком многое заметаем под ковёр «инфраструктуры проекта, о которой есть смысл вспомнить в последнюю очередь», в то время как бизнес от нас требует разработки функционала и как можно скорее.
На своём опыте я такое видел в нескольких крипто(валютных)-проектах. Даже если проект не является запланированным скамом, то требования «релиза да побыстрее» часто приводят к печальным последствиям...
zubrbonasus
23.10.2023 09:49Смысл фреймворка в том числе и в том, чтобы разрабатывать используя код. Если нет доверия к фреймворку, можно выбрать другой или запилить что-то свое. В последнем случае не факт что получится лучше фреймворка. Также может быть небезопасно железо. В прочем кто, что заказывает и кто за что платит, тот то и получает.
WASD1
23.10.2023 09:49+1Смысл фреймворка в том числе и в том, чтобы разрабатывать используя код.
Мне совершенно не понятно что это значит.
Фреймворк предлагает некоторый "способ разработки".
В теории - "хороший" подходящий вам и достаточно безопасный.
На практике - выясняется что таке фреймворки часто сырые (что уменьшает его преимущества). Его недостатки, в этом случае всё равно остаются.
karrakoliko
23.10.2023 09:49+1В парадигме чистой архитектуры фреймворк это инфраструктура проекта, о которой есть смысл вспомнить в последнюю очередь, после того как будет разработан функционал.
когда от красивых слов перейдешь к практике в реальной компании, с коллегами, руководством, сроками, процессами — все это посыпется сквозь пальцы, и не поймаешь
Fedorkov
23.10.2023 09:49+5Где-то здесь должна быть ссылка на закон дырявых абстракций.
@evil_HFT, спасибо за качественный перевод.
tik4
23.10.2023 09:49+1Описанная проблема характерна не только для it, но и например для инжиниринга - использование высокоуровневых абстракций (трёхмерных конечно-элементных расчетов) привело к тому, что многие инженеры забили на физику и расчеты в 1д (на бумажке, в Экселе и тд) при этом совершенно не интересуясь какие ограничения есть у физических моделей в новомодных "черных ящиках" и как там все работает. Компуктер посчитал и все ок. И так оно много где.
Flammmable
23.10.2023 09:49+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 для инженеров.
grumbler70
23.10.2023 09:49+7@evil_HFT , спасибо за редкий в последнее время пост о здравом смысле.
Все эти недо-девопсы , не понимающие в основной массе "что там под капотом", вызывают только досаду и злость. Реальных девопсов - единицы на тысячу. Я знаю буквально пару-тройку. Основная масса - безответственные понторезы.
"Раработчики", а в реалии формошлёпы, из той же оперы.
Тенденции к обесцениванию инженерных навыков очень печальные и эти вопросы надо поднимать.
mrobespierre
23.10.2023 09:49+1Ох уж эти эксперты из скорлупки со своими советами. Когда им тыкаешь, мол вон, Go всё популярнее с каждыйм годом, уже большая часть облаков на нём, а там куда ни плюнь - всё слайс (динамический массив) байт, буквально. А они "да это не при чём, Go популярен из-за пиара Google". На вопрос "как именно Google пиарит Go?" всегда тишина. Всегда.
fieldof
23.10.2023 09:49+3Меня парит производительность систем (назовем это эффективность, КПД). Напоминает как человек вышедший на 300ккк какосеков (x5 к зп), стал и потреблять на x5. Хотя конечно часто подобное потребление результат гонки за эффективностью производства (отлить балванку, а не чеканить каждый раз, читай фреймворки). По итогу риходим к банальным pros/cons - где-то убыло, где-то прибыло. Но в реалиях софта прибывает скорее у корпораций и среднего размера компаний, к их марже. Так как существенного прогресса в софте я так и не ощутил как потребитель, а вот потребление батареи или оперативки линейно растет с каждым годом и нагрузка за "эффективностью" компаний фактически ложится на мой карман. Уже фактически невозможно не обновлять 7 лет свое железо - это доп fee к цене ПО которое аккуратно размазано по всей отрасли. Цена растет пропорционально падению начальной производительности, а принципиально новых продуктов которых невозможно было сделать условно в начале 00-х я так и не увидел. Изменилась лишь скорость внедрения этих готовых болванок, проверка гипотез бизнесом. Я понимаю что в современном мире деньги стоят дешевле чем рост, но точно ли не потребитель платит за эти эксперименты?
kreativf
23.10.2023 09:49+1Имхо всё в конце концов упирается в решение бизнес целей, в спрос и предложение. Держать штат людей, полностью разбирающихся во всех уровнях абстракций невыгодно и зачастую нецелесообразно. Держать штат людей умеющих работать только на самом высоком уровне абстракций - гораздо выгоднее с экономической точки зрения, ровно до того момента когда понадобится специалист, способный копнуть поглубже. Оптимум будет где-то между этими двумя крайностями.
Frevv
23.10.2023 09:49+1"Сегодня «программистов» и «системных администраторов» практически не существует" - существуют. Причём в 99.9% компаний админ адмтнит только почту и файловый сервер, а в промежутках меняет картриджи и устраняет замятие в принтерах. И не этом все, никаких задач из "devops" никогда за всю жизнь. Видимо автор работал толко в ИТ-компаниях (обычных которых большинство, из-за чего и конкуренция в ИТ конторы по 100-200 человек на место), не в обычных. Что делает програмист не в ИТ компании это вообще отдельный эпос.
используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным,как обезьяна с динамометрическим ключом, когда что-то пойдет не так.Для чего полезным то? Нет смысла ни в чем, разработчик работает всегда на компанию, а не на свои интересы. И ради зарплаты продвигает жизнь на работе приближая смерть. И пользы в обычной жизни, все офиса, от разработчика 0. Тут даже какой-нибудь учитель математике, интсрутор по фитнесу будет полезнее обществу.
toxicdream
23.10.2023 09:49+2Omne nimium nocet - все хорошо в меру.
Индустрия до сих пор бурно развивается. И до сих пор очень сильно нехватает стандартизации.
Мало какому инжинеру-строителю приходится задумываться почему у разных марок стали разная прочность, температура плавления, и какую из них надо взять чтобы отлить болт и гайку для крепления каждой балки моста.
В софтостроении до сих пор нет устоявшихся стандартных языков и библиотек. Комитет по C++ клепает новые стандарты каждые три года, писатели компиляторов не успевают все это реализовать, писатели библиотек ломают голову как это все подружить с железом. Прикладники замучавшись каждый пилит свою библиотеку под свои задачи и окружение. И все это сверху густо намазывается вебом, в котором вообще кто в лес, кто по дрова, рожая фреймворки со скоростью рожающей крольчихи. На безопасность вообще все забили.
В сумме это все дает адские тормоза которое приходится купировать ежегодным апгрейдом железа. И капитализм, и рынок это все пока устраивает - задачи худо-бедно решаются, прибыль идет. Хакнули из-за дыр в безопасности - сами виноваты, почаще обновляйтесь и делайте бэкапы...
Возможно когда это все грохнется, а событие это уже маячит на горизонте, тогда и придут эффективные и стандартные решения для минимизации издержек. А пока имеем, что имеем.
accurate_random
23.10.2023 09:49Лайк за одно только название, вечером дочитаю.
Хотя в дороге на работу дочитал. Актуальная тема поднята.
atshaman
23.10.2023 09:49+1Единственный вопрос, который хочется задать, прочитав такие статьи - "И чО?!"
Уже в начале прошлого века ни один человек не знал всю производственную цепочку производства обычного карандаша. В 21 веке есть математические теоремы, судя по всему - превышающие когнитивные возможности человеческого мозга - "ГРУППА математиков доказала" - повторить, или хотя бы полностью понять всю цепочку "в одного" - неа. Только верить.
Мир пронизан уровнями абстракции сверху донизу - и это касается далеко не только IT. Сделать с этим можно - ну примерно "ничего", оно все и везде так. Посыл "делоите хорошо - а плохо не делоите!" конечно замечательный, но очень и очень условно реализуемый.
nulovkin
Надеюсь, достаточно сильный AI скоро напишет относительно невысокую абстракцию, которая все стандартизирует и всех со всеми помирит.
Tolkik
Как раз наоборот. ИИ - это ещё один большой слой абстракции. А сильный ИИ - это настолько огромный слой абстракции, что будет, наверное, больше всего остальных слоёв, вместе взятых.