Принято считать, что костыли в коде — это плохо, стыдно и вообще причина высокой ранней смертности программистов от переломов пальцев. Однако, все программисты, даже самые лучшие, костылят постоянно и непрерывно. — даже ваше любимое кеширование — это вполне себе костыль. Более того, зачастую костыли являются не решением программиста, а диктуются реальностью или бизнес логикой. И в такой ситуации основные проблемы, которые принято валить на навязанные костыли, чаще всего программист создает себе сам из-за своего неуемного перфекционизма.
Сегодня мы будем учиться, как не создавать себе проблем и вообще жить с костылями в коде и не тужить.
Помимо тренировки навыков написания кликбейтных заголовков, я еще иногда предаюсь размышлениям. И наблюдая последние пару лет интересную ситуацию в одной компании, я пришел к выводу, который может показаться парадоксальным — контора, у которой все разработчики сильные, может хапнуть больших проблем, если it-шное лобби в верхах конторы достаточно слабое. Другими словами, если на уровне принятия решений о распределении ресурсов в компании нет сильного айтишного лобби, но вам обязательно нужен существенный процент джунов, иначе все покатится в жопу.
И это настолько неочевидный вывод, что, похоже, стоит раскрыть мысль подробнее.
Читаю сейчас книжку «Kotlin. Программирование для профессионалов» и снова наткнулся на вечную проблему авторов книжек по языкам программирования. Так что опять пришло время побухтеть.
Наблюдая раз за разом, как ребята, прошедшие довольно серьезный отсев на собеседовании в том числе по архитектурным вопросам, умудряются лажать в несложных архитектурных моментах, я долго не мог понять, почему в большинстве своем разработчики не умеют адекватно применять свои познания на эту тему в коде. И сегодня я понял.
Что если мы скажем вам, что язык программирования go — это на самом деле не язык программирования, а деструктивно-тоталитарная секта, целью которой является разрушение современного it? Что скрывается за так называемым языком программирования и как калечат программистов — не физически, а страшнее — психически! Как перевернуть мир, сделать черное белым, а белое черным, и кучу адевактных в общем-то людей заставить гордиться своей анальной болью? Об этих и многих других грязных тайнах в нашем эксклюзивном расследовании.
На почве недавних новостей про волшебную нейросеть ChatGPT и ехидных воплей про «скоро вам, программистам, придется идти на завод или жопой торговать» вспомнился github copilot, про который у меня давно копилась пара ведер желчи, но все руки не доходили написать (потому что лень). И хоть большинство восторженных криков по поводу конкретно копилота уже затихли, руки у меня наконец дошли и похоже пора высказаться.
Я, в общем-то, давно привык относиться к повальной дрочке на нейросети спокойно и даже с некоторым пониманием. Ну, в самом деле, кому же не хочется настоящего ИИ, который будет делать нашу работу за нас, чтобы прям «вкалывают роботы — счастлив человек» и вот это все. Тем более, что люди, далекие от it, нихрена не представляют, как это вообще работает и для них тот же телевизор по уровню волшебности не отличается от настоящего киношного ИИ.
К программистам, которые дрочат на нейросети, в общем-то, тоже претензий особо нет. Тем более, что в их фантазиях речь обычно о далеком будущем, а далекое будущее — оно, знаете ли, такое неопределенное и далекое, что там всякое может быть.
Но вот когда те самые программисты (!) начинают голосить, что ВОТ! ВОТ ОНО! НЕЙРОСЕТИ УЖЕ ЗАМЕНЯЮТ ЛЮДЕЙ! И не только в задачах нечеткой классификации — тут как бы да — но и в написании кода, статей, текстов и постов и все это типа осмысленно и не хуже человека — вот тут батю начинает припекать.
В общем, я замучался покупать новые штаны взамен прожженных, так что сегодня мы обосрем конкретно github copilot и раскроем миру правду, почему это мертворожденная отрыжка жопы сатаны и почему оно никогда не взлетит.
Вообще-то, книга не совсем про распределенные данные. Если быть точным, она — как жопа — разделена ровно на две половинки: первая очень верно описывается оригинальным названием книги (database internals) — потому что она просто про разные внутренние штуки в базах, пока без всякой распределенности. А вот вторая половина — да, это уже конкретно про распределенность.
В те времена, когда я много собеседовал программистов, я любил позадавать интересные вопросы тем, кто набрался смелости в своем резюме написать слово «сеньор». Не для того, чтобы кого-то обидеть или унизить — боже упаси. Просто от сеньора хочется услышать не только ответ на вопрос, чем отличаются типы джоинов между собой, но и увидеть хоть какие-то зачатки мышления и способности рассуждать.
Одним из моих любимых вопросов был следующий — я просил сказать, что такое костыль, типа дать определение своими словами. Обычно после некоторых мучений человек-сеньор все-таки рожал что-то вроде «это некий обходной путь, который используется для имитации исправления проблемы вместо реального исправления проблемы». Окей, отвечал я, тихонько потирая руки, как та выдра, в таком случае получается кеширование — это костыль?
В общем-то, достаточно серенькая книжка. Честно говоря, узнав, что один из авторов по совместительству является разработчиком языка, я ожидал большего — каких-то вкусных подробностей про внутрянку или неочевидных рекомендаций. Но нет. Получился этакий классический пример неинтересного учебника — книга просто последовательно и нудно описывает разные элементы языка, не особо пытаясь хоть как-то вызвать у читателя интерес. Причем описывается именно язык — то есть подкапотка, которую так любят спрашивать на собесах (GC, внутреннее устройство каналов и прочее вот это все) практически не освещена — за исключением одного места, где описана оптимизация структур по памяти. Совсем не освещаются идиоматически-архитектурные подходы (типа объяснения, как с «ООП головного мозга» переключиться на структуры и зачем вообще нужна динамическая типизация).
За исключением описания race condition — которое реально крутое, подробное и видно, что писалось с душой — все остальное написано довольно уныло, без огонька и только про сам язык.
В общем, если вы только начинаете разбираться с go, то можно и прочитать. Если же вы уже знаете основной синтаксис и ищете более продвинутую инфу — искать ее лучше в другом месте
Редкий случай, когда я читал книгу в бумажном варианте, но я наконец осилил этот шедевр русской школы переводческого дела и теперь просто обязан написать рецензию. Итак, стоит ли читать?
