HowProgrammingWorks - JavaScript and Node.js Programming

Монитор для Java разработки

Что кодворс что литкод позволяют хорошо потренироваться в тех задачах, которых никогда не будет на робочих проектах.

😜 Есть такой эффект, и я иногда чувствую вину за его распространение: человек только осваивает язык и платформу, но попадает на сложную лекцию о том, как все устроено внутри, о недокументированных функциях, оптимизациях, высоконагруженных и распределенных системах, многопоточности, сборке мусора, метапрограммировании, ивентлупе и т.д. и вот ему дают задачу (или он сам себе ее ставит) например: «сделать апи для получения с сервера списка городов» и тут он вспоминает про асинхронные генераторы, бекпрешер в стримах, про инверсию управления и начинается... нужно все сделать по науке, чтоб миллион пользователей пришло и что будет, если каждый 10 раз в секунду будет выкачивать список, в котором сотни тысяч записей, а может быть давайте не в JSON слать, а придумаем для этого бинарный протокол и сэкономим на кавычках и запятых, будем строки разделать байтом FF, и обязательно предусмотреть отмену получения списка и докачку, если соединение разорвалось с того же места и чтоб кеширование работало, но была возможность принудительно кеш обновлять... А если справочник меняется, то нужно вебсокетами присылать изменения, нужно придумать в каком формате, и таймаут держать в памяти, что если докачка не началась в течении 5 минут, то уже не начнется, а если соединение восстановлено, но мы подключились к другому процессу или потоку, а если сервер перегрузился нужно же... и это бесконечно, так складывание двух чисел можно защищать от влияния космических лучей... я уже не говорю про микротесты и нагрузочные тесты, которые непременно нужно нужно гонять пару часов. Ну... все это... конечно способствует освоению платформы, это интересно и через пару лет может дать полезные результаты и я не хочу отговаривать от экспериментов, но признайтесь себе, сколько будет пользователей, данных и интенсивности через год, два, три, прикиньте грубо, ну на 2 можно умножить и дать себе отчёт в действительных целях своего R&D

