Проблем-то, собирайте поменьше данных, тогда и утекать будет особо нечему. А ещё неплохо бы не с правительством разговаривать, а со специалистами по ИБ, так и вовсе всем будет лучше.
Коллега, вы неправильно поняли статью. Статья говорит о токсиках совсем чуть-чуть. Больше она раскрывает как когнитивные искажения влияют на бизнесы. Приводит ссылки на приличное количество исследований за широкий промежуток времени. И даёт ссылки на книги, которые по всей видимости действительно стоит прочитать инженерам метящим в руководители. Вы не правы.
Нет, конечно, не представляю. Но я бы и не стал. А вы как раз привели хороший пример "лучше заново написать". Только теперь будут нужны не программисты, а как раз архитекторы и техписы. Архитекторы выделят модули, а техписы опишут требования. Даже менеджеры не будут нужны. И здесь уже дело техники, разбить документацию и требования на блоки, которые можно будет скормить LLM и она напишет РАБОЧИЙ код, для которого будут и документация и требования :) И разбираться в нём тоже не будет необходимости, потому что при возникновении новых бизнес-требований или изменении старых, нужно будет не разобраться в том, что накодили предыдущие команды, а просто сгенерировать новый модуль целиком, рабочий и соотвествующий заявленным требованиям.
Я смотрел одного евангелиста LLM-программирования, и он высказал одну интересную мысль. Он подсветил момент, что да пока LLM генерят что-то "непригодное", но он указал на то, что она может, условно, сегенерить целый проект и потратит на это, скажем, минуту. Основная текущая претензия к LLM сейчас в основном про то, что она не сможет разобраться в сложном проекте, но если она может сгенерить целый проект за минуту, то можно найти такой подход, что разбираться в легаси станет не нужно. Это и сейчас многими инженерами оценивается как "проще заново написать". Опять же есть утверждение, что заказчику в целом всё равно идеальный он код получил под капотом или нет, ему важно соответствие продукта заявленным требованиям, т.е. выходит что настанет момент, когда программисты станут нужны реже, чем, например, сейчас. Т.е. цель создать LMM способную разобраться в любом коде и сделать его идеальным/понятным/чистым, выходит, и не стоит перед разработчиками LLM
Я коротко работал на проекте, где были абстракции, в которых я не без труда разбирался, с очень сложными типами. На мой вопрос "зачем так усложнять?", сказали "для удобства тестирования", там были все эти абстракции с сервисами и репозиториями с DI, в приложении на React (sic). При этом тесты не писали вообще. А багов я там нашёл немало, которые при неочевидных условиях валили приложение. Сам я поддерживаю вынос элементарного кода в функции, чаще всего для повышения самодокументируемости кода.
Т. е. на машину деньги есть, а на стоянку денег нет, пнятненько. Москва и не Москва здесь не при чём, конечно же. Просто в Москве не договоришься с администрацией, как в не в Москве, потому там все начинают голову включать. А когда там эвакуируют пару раз машину с запакованную на тротуаре или газоне, то ещё сильнее начинают голову включать. И конкуренция за место во дворе там гораздо выше. А плата за парковочное место просто заоблачная, и многие мечтают платить эту цену, он не имеют возможности, потому что все доступные парковочные места кто-то уже арендует. Я устал дышать пылью, которой просто ужас сколько, и всё из-за того, что несознательные (я все силы потратил выбирая это слово) автомобилисты паркуются как хотят и где хотят, просто потому что администрация молчит, а граждан высказывающих недовольство в адрес из автовеличества они за людей не считают. Между тем им в голову не приходит, что бо'льшая часть жителей многоэтажки, автомобили во дворе не паркует, однако автомобилисты считают всё свободное место во дворе своим. Это отвратительная позиция считать, что кто-то обязан вам решать ваши проблемы с парковой, и они именно ваши, вы не понимаете, что место во дворе не для паковки, и вы же не понимаете, что за комфорт нужно платить, я имею ввиду, конечно же, стоянки, которых предостаточно.
Человек в итоге справился с задачей, и в общем-то никто не сомневался, что он справится. То же самое касается и разработки, я уверен, что освою новый фреймворк/тулчейн/библиотеку, я профессионал и от меня ничего другого не ожидают. Просто со сроками можно очень сильно промахнуться, если не учесть всех вводных.
Ну вот опять взяли "всех" пользователей и за них высказались. Мне лично, как пользователю, безразличны все 6 фактических пунктов. Как разработчик, я умею их реализовать. К тому же я вроде подчеркнул, что как раз разработчики могут добиться выполнения всех расписанных выше пунктов, просто задачи разработчикам ставит бизнес. Бизнес решает добиваться разработчикам какого-то соответствия каким-то стандартам или нет.
Ну... криворукость пользователей технологии не характеризует технологию в целом. Можно делать SSR тогда страница будет прилетать целиком, но тогда нагрузка на сервер возрастает и ответ от сервера несущий всю разметку целиком тоже тяжелеет. И вообще вы отвлеклись на сожаления, о том как было хорошо и как стало плохо, от критики Реакта в основном на которую я отвечаю. JavaScript позволяет делать многофункциональные интерфейсы, включая 2D и 3D графические редакторы довольно просто, все интерфейсы (программные) предоставляет браузер. Также браузер рисует картинки и тексты и тратит на это ресурсы. Реакт призван минимизировать "рисование". Т.е. он призван помочь браузеру при изменении кусочка состояния "сообщение с сервера прилетело" не всю страницу перерисовывать, а дорисовать всплывашку.
Сайты, кмк, были больше гипертекстовыми документами, чем приложениями, всё же. Это позже, когда данные стали храниться в БД и ренедриться по шаблонам PHP, они стали приложениями. Потом стали добавлять интерактивности AJAX, адаптивности, а когда интернет стал широкополосным и легкодоступным, то всё ПО стало потихоньку переезжать на серверы в интернете. И теперь JavaScript генерирует DOM на лету в соответствии с состоянием хранящемся на клиенте и Реакт справляется с этим вроде как до сих пор быстрее всех.
Всё как-то упирается в "сайты", но Реакт это больше не про сайты, а про веб-приложения. Есть API и клиент. И клиента на рекате ну очень удобно писать. А API, не оглядываясь на клиент, тоже удобно и просто проектировать. Все семь пунктов, особенно седьмой решаются без каких-либо напрягов со стороны разработчика, если есть соотвествующие требования со стороны бизнеса. Всё что может делать браузер управляется JavaScript, и Реакт здесь не исключение.
Projects | LoC | Code Smells JS 299 | 7,496,726 | 217,957 TS 305 | 8,683,600 | 95,132 Table 4: Code smells for JavaScript (JS) and TypeScript (TS) На + млн строк кода в TS в JS показатели в два раза хуже JS 3,435,760 TS 722,687 Table 5: Cognitive complexity (CC) per LoC JS в 4 раза хуже Собственно это уже должно хорошо показывать плюсы использования TS И это ещё в TS есть any, процент его использования в выбранных проектах высокий. Без any дизайн программ ещё лучше был бы и выбор в пользу использования TS был ещё более очевидным. Строгая типизация заставляет думать, но при правильном использовании быстро входит в привычку, и качество кода растёт, а умственные и временные затраты падают.
Джунов чаще невыгодно растить самому работодателю, потому что на время менторинга "дешёвого" специалиста, тратится прилично так времени "дорогого" специалиста, что многие забывают включить в расчёты стоимости конечных затрат.
Антон, я считаю что вы делаете вредную работу, потому что дополнительно искажаете реальность людям с и без того сильно искажённой реальностью. Обесцениваете усилия тех, кто старается стать хорошим профессионалом, потому что множите мнение о том, что стать хорошим профессионалом во-первых легко, во-вторых легко одинаково для всех в любых профессиях. Даже для того, чтобы узнать "как не надо" делать, надо приложить массу усилий, прочитать и проанализировать кучу срачей и выбрать ту или иную сторону, а потом эту сторону защитить. Для того чтобы узнать "как надо делать" нужно иметь длинный опыт, потому что "как надо делать" в одном месте, может запросто оказаться тем "как не надо делать" в другом, именно по-этому, чтобы стать условным сеньёром нужны годы опыта не на одном проекте. Не бывает лёгких денег в длинной перспективе. Приобретая большие деньги ни за что здесь и сейчас вы обязательно теряете что-то важнее денег в длинной перспективе. Мудаков Людей с осознанной меркантильностью не любят в профессиональных кругах, потому что профессионалы - это те, на кого можно положиться, хорошие командные игроки, а для того, чтобы быть хорошим командным игроком, нужно понимать и ставить ценности команды выше собственных, что никак не возможно, будучи меркантильным. Возвращаясь к теме потерь в длинной перспективе в погоне за скорой наживой, скажу, что потерять можно будущие интересные контракты, подкинутые бывшими коллегами, хорошее место работы, редчайший опыт, честное имя в конце концов. А ведь и правда многие вещи в ИТ хорошо освоить несложно, если есть хотя бы стремление освоить их хорошо, и перспективы построить длинную хорошую карьеру в ИТ, и получать ЗП значительно выше других профессий долго пока ещё остаются. Мне кажется ваши поклонники ощутят вредность ваших советов, когда закончится вездесущая диджитализация, и рынок станет не таким сумасшедшим. В принципе банки, взвинтившие цены на неквалифицированный ИТ-труд, очень скоро перестанут столько платить, т.к. их сверхприбыли на льготных иппотеках уже почти закончились и на хороших местах останутся те, кто на них должен быть - хорошие профессионалы.
Не стоит забывать, что Apple первыми добились бессмысленности кражи телефона (в том числе с нанесением тяжких телесных повреждений) для сбыта оного на запчасти. Для меня как обладателя телефона за $1000, бывающего в относительно диких уголках РФ это важно. Видимо их уродская политика восстановления обусловлена в том числе и такой заботой о пользователях. Статья восхитительная, спасибо вам за неё.
Обожаю эту игру. Играл с 2023. Море восторга. Как GTA V, только в космосе. Скатился в деланье бабла на крафте дорогущих штук на 40 млн в сутки, думал: "Сделаю млрд и пойду по миссиям", но не пошёл) и всё же обожаю её. Великолепные космические приключения.
Весьма спорное мнение. Раз уж вы сдали свои мозги в аренду, именно это и есть работа по найму, то будьте любезны соответствовать. "Бизнес", это не только выгодополучатели, но и потребители. Ваша забота - потребители. "Сдать подороже" - это аналог "кидалова", ведь у всего на свете, есть справедливая рыночная цена. Поставьте себя на место нанимателя и вы поймёте как вы не правы. Судя по всему, вы имеете доступ к информации о валовой прибыли и не понимаете какие бизнес имеет расходы, кроме расходов на ваш уникальный и незаменимый труд. Если вы не помогли бизнесу заработать, когда была такая возможность, вы кинули людей на бабки.
REpresentational State Transfer ни словечка про это. Таким образом первое правило не существует. Второе правило про HTTP, но не про REST Третье правило про кэширование, но не про REST Четвертое правило - протокол (HTTP) и архитекnрутный стиль (REST), как следует из википедии, не одно и то же. Не стоит путать тёплое с мягким. Правила протокола нарушать нельзя, архитектурные правила, можно, если очень захотеть. И далее всё про HTTP, а не про REST. И это ещё никто не упомянул про RESTful
Признаюсь, не слежу. Но там написано сразу же успокаивающее: Сопровождение старых веток Redis 7.x, выпущенных до смены лицензии, будет продолжаться как минимум до выпуска Redis Community Edition 9.0 Если вам не нужен Redis-кластер (а он нам не нужен же в этом посте) можно не беспокоиться и продолжать им пользоваться. В принципе, если приложение простое, то можно и простой Dict/Map/Set использовать и хранить его в JSON файле.
Проблем-то, собирайте поменьше данных, тогда и утекать будет особо нечему. А ещё неплохо бы не с правительством разговаривать, а со специалистами по ИБ, так и вовсе всем будет лучше.
Коллега, вы неправильно поняли статью. Статья говорит о токсиках совсем чуть-чуть. Больше она раскрывает как когнитивные искажения влияют на бизнесы. Приводит ссылки на приличное количество исследований за широкий промежуток времени. И даёт ссылки на книги, которые по всей видимости действительно стоит прочитать инженерам метящим в руководители. Вы не правы.
Нет, конечно, не представляю. Но я бы и не стал. А вы как раз привели хороший пример "лучше заново написать". Только теперь будут нужны не программисты, а как раз архитекторы и техписы. Архитекторы выделят модули, а техписы опишут требования. Даже менеджеры не будут нужны. И здесь уже дело техники, разбить документацию и требования на блоки, которые можно будет скормить LLM и она напишет РАБОЧИЙ код, для которого будут и документация и требования :)
И разбираться в нём тоже не будет необходимости, потому что при возникновении новых бизнес-требований или изменении старых, нужно будет не разобраться в том, что накодили предыдущие команды, а просто сгенерировать новый модуль целиком, рабочий и соотвествующий заявленным требованиям.
Я смотрел одного евангелиста LLM-программирования, и он высказал одну интересную мысль. Он подсветил момент, что да пока LLM генерят что-то "непригодное", но он указал на то, что она может, условно, сегенерить целый проект и потратит на это, скажем, минуту. Основная текущая претензия к LLM сейчас в основном про то, что она не сможет разобраться в сложном проекте, но если она может сгенерить целый проект за минуту, то можно найти такой подход, что разбираться в легаси станет не нужно. Это и сейчас многими инженерами оценивается как "проще заново написать". Опять же есть утверждение, что заказчику в целом всё равно идеальный он код получил под капотом или нет, ему важно соответствие продукта заявленным требованиям, т.е. выходит что настанет момент, когда программисты станут нужны реже, чем, например, сейчас. Т.е. цель создать LMM способную разобраться в любом коде и сделать его идеальным/понятным/чистым, выходит, и не стоит перед разработчиками LLM
Я коротко работал на проекте, где были абстракции, в которых я не без труда разбирался, с очень сложными типами. На мой вопрос "зачем так усложнять?", сказали "для удобства тестирования", там были все эти абстракции с сервисами и репозиториями с DI, в приложении на React (sic). При этом тесты не писали вообще. А багов я там нашёл немало, которые при неочевидных условиях валили приложение.
Сам я поддерживаю вынос элементарного кода в функции, чаще всего для повышения самодокументируемости кода.
Т. е. на машину деньги есть, а на стоянку денег нет, пнятненько. Москва и не Москва здесь не при чём, конечно же. Просто в Москве не договоришься с администрацией, как в не в Москве, потому там все начинают голову включать. А когда там эвакуируют пару раз машину с запакованную на тротуаре или газоне, то ещё сильнее начинают голову включать. И конкуренция за место во дворе там гораздо выше. А плата за парковочное место просто заоблачная, и многие мечтают платить эту цену, он не имеют возможности, потому что все доступные парковочные места кто-то уже арендует.
Я устал дышать пылью, которой просто ужас сколько, и всё из-за того, что несознательные (я все силы потратил выбирая это слово) автомобилисты паркуются как хотят и где хотят, просто потому что администрация молчит, а граждан высказывающих недовольство в адрес из автовеличества они за людей не считают. Между тем им в голову не приходит, что бо'льшая часть жителей многоэтажки, автомобили во дворе не паркует, однако автомобилисты считают всё свободное место во дворе своим. Это отвратительная позиция считать, что кто-то обязан вам решать ваши проблемы с парковой, и они именно ваши, вы не понимаете, что место во дворе не для паковки, и вы же не понимаете, что за комфорт нужно платить, я имею ввиду, конечно же, стоянки, которых предостаточно.
Человек в итоге справился с задачей, и в общем-то никто не сомневался, что он справится. То же самое касается и разработки, я уверен, что освою новый фреймворк/тулчейн/библиотеку, я профессионал и от меня ничего другого не ожидают. Просто со сроками можно очень сильно промахнуться, если не учесть всех вводных.
Ну вот опять взяли "всех" пользователей и за них высказались. Мне лично, как пользователю, безразличны все 6 фактических пунктов. Как разработчик, я умею их реализовать. К тому же я вроде подчеркнул, что как раз разработчики могут добиться выполнения всех расписанных выше пунктов, просто задачи разработчикам ставит бизнес. Бизнес решает добиваться разработчикам какого-то соответствия каким-то стандартам или нет.
Ну... криворукость пользователей технологии не характеризует технологию в целом. Можно делать SSR тогда страница будет прилетать целиком, но тогда нагрузка на сервер возрастает и ответ от сервера несущий всю разметку целиком тоже тяжелеет. И вообще вы отвлеклись на сожаления, о том как было хорошо и как стало плохо, от критики Реакта в основном на которую я отвечаю. JavaScript позволяет делать многофункциональные интерфейсы, включая 2D и 3D графические редакторы довольно просто, все интерфейсы (программные) предоставляет браузер. Также браузер рисует картинки и тексты и тратит на это ресурсы. Реакт призван минимизировать "рисование". Т.е. он призван помочь браузеру при изменении кусочка состояния "сообщение с сервера прилетело" не всю страницу перерисовывать, а дорисовать всплывашку.
Сайты, кмк, были больше гипертекстовыми документами, чем приложениями, всё же. Это позже, когда данные стали храниться в БД и ренедриться по шаблонам PHP, они стали приложениями. Потом стали добавлять интерактивности AJAX, адаптивности, а когда интернет стал широкополосным и легкодоступным, то всё ПО стало потихоньку переезжать на серверы в интернете. И теперь JavaScript генерирует DOM на лету в соответствии с состоянием хранящемся на клиенте и Реакт справляется с этим вроде как до сих пор быстрее всех.
Всё как-то упирается в "сайты", но Реакт это больше не про сайты, а про веб-приложения. Есть API и клиент. И клиента на рекате ну очень удобно писать. А API, не оглядываясь на клиент, тоже удобно и просто проектировать.
Все семь пунктов, особенно седьмой решаются без каких-либо напрягов со стороны разработчика, если есть соотвествующие требования со стороны бизнеса. Всё что может делать браузер управляется JavaScript, и Реакт здесь не исключение.
Projects | LoC | Code Smells
JS 299 | 7,496,726 | 217,957
TS 305 | 8,683,600 | 95,132
Table 4: Code smells for JavaScript (JS) and TypeScript (TS)
На + млн строк кода в TS в JS показатели в два раза хуже
JS 3,435,760
TS 722,687
Table 5: Cognitive complexity (CC) per LoC
JS в 4 раза хуже
Собственно это уже должно хорошо показывать плюсы использования TS
И это ещё в TS есть any, процент его использования в выбранных проектах высокий. Без any дизайн программ ещё лучше был бы и выбор в пользу использования TS был ещё более очевидным.
Строгая типизация заставляет думать, но при правильном использовании быстро входит в привычку, и качество кода растёт, а умственные и временные затраты падают.
Джунов чаще невыгодно растить самому работодателю, потому что на время менторинга "дешёвого" специалиста, тратится прилично так времени "дорогого" специалиста, что многие забывают включить в расчёты стоимости конечных затрат.
Антон, я считаю что вы делаете вредную работу, потому что дополнительно искажаете реальность людям с и без того сильно искажённой реальностью. Обесцениваете усилия тех, кто старается стать хорошим профессионалом, потому что множите мнение о том, что стать хорошим профессионалом во-первых легко, во-вторых легко одинаково для всех в любых профессиях.
Даже для того, чтобы узнать "как не надо" делать, надо приложить массу усилий, прочитать и проанализировать кучу срачей и выбрать ту или иную сторону, а потом эту сторону защитить. Для того чтобы узнать "как надо делать" нужно иметь длинный опыт, потому что "как надо делать" в одном месте, может запросто оказаться тем "как не надо делать" в другом, именно по-этому, чтобы стать условным сеньёром нужны годы опыта не на одном проекте.
Не бывает лёгких денег в длинной перспективе. Приобретая большие деньги ни за что здесь и сейчас вы обязательно теряете что-то важнее денег в длинной перспективе.
МудаковЛюдей с осознанной меркантильностью не любят в профессиональных кругах, потому что профессионалы - это те, на кого можно положиться, хорошие командные игроки, а для того, чтобы быть хорошим командным игроком, нужно понимать и ставить ценности команды выше собственных, что никак не возможно, будучи меркантильным. Возвращаясь к теме потерь в длинной перспективе в погоне за скорой наживой, скажу, что потерять можно будущие интересные контракты, подкинутые бывшими коллегами, хорошее место работы, редчайший опыт, честное имя в конце концов.А ведь и правда многие вещи в ИТ хорошо освоить несложно, если есть хотя бы стремление освоить их хорошо, и перспективы построить длинную хорошую карьеру в ИТ, и получать ЗП значительно выше других профессий долго пока ещё остаются.
Мне кажется ваши поклонники ощутят вредность ваших советов, когда закончится вездесущая диджитализация, и рынок станет не таким сумасшедшим. В принципе банки, взвинтившие цены на неквалифицированный ИТ-труд, очень скоро перестанут столько платить, т.к. их сверхприбыли на льготных иппотеках уже почти закончились и на хороших местах останутся те, кто на них должен быть - хорошие профессионалы.
Не стоит забывать, что Apple первыми добились бессмысленности кражи телефона (в том числе с нанесением тяжких телесных повреждений) для сбыта оного на запчасти. Для меня как обладателя телефона за $1000, бывающего в относительно диких уголках РФ это важно. Видимо их уродская политика восстановления обусловлена в том числе и такой заботой о пользователях. Статья восхитительная, спасибо вам за неё.
Обожаю эту игру. Играл с 2023. Море восторга. Как GTA V, только в космосе. Скатился в деланье бабла на крафте дорогущих штук на 40 млн в сутки, думал: "Сделаю млрд и пойду по миссиям", но не пошёл) и всё же обожаю её. Великолепные космические приключения.
Весьма спорное мнение. Раз уж вы сдали свои мозги в аренду, именно это и есть работа по найму, то будьте любезны соответствовать. "Бизнес", это не только выгодополучатели, но и потребители. Ваша забота - потребители. "Сдать подороже" - это аналог "кидалова", ведь у всего на свете, есть справедливая рыночная цена.
Поставьте себя на место нанимателя и вы поймёте как вы не правы. Судя по всему, вы имеете доступ к информации о валовой прибыли и не понимаете какие бизнес имеет расходы, кроме расходов на ваш уникальный и незаменимый труд.
Если вы не помогли бизнесу заработать, когда была такая возможность, вы кинули людей на бабки.
REpresentational State Transfer ни словечка про это. Таким образом первое правило не существует.
Второе правило про HTTP, но не про REST
Третье правило про кэширование, но не про REST
Четвертое правило - протокол (HTTP) и архитекnрутный стиль (REST), как следует из википедии, не одно и то же. Не стоит путать тёплое с мягким. Правила протокола нарушать нельзя, архитектурные правила, можно, если очень захотеть.
И далее всё про HTTP, а не про REST.
И это ещё никто не упомянул про RESTful
Признаюсь, не слежу. Но там написано сразу же успокаивающее:
Сопровождение старых веток Redis 7.x, выпущенных до смены лицензии, будет продолжаться как минимум до выпуска Redis Community Edition 9.0Если вам не нужен Redis-кластер (а он нам не нужен же в этом посте) можно не беспокоиться и продолжать им пользоваться. В принципе, если приложение простое, то можно и простой Dict/Map/Set использовать и хранить его в JSON файле.
В таком случае ваш комментарий также вводит в заблуждение и ограничение на какую-то длину должно быть учтено в библиотеке: