Интересная статья мне тут попалась. По сути она как бы косвенно обсирает язык Go :). Хотя код Go обычно абсолютно прост и понятен, но для беглого просмотра он не оч

Вот краткая выжимка:


Основная идея: Код чаще просматривают бегло, чем читают внимательно. Поэтому важно писать код, который можно понять с первого взгляда по его "форме" и структуре.

Ключевые принципы:

1. Форма кода имеет значение

Структура кода должна сразу показывать, что он делает
Связанный код должен выглядеть связанным, несвязанный — несвязанным
2. Избегать избыточной многословности

Слишком длинные имена переменных затрудняют понимание структуры
Пример: a * (x * x) + b * x + c читается лучше, чем a.multiply(x.pow(2)).plus(b.multiply(x.plus(c)))
3. Использовать контекст

В узкой области можно использовать короткие имена (get в HTTP-модуле)
В широком контексте нужны более описательные имена (Stripe.get)
4. Выделять "сантехнику" от логики

"Сантехника" — вспомогательный код (преобразования типов, обработка ошибок)
Логика — основная суть программы
Операторы и макросы помогают сделать "сантехнику" менее заметной
5. Минимизировать лишнюю информацию

Убирать ненужный boilerplate-код
Оставлять только существенную информацию для понимания
Аналогия с математикой: Математическая нотация — отличный пример читаемости "с первого взгляда". Интеграл ∫₀³(7x² + 3x + 7)dx понятен сразу, а его словесное описание требует полного прочтения.

Вывод: Хороший код должен быть "легким" для восприятия — его структура и назначение должны быть очевидны даже при беглом просмотре.

скинули тут вакансию ))

интересно, как такие долбоёбы-работодатели выживают вообще

Короче, тут такое дело, каминаут. Я тут плагин к Intellij сделал для редактирования OpenAPI (GUI редактор для openapi доков). Плагин платный, и как ни странно, уже есть пара реальных обладателей лицензии (я и моя мама).
Он умеет редактировать 3.0 и 3.1. Наверно позже сделаю и для 2.0.

Почему я его сделал: вручную редактировать огроменные ямлы с десятерной вложенностью, даже с хорошим автокомплитом - это больно. Ямл вообще придумали странные люди.

Плагин местами сыроват, часть интерфейсов я переделаю потихоньку. Вообще, это MVP, чтобы понять, надо это кому-нибудь вообще или нет. Но, так как уже целых двое готовы за плагин платить, и это еще не было практически никакого маркетинга, значит надежда есть. Как минимум, пивом я обеспечен.

В общем, кто не под санкциями, попробуйте триалку. Если увидите, что что-то не нравится, раздражает, хочется выматериться - я буду счастлив услышать ваши трехэтажные маты и поправить. Прямо жду этого :)

https://plugins.jetbrains.com/plugin/27118-openapi-gui-editor

Насчет редактирования openapi, по следам предыдущего поста

Многие в комментах писали, что лучше генерировать спеку из кода, это быстрее и проще.

Возможно, в некоторых языках - это просто, но вот в Go или PHP, например, код сильно засирается аннотациями, посмотрите на пример: https://github.com/swaggo/swag/blob/master/example/celler/controller/examples.go

Т.е. мало того, что код засирается, так еще и надо знать, как правильно срать :), т.е. по сути помимо знания об openapi надо еще знать этот псевдоязык и к каким элементам кода его применять.

Ну и, конечно же, самое главное, легко забыть поменять аннотацию, поменяв код. Не будет гарантии, что код и дока соответствуют друг другу.

В общем, большой разницы тут нет, что руками править openapi доку, что так.

Только если фреймворк какого-то язывка прям всё сам делает и выдаёт готовенький блестящий openapi. Я слышал, что в Java как-то с этим получше, но тоже сомневаюсь, что идеально

Ну и главное: подход API design first позволяет сначала согласовать апи (с другой командой, с архитектором, с фронтендерами, с другой компанией, с которой вы интегрируетесь), а потом только пилить сам код.

https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf

"...Несмотря на широкое распространение, влияние инструментов ИИ на разработку программного обеспечения в реальных условиях остается недостаточно изученным. Мы проводим рандомизированное контролируемое исследование (РКИ),
чтобы понять, как инструменты ИИ на рубеже февраля-июня 2025 года влияют на производительность опытных разработчиков ПО с открытым исходным кодом. 16 разработчиков со средним опытом работы с ИИ
выполняют 246 задач в зрелых проектах, в которых их средний опыт работы составляет 5 лет. Каждой задаче случайным образом назначается разрешение или запрет на использование инструментов ИИ начала 2025 года. Когда инструменты ИИ разрешены, разработчики
в основном используют Cursor Pro, популярный редактор кода, и Claude 3.5/3.7 Sonnet. Перед началом выполнения задач разработчики прогнозируют, что разрешение использования ИИ сократит время выполнения на 24%. После завершения исследования разработчики оценивают, что разрешение использования ИИ
сократило время выполнения на 20%. Удивительно, но мы обнаружили, что использование ИИ фактически
увеличивает время выполнения на 19% — инструменты ИИ замедляли разработчиков. Это
замедление также противоречит прогнозам экспертов в области экономики (на 39% короче)
и машинного обучения (на 38% короче). Чтобы понять этот результат, мы собираем и оцениваем данные по 20 свойствам нашей среды, которые априори могут способствовать наблюдаемому
эффекту замедления, например, размеру и стандартам качества проектов или предыдущему
опыту разработчиков с инструментами ИИ. Хотя влияние экспериментальных артефактов нельзя полностью исключить, устойчивость эффекта замедления в наших
анализах позволяет предположить, что он вряд ли в первую очередь является функцией нашего
экспериментального
дизайна...."

Восстановление «Аэрофлота» может занять до ПОЛУГОДА — сообщают эксперты.

А если хакеры удалили резервные копии, то весь процесс может затянуться на год.

На картинке сравнение зарплат инфобезопасника в Аэрофлоте и кладовщика в супермаркете. Выводы делайте сами.

@exploitex

Почему важно разбираться в деталях

Независимо от того, над каким проектом автоматизации (хотя, не только автоматизации) я работаю, замечаю один и тот же паттерн: если я не разбираюсь в предметной области, получается ерунда, а не полезный тул. На самом деле такое я замечаю не только за собой. И это логично: когда нет понимания, как работают процессы, как и какие задачи решаются, что поступает на вход задач и какие ожидаемые результаты, невозможно нормально спроектировать систему (автоматизацию, тулзу, приложение, сервис), потому что не понятно, что важно, а что нет. При отсутствии фундаментальных знаний, совершенно неочевидно, как может выглядеть прототип решения, чтобы с одной стороны — не сильно заморачиваться с реализацией, а с другой — чтобы оно уже приносило ценность клиенту.

Получается, что если на проекте нет доменного эксперта (опытного спеца со знаниями и опытом), который активно участвует в дизайне системы, получится поделка и её никто не купит. Например, можно попробовать сделать систему подготовки заявок на тендер чисто по наитию. Вроде как понятно, что надо взять исходные документы, взять шаблон заявки на тендер, вытащить нужные данные из исходных документов и положить эти значения в шаблон заявки, и вуа ля, прототип готов, можно показывать клиентам (да ещё и сразу нескольким, потому что это вроде как многим компаниям нужно). Но после демонстрации оказывается, что исходные документы могут не содержать нужную информацию и их нужно вытаскивать из внутренней базы знаний, а перед отправкой на тендер важно сделать апрув у менеджмента, и потом ещё саму заявку зарегистрировать во внутренней системе учёта документов, и т.п. Всплывают те самые "маленькие нюансы", которые знает только специалист, занимающийся оформлением этих заявок. А если этих фич нет в продукте, он никому не нужен.

Поэтому, если я делаю проект, стараюсь
1. максимально разобраться, как в компании решают задачу сейчас (вручную);
2. найти специалиста в теме (обычно, это кто-то из компании, заинтересованный в автоматизации), чтобы приставать к нему с кучей вопросов о том, "что", "как" и "почему".

На последнем проекте мы с ребятами ездили к клиенту, сидели несколько часов с юристами, и втыкали в миллиард разных договоров, чтобы понять, откуда и куда переползают данные, какие есть типы шаблонов, где "узкое горлышко" в процессах. Всё это не про творчество и вайбкодинг, очень скучно и рутинно, но только так можно разобраться, где клиенту будет реальная ценность от нашей автоматизации, а где — это просто наши влажные фантазии.

Что меня бесит в курсоре, что он как бы это сказать, устаёт. Ты ему говоришь: напиши к этому тесты, он пишет. Один тест не проходит. Он 10 раз пытается исправить, а потом пишет, что в принципе и 16 из 17 рабочих тестов - это норм.

Или: а давай я просто этот тест удалю, хер его знает, что там не работает.

Самый прикол в том, что только сегодня с пацанами обсуждали, что хотя тест Тьюринга современные модели проходят, но все равно можно отличить человека от машины: просто задавать вопросы 24/7. Человек в какой-то момент просто устанет, захочет есть, в туалет и т.д. А машина будет отвечать и отвечать.

А тут вон оно чё. И тут они уже как люди

Пока я жду, когда ии заменит программистов, похоже появляются новые профессии....

(взято с хабра)

Слушал подкаст Подлодка, там было про представление чисел в памяти. Решил загуглить bigfloat...

Не успел к пятнице, исправляюсь в понедельник.