⭐️ Тут сведены идеи применения AI, точнее LLMок в разработке программного обеспечения. Что они делают хорошо 🟢, что удовлетворительно 🟧, а что вообще плохо 🛑 🟢 Анализ больших объемов данных, которые человеку сложно внимательно обработать ∙ логов и стектрейсов ∙ memory dumps ∙ dependency trees ∙ git blame 🟢 Портирование: ∙ с одной версии фреймворка или библиотеки на другую ∙ с одного языка на другой ∙ с одной СУБД на другую ∙ с одной OS на другую или поддержка нескольких 🟢 Боты и тулинг для автоматизации обработки кодовой базы и репозиториев: ∙ применение стиля ∙ применение чеклиста изменений ∙ поиск уязвимостей в кодовой базе ∙ маркировка commits, pull requests, issues ∙ расстановка тегов по коммитам и т.д. ∙ автоматизация закрытия тасков, майлстоунов ∙ поиск дубликатов кода, тасков, или перелинковка связанных ∙ аудит объемов работы, качества, сбор статистики ∙ предложения для рефакторинга ∙ поддержание консистентности кодовой базы и стиля ∙ создание спеки стиля кода по примерам кода или кодовой базе проекта ∙ предложение метрик для оценки кода и вычисление этих метрик 🟢 Написание текстов: ∙ подготовка CHANGELOG, HOW TO, Q&A ∙ генерация документации по коду ∙ реверс-инжиниринг кода в ТЗ ∙ поиск отличий между ТЗ, кодом, доками ∙ преобразование между форматами данных, например json, csv, pdf, sql, txt 🟢 Управление проектами ∙ оценка трудоемкости разработки, времени и денег ∙ оценка возможности распараллеливания разработки ∙ поиск слабых мест и выявление проблем в сметах, планах, ТЗ ∙ предложения по оптимизации бизнес-процессов ∙ сбор данных для подготовки принятия решений 🟢 Программирование ∙ алгоритмические задачи, подбор и реализация алгоритмов ∙ портирование, перевод и транспиляция между языками программирования ∙ преобразование между class и prototype в JavaScript ∙ оптимизация по заданному критерию: cpu, ram, i/o, lines, читаемость, сложность, etc. ∙ объяснение кода ∙ генерация примеров использования библиотек или абстракций ∙ ревью пул реквестов ∙ генерация юниттестов, системных тестов ∙ генерация конфигураций ∙ настройка CI/CD ∙ генерация SQL запросов ∙ генерация API, CRUD, формочек ∙ генерация моделей, структур, DTO, схем данных, классов, jsdoc ∙ преобразование моделей между разными синтаксисами ∙ синхронизаций структуры базы данных, схем, моделей, форочек ∙ генерация тайпингов и заголовочных файлов как .h, .d.ts ∙ подготовка контрактов и описание интерфейсов для интеграции систем ∙ генерация парсеров, конвертеров, по примерам входных и выходных форматов данных ∙ генерация валидаторов данных и валидаторов контрактов 🟧 Задачи, которые LLMки делают, но не всегда качественно и с проблемами ∙ терпимо конвертирует код между парадигмами: ООП, процедурное и структурное программирование ∙ гораздо хуже конвертирует между ООП и ФП ∙ асинхронное программирование и задачи с доступом к состоянию из разных мест ∙ олимпиадное программирование ∙ подготовка шаблонов и примеров приложений/проектов ∙ выбор зависимостей ∙ выбор СУБД, языков программирования, платформ, тулинга ∙ концептуальный код, демонстрирующий идею и делающий ее понятнее для многих 🛑 Что плохо решается при помощи LLMок ∙ системное программирование ∙ платформенный код, код библиотек, фреймворков ∙ новые и прорывные технологические решения, которые негде подсмотреть ∙ большинство новых нетипичных задач, когда в интернете мало примеров кода ∙ архитектура систем и структура приложений, даже при наличии множества примеров

Сама логика предметной области имеет асинхронную природу. Ни какие балансировщики и гейтвеи, ни какие облака или FaaS не могут решить проблемы конкуррентного доступа к памяти, cpu, диску, системам ввода-вывода. Но писать доменный код в стиле параллельного программирования — это тупик, а асинхронное программирование не намного проще, тем более на #JavaScript под управлением #nodejs. Мои взгляд на этот вопрос будет в курсе, который готовлю, точной даты не знаю, но до нового года точно будет: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Async-2024.md

Как учить языки программирования? Несколько неочевидных подсказок: 🔵 Не нужно сразу стараться понять все, это как с человеческими языками, если концентрироваться на том, что вы не понимаете все на 100%, то обучение заблокировано, со временем пробелы будут закрываться, а после какого-то момента пазлы сложатся, 🟢 Нужно много читать и разбирать хорошего кода, основная деятельность программиста — это не написание, а чтение кода, это так не только во время обучения, но и в работе, 🟡 Нужно изучать плохой код, разбирать почему он плохой и исправлять, переписывать, улучшать, добиваться не скорости и применения сложных конструкций, а читаемости, простоты и понятности, 🔴 Важно делать ошибки, изобретать велосипеды, наступать на грабли, исправлять их и разбирать, в чем была проблема, конфликтовать и приходить к консенсусу, заходить в тупик и находить решение, это эффективнее всего делать в групповом проекте, объединяйтесь и работайте вместе. Тут мои новые лекции для начинающих и много заданий: https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Beginners.md

