Честно говоря, не знаю о чём тут вообще спорить. Для меня изменение в рабочих процессах вполне очевидное: теперь можно код не писать, а читать. Как обыкновенное алгоритмическое автодополнение а-ля Intellisense, только генерящее на 2-3 порядка больше кода за один раз.
Программист не код пишет, а превращает описание задачи на бизнес-языке в описание задачи на языке программирования. Он прежде всего отвечает за адекватность этого превращения, для чего ему нужны знания не только в информатике, но и в предметной области, а ещё здравый смысл. Любой разработчик неизбежно знакомится с предметной областью в той или иной степени, иначе он просто не нужен в проекте.
Вот собственно эту «адекватность превращения бизнес-задачи в код» пока непонятно как возлагать на LLM. Это так же странно, как возлагать эту адекватность целиком на джуна, пришедшего в проект 2 недели назад, без какого-либо ревью его работы.
Десятки лет развития языков и методологий программирования были направлены на то, чтобы человек, как существо ненадёжное по своей природе, могло создать что-то БОЛЕЕ надёжное, чем он сам. Мы придумали для этого статическую типизацию, мы придумали для этого кучу различных видов тестирования, где-то даже используют формальную верификацию. И самое главное: код — эта такая штука, которую могут почитать НЕСКОЛЬКО человек (в том числе и сам автор через некоторый промежуток времени). Такая вот коллективная и итеративная работа над кодом даёт нам шанс делать системы более надёжные и продуманные, чем каждый человек может по-отдельности.
Не вижу чтобы нейросети тут кардинально что-то поменяли кроме того, что теперь «автодополнение» подставляет вам не название функции, а создаёт сразу PR. Но ответственность за соответствие этого PR задачам бизнеса по-прежнему лежит на вас.
Всё уже придумали, проблема в скорости шины, это сразу становится горлышком. Видеокарта это такая тварь, которая требует не только много питания, но и много шины. Я бы сказал что видеокарты в потребительских ПК - основной потребитель ширины PCI Express, по сравнению с которым всё остальное (SSD, USB/TB) это слёзы.
Это вопрос выбора "базы данных" для хранения таких поясняющих комментариев. Гит - это распределённая система, и всё что у вас в истории можно в две команды перелить с какого-нибудь Bitbucker Server на Gitlab или какой-нибудь Gitea. А мигрировать содержимое Jira уже сложнее.
Если бы не 2022-й, я бы тоже не считал это проблемой, но 2022-й случился.
Надо, вроде, чтобы весь код работал правильно и согласованно, а не каждый коммит по отдельности?
А это уж как вы организовали у себя в проекте/команде. Я прошу разработчиков делать атомарные коммиты, которые переводят репозиторий из одного работающего состояния в другое работающее (включая компилируемость кода и проходящие юнит-тесты). Да, это не всегда удаётся, поэтому у нас договорённость - если в коммите что-то сломано и починится в следующем, желательно об этом написать.
Сейчас многие проекты выбрали для себя единицей изменений именно МР, а коммиты остаются целиком инструментом для автора кода - коммить когда вздумается, всё равно мы будем смотреть только весь МР сразу. Это может работать, но становится неподъёмным, когда количество ревью через одного человека резко возрастает (например, команда за полгода увеличилась в 2-3 раза). Тогда начинаешь задумываться о том, что коммиты неплохо бы использовать по их изначальному назначению: как атомарную единицу изменений в проекте.
Как разбивка на коммиты помогает понять, что происходит в коде, стесняюсь спросить?
Ну если коммит-мессадж такой: "fixed a bug", то никак не помогает. А если коммит-мессадж такой, то в код можно и не смотреть в теории. По крайней мере смотреть в код придётся только ревьюеру, а если кто-то позже придёт почитать - коммит-мессадж будет даже полезнее кода.
В общем целом я бы сказал что лучше небольшой самостоятельный МР из одного коммита, чем большой МР из десятка коммитов.
Это безусловно так и есть. Не знаю ни одного разработчика и ревьюера, который просил бы побольше изменений закинуть в один МР вместо нескольких. Но МР для того и придумали, что это такая единица изменений/работы над проектом, которую можно целиком применить, а потом целиком откатить, если припекло. И такая единица далеко не всегда будет совпадать с единицей "загрузки изменений в голову читателя" (коммитом), т.к. первая обычно значительно больше.
Понятное дело что в любом приличном проекте есть feature flags и подобные штуки, чтобы не показывать юзерам недопиленные фичи, но всё же это касается в основном нового кода. Недорефакторенный старый код в прод не выкатишь, а значит недоделанный МР не смёржишь (разумеется сегодня бизнес хочет релизиться если каждый день, то в любом момент когда потребуется, поэтому мастер/релизная-ветка должна быть всегда в рабочем состоянии).
Так что "маленькие" МР — это здорово, но встречается довольно редко. Обычно когда мне приходит МР с одним коммитом - это человек просто не умеет пользоваться коммитами и напихал кучу изменений в один коммит, а мне теперь как-то за 20 минут нужно успеть понять, что в нём происходит (иначе я ничего не успею). Так что текст коммита — это скорее механизм работы с головой читателя кода, и кмк его полезно использовать.
Ну и что хорошего в том, что вы не смотрите на текст коммита? Почему не сделать из этого инструмент и не начать им пользоваться?
Нет, я понимаю к чему вы про забор: в прод пойдёт код, а не текст коммита. Но можно сидеть 20 минут пытаться понять чего именно добивался человек этими изменениями, а можно прочитать текст коммита и понятно станет за 3 минуты.
Кроме того, правильное пользование коммитами позволяет автору кода загружать изменения в голову ревьюера правильными порциями. В моём случае это вообще самое важное: чтобы не зависать на каждом МР на час (коих за день может быть с десяток-другой), я прошу перед отправкой на ревью сделать нормальные коммиты, чтобы можно было смотреть ревью по ним, а не сразу всё.
Большинcтво компонентов софта не живет больше 1-2 лет, за исключением энтерпрайза и некоторых других исключений, не надо думать и закладывать туда все возможное и делать максимально универсально.
Тут что-то на фронтэндерском, не получается прочитать.
Как вы на HH определяете, как развивается карьера отдельных людей? Вот у меня из пяти знакомых:
трое ушли с десктопного C++ на бэкенд и Go;
ещё один перешёл с Electron на бэкенд (тоже Go);
ещё один хотел бы перейти с Electron на бэкенд (пока этого не сделал, но сделает как только пройдёт собесы в интересующие его компании). Правда этот парень бывший плюсовик, на Electron его занесло скорее вынужденно.
Причём и не скажешь, что они ушли из какой-то одной компании (где было всё сильно плохо) или пришли в какую-то одну компанию (где было всё сильно хорошо), компании разные. Справедливости ради, есть и такой знакомый, который остался на десктопном C++, но уехал из РФ в стартап с довольно щедрыми зарплатами, поэтому всем доволен и так.
Зайдите на стримы к разных популярным ребятам, и посмотрите на качество их картинки. А потом посмотрите на их сетап. Ну например: Sony A7 IV и Sony A7С (да, аж две камеры сразу, чтобы красиво было!).
Пока Microsoft, Apple и прочие гиганты бились за звание главной платформы для запуска клиентского кода, Google тихонечко закатила всем в огород троянского коня в виде Хрома. И получилась такая вот интересная ситуация, что теперь "операционной системой" (а точнее, средой для работы клиентского приложения) является браузер, а не натив. И эта среда победила. Почему - уже написали предыдущие комментаторы.
JS и сейчас относительно конченный язык, а году в 2013-м это был ад и Израиль. И ничего, все пошли колоться об этот кактус. Чтобы писать под победившую среду запуска клиентского кода. Побежали все переписывать старые проекты - MS переписала Офис, Гугл же написал свой офис сразу в вебе.
Уже все и забыли, что "Веб" - это про организацию информации прежде всего, а не про HTML/CSS/JS.
Теперь разработчиков под нативный десктоп и нет толком. Точнее, они есть, но им за их знания заплатят намного больше, например, на бэкенде. А над клиентским десктопом можно издеваться, память-то там клиентская, она "бесплатная" для компании, в отличие от памяти на серверах.
Зато навалом разрабов под браузер, стоят они приемлемо, вот и вся история.
Вот на мобилках ресурсов поменьше, и там веба почти нет - каждый второй проект делает себе приложение и переманивает туда всякого, кто зашёл на сайт с мобилы.
А, самое главное: на десктопах толком не прижились магазины приложений. На мобилках юзеров к этому приучили с горшка, и проблема деливери/автоапдейта была решена на корню. А десктоп уже слишком стар как концепция, чтобы его юзеров можно было заставить что-то делать иначе. Microsoft Store почти никому не нужен, Snap Store тоже, разве что на Маке удалось более-менее посадить на их магаз.
А задача - открывать на просмотр такие архивы, ибо распаковывать их целиком просто для "посмотреть" - это практически нереально. Вернее, когда у вас ext4 на NVMe-диске - может и реально, но не когда NTFS на магнитном.
Вполне себе хранятся миллионы файлов и на ноуте с NTFS
Хранятся-то они замечательно, вы попробуйте удалить их потом. Задача на полдня примерно. Если бы всё так было хорошо с NTFS, зачем бы тогда MS придумала использовать ReFS в своей фиче Dev Drive.
Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
“Вот понаберут глупых новичков, а мне потом за ними РАЗГРЕБАТЬ!”. Что это за инженер с 10-летним опытом, вынужденный исправлять ошибки за сокомандником? Почему крутые специалисты просто не откажут неадекватным кандидатам, не пустив их в свой продукт?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Самый эффективный инструмент для трудоустройства и зарплатного роста в IT
Чтобы контент приносил результат, его надо выпускать регулярно. Только так вы добьетесь нужного количества касаний с нужной аудиторией. Это значит, что делать одну висишку раз в полгода — это не контент-маркетинг.
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Как скоро они выгорят от не своей работы?
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?
Статья коротко: Делай хорошо, плохо не делай. Вот мой телеграм-канал.
Честно говоря, не знаю о чём тут вообще спорить.
Для меня изменение в рабочих процессах вполне очевидное: теперь можно код не писать, а читать. Как обыкновенное алгоритмическое автодополнение а-ля Intellisense, только генерящее на 2-3 порядка больше кода за один раз.
Программист не код пишет, а превращает описание задачи на бизнес-языке в описание задачи на языке программирования. Он прежде всего отвечает за адекватность этого превращения, для чего ему нужны знания не только в информатике, но и в предметной области, а ещё здравый смысл. Любой разработчик неизбежно знакомится с предметной областью в той или иной степени, иначе он просто не нужен в проекте.
Вот собственно эту «адекватность превращения бизнес-задачи в код» пока непонятно как возлагать на LLM. Это так же странно, как возлагать эту адекватность целиком на джуна, пришедшего в проект 2 недели назад, без какого-либо ревью его работы.
Десятки лет развития языков и методологий программирования были направлены на то, чтобы человек, как существо ненадёжное по своей природе, могло создать что-то БОЛЕЕ надёжное, чем он сам. Мы придумали для этого статическую типизацию, мы придумали для этого кучу различных видов тестирования, где-то даже используют формальную верификацию. И самое главное: код — эта такая штука, которую могут почитать НЕСКОЛЬКО человек (в том числе и сам автор через некоторый промежуток времени). Такая вот коллективная и итеративная работа над кодом даёт нам шанс делать системы более надёжные и продуманные, чем каждый человек может по-отдельности.
Не вижу чтобы нейросети тут кардинально что-то поменяли кроме того, что теперь «автодополнение» подставляет вам не название функции, а создаёт сразу PR. Но ответственность за соответствие этого PR задачам бизнеса по-прежнему лежит на вас.
Боже, как славно что я долистал до этого комментария, а то какой-то осадок неприятный был всё это время.
Всё уже придумали, проблема в скорости шины, это сразу становится горлышком. Видеокарта это такая тварь, которая требует не только много питания, но и много шины. Я бы сказал что видеокарты в потребительских ПК - основной потребитель ширины PCI Express, по сравнению с которым всё остальное (SSD, USB/TB) это слёзы.
Это вопрос выбора "базы данных" для хранения таких поясняющих комментариев. Гит - это распределённая система, и всё что у вас в истории можно в две команды перелить с какого-нибудь Bitbucker Server на Gitlab или какой-нибудь Gitea. А мигрировать содержимое Jira уже сложнее.
Если бы не 2022-й, я бы тоже не считал это проблемой, но 2022-й случился.
А это уж как вы организовали у себя в проекте/команде. Я прошу разработчиков делать атомарные коммиты, которые переводят репозиторий из одного работающего состояния в другое работающее (включая компилируемость кода и проходящие юнит-тесты). Да, это не всегда удаётся, поэтому у нас договорённость - если в коммите что-то сломано и починится в следующем, желательно об этом написать.
Сейчас многие проекты выбрали для себя единицей изменений именно МР, а коммиты остаются целиком инструментом для автора кода - коммить когда вздумается, всё равно мы будем смотреть только весь МР сразу. Это может работать, но становится неподъёмным, когда количество ревью через одного человека резко возрастает (например, команда за полгода увеличилась в 2-3 раза). Тогда начинаешь задумываться о том, что коммиты неплохо бы использовать по их изначальному назначению: как атомарную единицу изменений в проекте.
Ну если коммит-мессадж такой: "fixed a bug", то никак не помогает. А если коммит-мессадж такой, то в код можно и не смотреть в теории. По крайней мере смотреть в код придётся только ревьюеру, а если кто-то позже придёт почитать - коммит-мессадж будет даже полезнее кода.
Это безусловно так и есть. Не знаю ни одного разработчика и ревьюера, который просил бы побольше изменений закинуть в один МР вместо нескольких.
Но МР для того и придумали, что это такая единица изменений/работы над проектом, которую можно целиком применить, а потом целиком откатить, если припекло. И такая единица далеко не всегда будет совпадать с единицей "загрузки изменений в голову читателя" (коммитом), т.к. первая обычно значительно больше.
Понятное дело что в любом приличном проекте есть feature flags и подобные штуки, чтобы не показывать юзерам недопиленные фичи, но всё же это касается в основном нового кода. Недорефакторенный старый код в прод не выкатишь, а значит недоделанный МР не смёржишь (разумеется сегодня бизнес хочет релизиться если каждый день, то в любом момент когда потребуется, поэтому мастер/релизная-ветка должна быть всегда в рабочем состоянии).
Так что "маленькие" МР — это здорово, но встречается довольно редко. Обычно когда мне приходит МР с одним коммитом - это человек просто не умеет пользоваться коммитами и напихал кучу изменений в один коммит, а мне теперь как-то за 20 минут нужно успеть понять, что в нём происходит (иначе я ничего не успею). Так что текст коммита — это скорее механизм работы с головой читателя кода, и кмк его полезно использовать.
Ну и что хорошего в том, что вы не смотрите на текст коммита? Почему не сделать из этого инструмент и не начать им пользоваться?
Нет, я понимаю к чему вы про забор: в прод пойдёт код, а не текст коммита. Но можно сидеть 20 минут пытаться понять чего именно добивался человек этими изменениями, а можно прочитать текст коммита и понятно станет за 3 минуты.
Кроме того, правильное пользование коммитами позволяет автору кода загружать изменения в голову ревьюера правильными порциями. В моём случае это вообще самое важное: чтобы не зависать на каждом МР на час (коих за день может быть с десяток-другой), я прошу перед отправкой на ревью сделать нормальные коммиты, чтобы можно было смотреть ревью по ним, а не сразу всё.
Тут что-то на фронтэндерском, не получается прочитать.
Как вы на HH определяете, как развивается карьера отдельных людей?
Вот у меня из пяти знакомых:
трое ушли с десктопного C++ на бэкенд и Go;
ещё один перешёл с Electron на бэкенд (тоже Go);
ещё один хотел бы перейти с Electron на бэкенд (пока этого не сделал, но сделает как только пройдёт собесы в интересующие его компании). Правда этот парень бывший плюсовик, на Electron его занесло скорее вынужденно.
Причём и не скажешь, что они ушли из какой-то одной компании (где было всё сильно плохо) или пришли в какую-то одну компанию (где было всё сильно хорошо), компании разные.
Справедливости ради, есть и такой знакомый, который остался на десктопном C++, но уехал из РФ в стартап с довольно щедрыми зарплатами, поэтому всем доволен и так.
Зайдите на стримы к разных популярным ребятам, и посмотрите на качество их картинки. А потом посмотрите на их сетап. Ну например: Sony A7 IV и Sony A7С (да, аж две камеры сразу, чтобы красиво было!).
Давайте начистоту.
Пока Microsoft, Apple и прочие гиганты бились за звание главной платформы для запуска клиентского кода, Google тихонечко закатила всем в огород троянского коня в виде Хрома. И получилась такая вот интересная ситуация, что теперь "операционной системой" (а точнее, средой для работы клиентского приложения) является браузер, а не натив. И эта среда победила. Почему - уже написали предыдущие комментаторы.
JS и сейчас относительно конченный язык, а году в 2013-м это был ад и Израиль. И ничего, все пошли колоться об этот кактус. Чтобы писать под победившую среду запуска клиентского кода. Побежали все переписывать старые проекты - MS переписала Офис, Гугл же написал свой офис сразу в вебе.
Уже все и забыли, что "Веб" - это про организацию информации прежде всего, а не про HTML/CSS/JS.
Теперь разработчиков под нативный десктоп и нет толком. Точнее, они есть, но им за их знания заплатят намного больше, например, на бэкенде. А над клиентским десктопом можно издеваться, память-то там клиентская, она "бесплатная" для компании, в отличие от памяти на серверах.
Зато навалом разрабов под браузер, стоят они приемлемо, вот и вся история.
Вот на мобилках ресурсов поменьше, и там веба почти нет - каждый второй проект делает себе приложение и переманивает туда всякого, кто зашёл на сайт с мобилы.
А, самое главное: на десктопах толком не прижились магазины приложений. На мобилках юзеров к этому приучили с горшка, и проблема деливери/автоапдейта была решена на корню. А десктоп уже слишком стар как концепция, чтобы его юзеров можно было заставить что-то делать иначе. Microsoft Store почти никому не нужен, Snap Store тоже, разве что на Маке удалось более-менее посадить на их магаз.
Думаю самый лучший вариант - приложение Tino. Если удалят и его, то в этот момент Apple как бы сама себя удалит из своего магазина.
Это чеболизация по-российски.
А задача - открывать на просмотр такие архивы, ибо распаковывать их целиком просто для "посмотреть" - это практически нереально. Вернее, когда у вас ext4 на NVMe-диске - может и реально, но не когда NTFS на магнитном.
Ну там не один архив на 105, а несколько (самый большой на ~16 Гб), но дело-то в другом - что не мне выбирать, как упаковывать, ибо торрент не мой.
А хороший софт потому и хорош, что он хорошо справляется не только с "лёгкими" и популярными кейсами, но в том числе и с не совсем адекватными.
Хранятся-то они замечательно, вы попробуйте удалить их потом. Задача на полдня примерно.
Если бы всё так было хорошо с NTFS, зачем бы тогда MS придумала использовать ReFS в своей фиче Dev Drive.
Если я распакую каждый архив из 105-гигайбайтовой утечки исходников Twitch-а, у меня ФС загнётся от количества файлов. Зачем, если можно архиватором вытаскивать нужные подпапки?
Так, стоп. Разве это не гейткипинг? Т.е. вся остальная статья не имеет смысла? Почему спрашиваю: потому что для меня это основной (если не единственный) аргумент заливать про Таненбаума, CS и всё прочее. Хочется в какой-то момент перестать подтирать за человеком, а он пока даже не понимает, а почему, собственно, за ним подтёрли.
Всё понятно. Рад знакомству (нет).
Как-то всё это грустно. Про «регулярно», про «касания». Когда автор прибегает к помощи редакторов/писателей/прочих специалистов по выражению мыслей и идей в достойном виде — тогда и результат достойный. А вот когда делается наоборот, потому что нужны «касания» — такое себе.
Впрочем, о чём это я, я же просто не с той стороны рта нахожусь. Люди работу работают, а мы потом будем выискивать сокровища в информационной свалке.
А вот за эту статью спасибо! Вот её как раз писали именно те люди, которые «кто ручками каждый день в ней [теме] ковыряется».
Неужели хороших авторов настолько мало и они настолько недоступны, что не вариант идти по пути их выращивания и менторства?