Comments 23
В 80е нормой было написание 50 строк к день. Переход с ассемблера на Си стал революцией продуктивности.
Дальше:
C -> ООП (C++, Java, C#): Революция абстракции над сложностью. Компоненты и объекты вместо процедур.
ООП -> Скрипты (Python, Ruby): Революция "батареек в комплекте". Скорость прототипирования и решения типовых задач (веб, данные).
* Языки -> Фреймворки (Rails, Django, .NET): Революция каркасов. Не ты пишешь код, а фреймворк вызывает твой код. Продуктивность х10 для конкретных доменов.
* Код -> Инфраструктура (Cloud, DevOps, Контейнеры): Главная революция последних 15 лет. Фокус на бизнес-логике, а не на серверах.
* Сейчас -> AI-ассистенты (Copilot): Умножение силы программиста, автоматизация рутины. Не замена, а усиление.
При этом, каждый шаг оказывался в то же время тупиком. Сижу тут, смотрю на миллион строк кода .Net framework 4.6.2, WCF и... Это полный тупик, пацаны! Обновлению не подлежит. Устарело даже на уровне контрактов и сетевых протоколов.
решения Microsoft того периода (2008-2012) имели высокий темп устаревания. Более устойчивые альтернативы были, в первую очередь в экосистеме Java. Microsoft предлагал сильно связанные, интегрированные фреймворки (WCF + Silverlight + RIA Services). Когда менялась парадигма (например, мир перешел на REST/JSON и мобильные клиенты), весь этот стек быстро становился легаси.
Там даже dip не выполнялся.
Бизнес-логика была вынуждена:
1. Реализовывать "грязные" интерфейсы. Вместо чистого ICustomerService она реализовывала ICustomerService с атрибутами [ServiceContract] и [OperationContract]. Абстракция (интерфейс) стала зависеть от детали (WCF).
2. Использовать "грязные" модели данных. Доменные объекты (Customer, Order) должны были быть помечены как [DataContract], а их свойства — как [DataMember]. То есть, ядро вашего домена зависело от библиотеки для веб-сервисов.
3. Думать о деталях транспорта. Например, обрабатывать специальные исключения FaultException вместо обычных. Логика обработки ошибок становилась привязанной к WCF.
Высокоуровневая бизнес-логика напрямую зависела от низкоуровневой детали — фреймворка для коммуникации. Поменять WCF на что-то другое означало переписывать и контракты, и модели, и реализацию
Ну это я так. О наболевшем
:-) Ну да. "Школьники пишут программы" сейчас, вот только "когда все идет не так" - зовут "других людей". Так что реальным IT специалистам работы хватает.... :-)
Не удержался.. как программист, вошедший в профессию в далеком 1979-м и видевший рождение и смерть многих идей, решений, технологий и систем, может дополню, а может и нет:
1979-80: Минск-222М 6 килослов ОЗУ (правда далеко не байт .. 48бит? уже не помню) и .. Фрязинский терминал в учебном классе НГУ, на котором .. практически ИДЕ "Фортран-2". Да, терминал был сам по сесе вполне "ЭВМ"... скорость разработки на Фортране-2 на мою память составляла 100-200строк программы за учебную пару (1.5часа). Тут просто: есть задание, его надо запустить к концу пары. Пусть в среднем это 150строк. Пересчёт на 8 часовой рабочий день дает 8/1.5*150 = 800строк рабочего кода. Надо ли нам было знать "архитектуру Минск-222М? - не-а. Только Фортран-2 и периферию).
80-90: ЕС1022 - ЕС1055, 15ВСМ-5 (оно же Д3-28, справочник программиста лежит по сию), Электроника-60, ДВК-1, ДВК-2, Роботрон, Спектрум, Оптимист, Океан-240, Yamaha, ЕС-1841, Искра-226 .. примерно сохранил порядок.. Ассемблер? О, да.. каждой. Наизусть, с учетом особенностей той или иной команды. Особенности архитектуры, организации памяти, ввода-вывода, вплоть до включения в код сообщений оператору на каком шаге программы ему надо поменять "жесткий диск" в приводе. Подключение новой периферии, требовало ещё и знания протоколов в деталях.. рождение сетей (в моем опыте), электронной почты и Интернета.. Скорость писания кода? Да примерно также. Игра "биржа" для Д3-28 написана за 1день (часов за 12) в две каски. Что-то около 2600строк кода совокупно. Правда это "Бейсик". Ассемблер-Реассемблер (8кб суммарно с элементами ОС) для Д3-28 писался примерно полгода совокупно, но там было 9/10 времени на сочинение "как упихать это в память?"..
90-2000: Засилье "ПиСи" в разных модификациях от 8086, 80286, 80386, 80486 и далее.. переход от ДОС (все команды и дырки, пардон "недокументированное" надо было знать наизусть) к ОС/2 и ковыряние в разных потрохах винды разных мастей. Первые локальные сети Novell 2 .. позже и 3х .. и вообще их зоопарк, пока не устаканился Ethernet.. Линукс. Знание железа помогало, но .. оно уже перестало быть актуальным. Бурное развитие ИДЕ (Борланд, привет) .. скорость писания кода? Да примерно 400-500строк за рабочий день (больше 8 часов, т.к. перекуры, поиграться, подумать..). Си, Паскаль..
нулевые - 2010: Агрессивная борьба с разными поделками Микрософт от WFWG3.11 до Win2k-xx пройдено всё, но уже больше как сисадмин. Писать под винду - отказался принципиально уже. Этому барахлу не должно быть место на празднике Жизни. ) Тут больше разные СУБД, сети и .. Ассемблер.
2010-2020е: о да. Знание тонкостей железа больше вредит чем помогает. Знание тонкостей компиляторов - ту да же. Знание потрохов устройства СУБД - там же: "к терапевту". Программирование превратилось из разработки в "сборочный конвеер". Перекладывание джейсончиков, писание HTML формочек, "толстый клиент браузера" .. забудьте это всё. Возьми тут, прилепи это, помаж так, запусти в прод. Падает? Прикрути сюда это и смотри. Не помогло? Опиши как фичу и особенность поведения.. Софт скилы персоналия важнее его знаний и опыта.. привет, дожили.
2020-2025: Применение ИИ.. ну тут хорошо изложено выше.
Скорость разработки? Сколько себя помню, столько она ПАДАЕТ. Хорошо если сию, с ИИ на пару, пишется 100-300строк кода в рабочий день. И да, он наконец-то стал 8 часов.. :)
Как же хочется вернуться в коллектив, где знают цену фразе: "стоимость байта памяти и машинной команды".. как-то так. Всё ИМХО. )
Видимо, задачи становятся сложнее (сети, безопасность, многопоточность), требования менее чёткие и больше зависимость от контекста
Си против ассемблера выиграл всухую на примере разработки ms Excel vs конкурент, не помню какой
Реально сложные задачи (числодробилки, хайлоад и пр.) написаны давным-давно уже. То, что стоит как "задачи" сию - это обвязка, обмазка и сборка из готовых кусков, в которые уже давно никто никуда не лазит.
К примеру, взять индекс BTREE любой субд. Когда впервые написан код для работы со сбалансированными, разреженными деревьями, что лежит в основе индекса? .. правильно, это mumps, код которого актуален и не менялся, кажись с .. 1979года.
Наши работают с М10, которая внутри mumps и очень хотят сбежать на postgres. С чего бы это?
Видимо, когда управление данными и бизнес логика перемешаны это очень плохо для ревью и изменений. Код хрупкий.
Алгоритмы / абстракции не содержат много кода. А вот управление сложностью бизнес логики, частными случаями это отдельная олимпиада.
Управление сложностью это сложно
С mumps сбежать хотят многие, не многим это удается.. :)
Вы немножко про иное, чем выше: Вы про внешний интерфейс mumps, который есть жуть жуткая, а я про алгоритмы разреженных деревьев, которые снаружи никто не видит, и которые точно также работают и в коробке с названием Postgres. Так что "сбежать" не получится, и там и там в btree стоит один и тот же код.
Не надо переживать! Это нормальный процесс когда все становится более узкоспециализированным. Раньше человеку надо было знать и уметь все самому: от того, как вспахать поле, до того, как принять роды у коровы. Сейчас этим занимаются специально обученные люди. Кто то перекладывает JSONы (востребовано) кто то пишет драйвера под новое железо, разрабатывает операционные системы и т.п. (тоже ведь востребовано!)
Хорошему программисту надо знать ту сферу, в которой он работает. То, что раньше программисты были большие и сильные, а нынче измельчали - стариковское обюжжание :P
Если ты превосходно разбираешься в соей узкой области и не хочешь/можешь даже в общем приближении понимать "как все под капотом работает" - это не ужасно, но недостаток. И получаем ответы от всех "узких специалистов" - "С моей стороны пули вылетели, проблемы на вашей стороне..."
Плохой пример про поле и корову. Считаю, что в данном случае отсутствие знаний - влияние/последствия извращенной системы образования. Да и раньше - не всем это надо было знать.
Неужели эти знания не нужны человеку, что живёт и трудится в деревне/селе? Но школа не даст этого. Школа не обучит ни одному нужному для жизни в деревне (или в данной местности) навыку. Потому что почти все школы унифицированы. И дают примерно одни и те же знания. Без привязки к местности. Изучают сферических коней в вакууме.
А ведь можно в этой школе на уроках биологии изучать строение домашних животных, уход, лечение и т.п. Или строение растений на примере всех тех растений, что выращивают в текущей местности плюс окружающий внешний мир (местные растения, деревья, животные и прочее).
На химии - после изучения базовых основ - изучать способы создания/замешивается удобрений, очистки воды, газа от установок переработки органических отходов и т.п.
Т.е. знания нужны для решения задач реального мира. А современная школа работает не так.
С программированием похожая история. Вычислительная техника создавалась для решения задач реального мира. И со временем так усложнилась, что потребовались специалисты, что способны развивать и совершенствовать эту технику и ПО (разрабатывать новое железо и писать драйвера для него и ОС). Знания для этого нужны не всем разработчикам. А только выбравшим эту стезю. И выбор такого направления должен идти ещё при поступлении в вузы. Хочешь создавать новое железо и ПО для них - иди сюда.
Прочие же разработчики - все также решают задачи реального мира, на основе предоставленных им готовых инструментов в виде разнообразного железа и ОС. И самые эффективные специалисты здесь те, что хорошо знают свое направление. Например, как вспахать то же поле. Такой разработчик сможет создать хорошее и качественное ПО для этой задачи. Детально понимая, как пашут, какой техникой, в каких условиях, как размечают поле, как делают развороты на поле, на какую глубину пашут, влияние грунта на работу и т.д. Такому разработчику не нужно знать железо и ОС на уровне их разработчиков. Но нужно глубокое знание предмета.
Я могу ошибаться, но сейчас разделение на специализации идёт по-другим принципам и логике. И реальная специализация начинается лишь тогда, когда человек попадает на конкретную работу. И там он по сути учиться заного всей предметной области (не программированию, а именно предметной области)
С точки зрения низкоуровневых снобов - деградация. С точки зрения нейтрального наблюдателя - кооперативная специализация на более высоких уровнях абстракций.
Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
Да ну, какое там обилие? В каждом из распространённых языков есть 2-3 фреймворка, достойных внимания. Все остальные - это "убийцы" тех двух-трёх, про которые через год-два все забывают.
Ок. Берем ПХП и Yii. Одного достаточно. Вопросы на засыпку (в ИИ не подглядывать, в папки тоже): сколько всего файлов фреймворка Вы знаете? А сколько их всего? Сколько из них Вы знаете на столько, что можете внести изменения с гарантией исключения бага, по не знанию? Ну и по-проще: когда Вы последний раз заглядывали в код самого фреймворка? :)
Не надо ля-ля.. Да, в каждом направлении есть 2-3 мейнстримовых фреймворка, в которые 99.9% разрабов никогда не заглядывали "под капот". В свое время, был такой Zend 1.x .. заглянув под капот, покопавшись и .. ужаснувшись, выкинул очень много, после чего пустая страница "Привет мир" в полном обвесе Zend MVC стала весить 32 КИЛОбайта, вместо 2.6 МЕГА байт изначальных.
Много разрабов способно разобраться хотя-бы в одном фреймворке РАНЬШЕ чем выйдет его обновление? :) Так шта .. если копаться и пользовать по делу - да, мешает и сильно. Если формочки клепать не вникая в потроха .. а это точно "разработка"? :)
Что за бред вы несёте? С Yii не работал, работаю в основном с Drupal (он в свою очередь базируется на Symfony)и ещё немного с Laravel. Так вот, расскажу со своей колокольни, почему вы пишете бред:
сколько всего файлов фреймворка Вы знаете? А сколько их всего?
В объектно-ориентированном фреймворке надо знать не файлы, а нэймспэйсы и классы.
Сколько из них Вы знаете на столько, что можете внести изменения с гарантией исключения бага, по не знанию?
Фреймворк в вендорах, там менять только через патч, иначе при первом же деплое composer install всё затрёт. НО(!!!) это каким идиотом надо быть, чтобы патчить фреймворк под свои нужды, когда там всё легко декорируется, альтерится, переопределяется?
Ну и по-проще: когда Вы последний раз заглядывали в код самого фреймворка? :)
Вчера ходил по нему с дебагером. А до этого позавчера. И в понедельник, вероятно, загляну опять.
99.9% разрабов
Возможно, я тот самый 0,1%, но я всегда говорил, что не надо скупать курсы и книги, надо читать код. В первую очередь код фреймворков. Тех самых 2-3 фреймворков, которые востребованы более 10 лет и давно не болеют детскими болячками.
Ну и вдобавок к моему тезису о том, что нет никакого смысла учить всё подряд. После 5 лет работы с Drupal мне попался проект на Laravel. Впервые видя её, мне понадобилось всего три часа, чтобы начать работать. А задачи были интересные: поменять модели данных, чтобы выборки работали быстрее, создать миграции для деплоя этих изменений, написать консольную команду для импорта около 100 тысяч товаров. Почему всё оказалось так просто? Да потому что если ты знаешь один толковый фреймворк, то любой другой толковый фреймворк тебе с ходу будет понятен.
В объектно-ориентированном фреймворке надо знать не файлы, а нэймспэйсы и классы.
Не мешает выше сказанному. Чтобы их ЗНАТЬ, надо:
..., надо читать код. В первую очередь код фреймворков.
Именно про это и были вопросы. :) Видимо да, Вы тот самый 0.01%.
Фреймворк в вендорах, там менять только через патч, иначе при первом же деплое composer install всё затрёт. НО(!!!) это каким идиотом надо быть, чтобы патчить фреймворк под свои нужды, когда там всё легко декорируется, альтерится, переопределяется?
Это уже тонкости вопроса правок. Да, можно и так. А можно форкнуться себе и поменять в композере откуда брать, а можно и в наглую сфетчиться и поддерживать исключительно локально, накатывая патчи родной репы.. зависит, между прочим и от НДА в частности.
Впервые видя её, мне понадобилось всего три часа, чтобы начать работать. А задачи были интересные: поменять модели данных, чтобы выборки работали быстрее, создать миграции для деплоя этих изменений, написать консольную команду для импорта около 100 тысяч товаров. Почему всё оказалось так просто? Да потому что если ты знаешь один толковый фреймворк, то любой другой толковый фреймворк тебе с ходу будет понятен.
Да, потому что задачи по сути одни и те же, типовые. Попробуйте что-то не типовое, к примеру распарсить ваши 100тысяч товаров на группы по содержанию текста в названиях и написать валидатор, выдающий в браузер расхождения в группах и категориях, куда они приписаны. Тут Вам и модельки посложнее АктивРекорд и хелперы и кешаторы и на выдаче это всё ещё надо скомпоновать удобно для потребителя.. :) Да, оптимизируйте сие поделие, дабы оно не жрало память и проц ведрами при росте товарной базы скажем .. миллиардов до 3-х. и не слало на клиента объемами по сотне метров и гектары..
ПС. А то что ни интернет-забегаловка, то обязательно чьи-то трусы попадаются в категории "запчасти для токарного станка".. :)
В предметники надо уходить. Чистокодеры в таких количествах не нужны
Через 20 лет появится статья на манер: ...вот раньше люди умели в ООП, а сейчас только в промпты...
Эволюция "требует" усложнения и как следствие - разветвления. Когда произошла техническая революция и люди ушли с полей, и ручной сборки урожая, то начали заниматься обслуживанием этих самых машин, которые их заменили. У людей появилось больше времени на семью и свой досуг. И это нормально.
Ты можешь сейчас собирать каждое приложение из исходников и быть умным как раньше только в этом, упуская много других возможностей, а можешь пользоваться пакетным менеджером и быть счастливым, приобретая новые знания. И как видишь, эволюция движется людьми не в пользу рутины.
Внезапно стало модно думать о программе как о коллекции объектов, а не как о последовательности команд. Управление памятью стало делом компилятора, а не программиста.
Оба утверждения - неправда. Мода там ни при чём. Программа - коллекция объектов - чушь собачья. Управление памятью никак не связано с ООП.
Деградация программиста глазами ИИ: От магистра памяти к пользователю ChatGPT