"Программируйте на уровне интерфейсов, а не реализаций" - это не про качество абстракций, а про полиморфизм. Абстракции могут быть такими же уродливыми, как и их первые реализации. Зачастую так и происходит. Но не вводя их и улучшать нечего. За качество отвечают уже другие инструменты. Например, ISP, DIP и т.п.
Да, это возможности отлаживать, рефакторить, работать с VCS, профайлерами. Поэтому IDE не просто "запускают тулзы" а предлагают расширяемость через те же плагины, их вызов в контексте конкретного блока кода, автоматизацию через скриптовые языки. Умеют искать не просто текст в файлах, а конкретные виды (идентификаторы, референсы, имплементации интерфейсов и т.п.). Документацию они автоматом соберут, обновят и покажут preview в отдельном табе. Я уж не говорю, что большинство более-менее современных IDE тут же обеспечат удобный интерфейс к СУБД, докеру, TeamCity и т.п. У меня на некоторых виндовых серверах стоит FAR, но это дико не удобно, что я даже в такой среде чаще использую VIM+SSH.
Чтобы стать fluent в использовании языка его надо много раз использовать.
Ничто из мной перечисленного не отменяет написания кода. Просто влияет на его качество.
И уж естественно новички не начинают с приложений на 1000+ LOC.
Речь шла о преподавателях. Их опыте.
А на крошечных обучающих примерах хорошие практики нередко только переусложняют программу.
Осмысленные имена переменных, использование DEFINE констант вместо казуально возникающих чисел, doxygen-стайл документация к функциями вместо собственного колхоза, несколько ассертов для проверки edge-cases, нормальная IDE вряд ли "переусложняют". После первой же демонстрации студенты практически не отлипали от хороших практик. А многое я ещё на школьниках 5-11 классов опробовал)) Моя любимая шутка за их авторством (когда я сказал, что используемый на курсе wgcc не обновлялся с 2007) была: "Кажется препод последний раз обновлялся ещё раньше"))
И в программировании — вначале учишься понимать как код вообще пишется и работает на низком уровне а уже затем — как его организовать на высоком уровне чтобы это было удобно.
Когда им вбрасывают быструю сортировку без объяснения рекурсии, просто как данность, нагрузив их неокрепший мозг работой с указателями - это какой уровень?
И вот все что Вы пишите — это, имхо, как раз в стажировку должно входить
То есть на семинарах нужно преподавать то, как не стоит писать код, а на стажировке всё это исправлять?))
А из других ВУЗов сейчас кто-то хорошую программу на Ваш взгляд дает?
Увы, у меня пока очень маленькая и очень печальная выборка...
1. Полное непонимание, что код не только пишут, но и читают. Были просто дикие решения, которые я мог с трудом прочитать. Например два прохода по файлу с практически автономной логикой заворачивались в цикл от 1 до 2 с диким количеством тернарных операторов внутри (получалось в итоге медленно, нечитаемо и более вербозно). Именование идентификаторов - тоска, я уж молчу про формирование ubiquitous language.
2. Пропахший нафталином стандарт, что самые крутые программисты пишут в FARе, а отладка осуществляется исключительно printf'ами. За CLion били по рукам.
3. C89. Такое захочешь - не откопаешь.
4. TDD вообще не в почете. Хотя бы простыми assert'ами специфицировать условия задачи.
5. Роль header/implementation файлов вообще не объяснена, хотя абстракция/реализация - ключевые концепты в нашем деле и можно было бы её красиво подать.
6. Умение проводить декомпозицию не прививается. Ни на модульном, ни на функциональном уровне. Такое устойчивое ощущение, что преподаватель никогда не писал приложений даже на жалкие 1000 LoC.
В общем дрессируют мыслить линейно, императивно, когда мир активно движется в сторону декларативнго, type-oriented подхода, а приложения - это сложные конструкции. Ключевым вызовам ИТ - масштабируемости, реакции на изменения, командной работе даже близко не соответствует. Что интересно, все эти подходы нисколько не усложняют образовательный процесс, а делают его более органичным.
В прошлом году помогал студентам мехмата МГУ. Уровень преподавания - полное дно. Что парадоксально, восхваляемого математического мышления с абстракциями, блэк-джеком и прочими куртизанками там и не ночевало.
Все пропало... столько лет стараний и стертые до крови пальцы... Звание идеального ушло от меня куда в вакуум, осталось довольствоваться скромным титулом реального программиста.
Всегда интересовало, по какому принципу осуществляется отбор. Неоднократно имел наглость предложить свою кандидатуру, казалось что бесплатный матёрый архитектор - не самая плохая сделка. Но чем-то я не вышел))
Было что-то похожее недавно. Нужно было отжимать приходящие CSV размером от 5ГБ. Через имеющийся стриминг (NiFi, Kafka) ползало, но очень печально. Решением оказался Clickhouse. Отправка родному клиенту на stdin 5ГБ с последующей выдачей ключевых метрик (по датасету из 19М строк) на Kafka connector занимало буквально 6-7 секунд. И это на достаточно простом стенде, данные на который вливались с ноута по воздуху и внутри был фактически ещё один ETL stage, то есть импортированный датасет трансформировался в новый с обогащением, конвертацией и т.п.
Так шустро в райдере или в решарпере? Райдер у меня достаточно бодро работает, правда там другие заморочки. Но это уже моя специфика, не всем нужна поддержка iOS Local Device с hot reset.
Видимо тратите время на выполнение руками операций, которые могла бы выполнить машина
У меня постоянное ощущение, что машина стараниями решарпера выполняет слишком много операций)) Уже не первый год пытаюсь заставить себя на него пересесть. Рефакторинг, подсказки, неплохой тест-раннер, всё круто, беру. Но как начинается суровая работа… он своей скоростью убивает на порядок больше, чем даёт производительности труда. Буквально на днях пришло очередное обновления, после которых он любит опять включаться, хотя я ему сказал суровое "disable". Не очень большой проект, гдето 150K LoC. Вытерпел первую загрузку, с тотальным фризом секунд на десять и минутным подтормаживанием то там, то сям. Думаю, сейчас прокэшируется и дальше должно быть лучше. Но любой чих, любая навигация, любая подсказка — это +0.5-2с (Ryzen 5950X, RAM 128G, NVMe PCIe 4.0). Вроде казалось бы ерунда, но лично меня просто жутко выбешивает. Прыжки между фичами вообще беда. Может это исключительно мой паттерн. У меня в силу SRP/ISP огромное количество навигаций. А для рефакторинга я его могу раз в неделю включить и спокойно навести красоту.
А статистика именно по компаниям, склонным к использованию .NET или в целом? Потому что у меня эмпирические картины сильно отличаются. Там где fluentd редко наблюдается .NET. Там где .NET наиболее частая связка serilog+filebeat+logstash.
Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).
И почему все считают, что Бейсик тут отстаивается как самодостаточный функциональный современный ЯП?
Я сравнивал BASIC с Pascal. Так что вы ошиблись адресатом.
Бейсик поддерживает и массивы — первый шаг к структурам.
Я бы спросил, а куда делать следующий шаг, поскольку речь шла о массиве кругов. Но уже понятно, что с вами шагать очень долго. У детей темп намного выше))
В некоторых их и не было никогда, в других предпочтение отдавалось рекурсии. А в иных они всё чаще становятся просто синтаксическим сахаром для итераторов. И, наконец-то, вместо этой уродливой императивной конструкции есть нормальный масштабируемый вариант. Хочешь — многопоточность добавляй, хочешь — партиционирование. Не надо обходить весь код и вырезать эти циклы, громко матерясь.
И переменные тоже упразднили из современного программирования?
У вас, как я понимаю, очень дискретное мышление? Попробую пояснить на примере. В ES6+ var остался, но практически все best-practices рекомендуют использовать const. В языках вроде Rust, F# и многих других надо принудительно указывать мутабельность, но она не очень приветствуется. Я это рассматриваю как постепенное движение к иммутабельности. А для вас факт поддержки переменных — это то, что они основы?
В каких-то языках — возможно и будет. Но далеко не во многих :) И поморгать мне на мой век хватит, да и детям моим тоже :)
А там много не надо. Достаточно одного, чтобы большая часть рынка программистов осталась без работы.
И как этот переход в BASIC будет выглядеть? "Доброе утро, котятушки. Вчера я вам показывал рисование круга на BASIC. Но этот язык настолько убогий, кроме строк и чисел ничего не поддерживает, поэтому сегодня начнём изучать новый".
Ассемблером можно заинтересовать. Я в таких случаях использую embedded-платформы, от простых контроллеров, где можно помигать светодиодами, до чего-то роботизированного. Но это другой вектор развития.
Почему принцип программирования на уровне интерфейсов в большинстве случаев ошибочен и приводит к плохой архитектуре
"Программируйте на уровне интерфейсов, а не реализаций" - это не про качество абстракций, а про полиморфизм. Абстракции могут быть такими же уродливыми, как и их первые реализации. Зачастую так и происходит. Но не вводя их и улучшать нечего. За качество отвечают уже другие инструменты. Например, ISP, DIP и т.п.
Первый курс очень плох. Что не так с нашим образованием?
Да, это возможности отлаживать, рефакторить, работать с VCS, профайлерами. Поэтому IDE не просто "запускают тулзы" а предлагают расширяемость через те же плагины, их вызов в контексте конкретного блока кода, автоматизацию через скриптовые языки. Умеют искать не просто текст в файлах, а конкретные виды (идентификаторы, референсы, имплементации интерфейсов и т.п.). Документацию они автоматом соберут, обновят и покажут preview в отдельном табе. Я уж не говорю, что большинство более-менее современных IDE тут же обеспечат удобный интерфейс к СУБД, докеру, TeamCity и т.п. У меня на некоторых виндовых серверах стоит FAR, но это дико не удобно, что я даже в такой среде чаще использую VIM+SSH.
Первый курс очень плох. Что не так с нашим образованием?
Ничто из мной перечисленного не отменяет написания кода. Просто влияет на его качество.
Речь шла о преподавателях. Их опыте.
Осмысленные имена переменных, использование DEFINE констант вместо казуально возникающих чисел, doxygen-стайл документация к функциями вместо собственного колхоза, несколько ассертов для проверки edge-cases, нормальная IDE вряд ли "переусложняют". После первой же демонстрации студенты практически не отлипали от хороших практик. А многое я ещё на школьниках 5-11 классов опробовал)) Моя любимая шутка за их авторством (когда я сказал, что используемый на курсе wgcc не обновлялся с 2007) была: "Кажется препод последний раз обновлялся ещё раньше"))
Когда им вбрасывают быструю сортировку без объяснения рекурсии, просто как данность, нагрузив их неокрепший мозг работой с указателями - это какой уровень?
То есть на семинарах нужно преподавать то, как не стоит писать код, а на стажировке всё это исправлять?))
Увы, у меня пока очень маленькая и очень печальная выборка...
Первый курс очень плох. Что не так с нашим образованием?
Я из Double Commander не вылезаю... когда мне надо работать с файлами. А речь идёт о разработке.
Первый курс очень плох. Что не так с нашим образованием?
Кабы их учили работать с make-файлами, да ещё бы объяснили, что сборка - это не только компиляция и линковка.
Первый курс очень плох. Что не так с нашим образованием?
Очень много аспектов. Как пример:
1. Полное непонимание, что код не только пишут, но и читают. Были просто дикие решения, которые я мог с трудом прочитать. Например два прохода по файлу с практически автономной логикой заворачивались в цикл от 1 до 2 с диким количеством тернарных операторов внутри (получалось в итоге медленно, нечитаемо и более вербозно). Именование идентификаторов - тоска, я уж молчу про формирование ubiquitous language.
2. Пропахший нафталином стандарт, что самые крутые программисты пишут в FARе, а отладка осуществляется исключительно printf'ами. За CLion били по рукам.
3. C89. Такое захочешь - не откопаешь.
4. TDD вообще не в почете. Хотя бы простыми assert'ами специфицировать условия задачи.
5. Роль header/implementation файлов вообще не объяснена, хотя абстракция/реализация - ключевые концепты в нашем деле и можно было бы её красиво подать.
6. Умение проводить декомпозицию не прививается. Ни на модульном, ни на функциональном уровне. Такое устойчивое ощущение, что преподаватель никогда не писал приложений даже на жалкие 1000 LoC.
В общем дрессируют мыслить линейно, императивно, когда мир активно движется в сторону декларативнго, type-oriented подхода, а приложения - это сложные конструкции. Ключевым вызовам ИТ - масштабируемости, реакции на изменения, командной работе даже близко не соответствует. Что интересно, все эти подходы нисколько не усложняют образовательный процесс, а делают его более органичным.
Первый курс очень плох. Что не так с нашим образованием?
В прошлом году помогал студентам мехмата МГУ. Уровень преподавания - полное дно. Что парадоксально, восхваляемого математического мышления с абстракциями, блэк-джеком и прочими куртизанками там и не ночевало.
Профессионал ли ты по мнению Роберта “Боба” Мартина?
Все пропало... столько лет стараний и стертые до крови пальцы... Звание идеального ушло от меня куда в вакуум, осталось довольствоваться скромным титулом реального программиста.
Когнитивные искажения с примерами для айтишников
Наверно стоит в список когнитивных искажений внести способность везде видеть конгитивные искажения))
Работа над ошибками: отчет IT-отдела команды Навального
Всегда интересовало, по какому принципу осуществляется отбор. Неоднократно имел наглость предложить свою кандидатуру, казалось что бесплатный матёрый архитектор - не самая плохая сделка. Но чем-то я не вышел))
Apache Pulsar как основа для системы очередей
Было что-то похожее недавно. Нужно было отжимать приходящие CSV размером от 5ГБ. Через имеющийся стриминг (NiFi, Kafka) ползало, но очень печально. Решением оказался Clickhouse. Отправка родному клиенту на stdin 5ГБ с последующей выдачей ключевых метрик (по датасету из 19М строк) на Kafka connector занимало буквально 6-7 секунд. И это на достаточно простом стенде, данные на который вливались с ноута по воздуху и внутри был фактически ещё один ETL stage, то есть импортированный датасет трансформировался в новый с обогащением, конвертацией и т.п.
Как я выбирал между .NET и Java
Так шустро в райдере или в решарпере? Райдер у меня достаточно бодро работает, правда там другие заморочки. Но это уже моя специфика, не всем нужна поддержка iOS Local Device с hot reset.
Как я выбирал между .NET и Java
Значит перепутал. Адресовал вопрос этой фразе, думал частота была в смысле статистической величины:
А наверно речь шла о периодической. Год используют, год — нет))
Как я выбирал между .NET и Java
У меня постоянное ощущение, что машина стараниями решарпера выполняет слишком много операций)) Уже не первый год пытаюсь заставить себя на него пересесть. Рефакторинг, подсказки, неплохой тест-раннер, всё круто, беру. Но как начинается суровая работа… он своей скоростью убивает на порядок больше, чем даёт производительности труда. Буквально на днях пришло очередное обновления, после которых он любит опять включаться, хотя я ему сказал суровое "disable". Не очень большой проект, гдето 150K LoC. Вытерпел первую загрузку, с тотальным фризом секунд на десять и минутным подтормаживанием то там, то сям. Думаю, сейчас прокэшируется и дальше должно быть лучше. Но любой чих, любая навигация, любая подсказка — это +0.5-2с (Ryzen 5950X, RAM 128G, NVMe PCIe 4.0). Вроде казалось бы ерунда, но лично меня просто жутко выбешивает. Прыжки между фичами вообще беда. Может это исключительно мой паттерн. У меня в силу SRP/ISP огромное количество навигаций. А для рефакторинга я его могу раз в неделю включить и спокойно навести красоту.
Как я выбирал между .NET и Java
А статистика именно по компаниям, склонным к использованию .NET или в целом? Потому что у меня эмпирические картины сильно отличаются. Там где fluentd редко наблюдается .NET. Там где .NET наиболее частая связка serilog+filebeat+logstash.
Как я выбирал между .NET и Java
Странно, ни разу не сталкивался с таким мнением. Проектов на .NET было предостаточно. Северная Америка, Южная, Европа, Океания. От мелких бизнесов до транснациональных. В одном только ООН его море. Кто-то из доверия к бренду, кто-то в силу остального ландшафта в компании, кто-то из-за инструментов. WebForms/WPF были особенно в ходу, поскольку Delphi был не так распространён за пределами СНГ, а какой-нибудь MFC давался сильной болью. Огромное количество бизнес-софта, скажем тот же немецкий Sage (что-то в духе нашего 1С).
Прошло тридцать лет, а QBasic по-прежнему лучший
Я сравнивал BASIC с Pascal. Так что вы ошиблись адресатом.
Я бы спросил, а куда делать следующий шаг, поскольку речь шла о массиве кругов. Но уже понятно, что с вами шагать очень долго. У детей темп намного выше))
Прошло тридцать лет, а QBasic по-прежнему лучший
В некоторых их и не было никогда, в других предпочтение отдавалось рекурсии. А в иных они всё чаще становятся просто синтаксическим сахаром для итераторов. И, наконец-то, вместо этой уродливой императивной конструкции есть нормальный масштабируемый вариант. Хочешь — многопоточность добавляй, хочешь — партиционирование. Не надо обходить весь код и вырезать эти циклы, громко матерясь.
У вас, как я понимаю, очень дискретное мышление? Попробую пояснить на примере. В ES6+ var остался, но практически все best-practices рекомендуют использовать const. В языках вроде Rust, F# и многих других надо принудительно указывать мутабельность, но она не очень приветствуется. Я это рассматриваю как постепенное движение к иммутабельности. А для вас факт поддержки переменных — это то, что они основы?
А там много не надо. Достаточно одного, чтобы большая часть рынка программистов осталась без работы.
Прошло тридцать лет, а QBasic по-прежнему лучший
И как этот переход в BASIC будет выглядеть? "Доброе утро, котятушки. Вчера я вам показывал рисование круга на BASIC. Но этот язык настолько убогий, кроме строк и чисел ничего не поддерживает, поэтому сегодня начнём изучать новый".
Прошло тридцать лет, а QBasic по-прежнему лучший
Ассемблером можно заинтересовать. Я в таких случаях использую embedded-платформы, от простых контроллеров, где можно помигать светодиодами, до чего-то роботизированного. Но это другой вектор развития.