⚡️ Ключевая проблема современности — это то, что люди пишут frontend или backend на NodeJS так и не освоив нормально асинхронное программирование. Его знание не наступает сразу после изучения синтаксиса JavaScript и TypeScript, надежность асинхронного кода невозможно полноценно проверить типами и очень сложно покрыть тестами. Нет ни одного нормального курса по асинхронщине, их вообще почти нет, но и мой курс из 26 лекций (по часу и более) — полное говно, он разросся и устарел. Все думают, что они с налету вот так освоили колбеки и таймеры, промисы и async/await и все... НЕТ, так не работает, асинхронное программирование намного сложнее и вам придется понимать про состояние гонки, блокировки и особенности отладки и даже проблемы стектрейсов, адаптеры контрактов и атомарные операции, ивент луп и микротаски... но асинхронное программирование, одновременно и намного проще, потому, что нужно писать ПРОСТОЙ асинхронный код, а не сопли на флагах и примесях, зонах и доменах, а писать асинхронщину просто и понятно ­— вообще ни кто не умеет. В продуктах так не пишут, там все на заплатках из миксинов и на if-ах, в оупенсорсе тоже так не пишут, там оверинженеринг процветает и люди выдумывают сложнейшие абстракции для простых вещей, просто потому, что могут. Я сделал по асинхронному программированию, наверно, наибольшее количество докладов, лекций, примеров и статей, но вот только 2 года назад начал писать хоть сколько-нибудь приличный асинхронный код. Да и сейчас сделать такой курс для меня огромный вызов и ответственность, который я бы с удовольствием разделил с коллегами, c Illya Klymov и Denys Otrishko, Dmytro Nechai и Alexey Orlenko, Alex Golikov и Alexey Migutsky если они согласятся сотрудничать в любом удобном виде, как критики или соавторы, как рецензенты или конкуренты. Вы, конечно, можете позвать и предложить других специалистов, которых я не назвал. Оглавление у меня уже готово, но я его покажу после нескольких итераций, а пока могу дать только ссылку на старый курс, как пример того, как делать не нужно 👉 https://github.com/HowProgrammingWorks/Index/blob/master/Courses/Asynchronous.md

Чтобы писать на low-code нужно все то же, что и в обычном программировании, но это гораздо менее удобно. Условия и ветвление, циклы, структуры данных, работа с файлами, сетью, БД и прочее, никуда не деваются. Просто у вас не будет возможности: 🖕 писать юниттесты, 🖕 делать ревью кода, сравнивать код, 🖕 diff между коммитами, смотреть историю, версии кода, 🖕 модули, слои, компоненты - забудьте, 🖕 сложные схемы, более 100 блоков, Научитесь писать идеальный код с первого раза и чтобы его не нужно было поддерживать. Но есть и положительные моменты: ✅ красивая картинка продает, ✅ вы сможете списывать больше времени, ✅ бюджеты будут расти, Так же можете забыть про: 🚫 безопасность, 🚫 масштабируемость и надежность, 🚫 расширяемость и поддерживаемость, 🚫 предсказуемость сроков разработки. Удачи и терпения! С low-code они вам понадобятся.

Разработчик, помни, что ты вправе сам распоряжаться своей цифровой идентичностью и волен не соглашаться на предложения абьюзеров от менеджмента использовать, например, Jira или Confluence, если это нарушает твои личные границы. Сейчас они принуждают тебя к малому, а завтра заставят установить Скайп или Тимс на твоем компьютере. Сейчас ты допустишь легкий харасмент, но не успеешь и глазом моргнуть, как они начнут логать время, записывать снимки экрана, и вот их рука уже у тебя в трусах.

Как бы мог выглядеть идеальный web? Браузер с виртуальной машиной LISP и LISP сервер, обменивающиеся по сети S-выражениями. Естественно, S-выражения для описания UI. Полная однородность. Но на руках у нас только JS, который компилирует JS в JS и посылает JS другому JSу.

Почему большие коллективы менее эффективны в ИТ, все знают, что до 80% времени уходит на координацию. Но есть еще важный аспект: в крупных коллективах 20% времени уходит на три способа преодоления факапов, которые неизбежно в работе возникают: (1) построение оправданий, (2) обвинение коллег, и читаем в твиттере: https://twitter.com/tshemsedinov/status/1690966379485179905