Сейчас автомобили с ИИ начинкой ездят на автопилоте по реальным автомобильным дорогам, там масштаб ответственности повыше будет, чем "не попасть по пальцу забивая гвоздь"
Если использовать LLM чтобы он делал работу ВМЕСТО вас, то да, результат будет не обнадёживающий. Здесь же речь идёт о том, чтобы использовать его В ПОМОЩЬ себе, проверяя и дорабатывая его результаты. Приведены примеры как это можно сделать. Некомпетентные архитекторы БД были и до LLM, и всегда будут. А компетентным ИИ может помочь в работе, например массово внося изменения в таблицы. Неужто этот факт настолько плох, что нужно яростно минусить и статью с примерами, и все мои комменты?)))
Я сам не перестаю удивляться, я был в восторге ещё когда просто в режиме чата можно было общаться как с человеком, а сейчас ИИ уже и в файлах с кодом ориентируется, может создавать новые, вносить изменения сразу в несколько файлов, базы данных проектирует, и прогресс в ИИ-инструментах очень быстро идёт! Только и успевай узнавать, что ещё нового вышло, и как этим улучшить свои процессы!
Абсолютно верно, и ИМХО больше всего ценятся и будут цениться как раз специалисты, обладающие глубокой технической экспертизой, и навыками эффективного использования современных вспомогательных инструментов вроде искусственного интеллекта. Такие люди всегда будут очень востребованны, и как выразился pg_expecto, будут диктовать ценник за услуги
Благодарю за комментарий! Почувствовал в нём нотку сарказма, здесь стоит упомянуть, что всё приносит пользу при правильном использовании, и вред при неправильном. И молотком можно ударить по пальцем, но это не значит, что молоток плохой – то же самое и с использованием нейросетей. Если их использовать бездумно, без понимания технического аспекта, не проверяя результат, и не пытаясь понять как он устроен – на выходе будет УГ. А если же точечно просить ИИ выполнить что-то, декомпозируя задачи, и детально описывая желаемый результат и его особенности, то достаточно быстро можно получить очень достойный результат. Что касается ORM – за счёт своей универсальности и удобства чтения, они действительно порой генерируют неэффективный громоздкий код, который долго выполняется. И тут между прочим, кроме шуток, может хорошо помочь ИИ, который напишет под задачу чистый SQL запрос.
Где вот только взять этого редкого зверя "профессионального ИТ-менеджера"? Я вот ищу-ищу, кого-то нахожу, только вот меня никак не может пока никто заменить. Людям проще слиться с проекта, или зафакапиться, чем включиться и грамотно довести дело до конца...
Жесть, сколько танцев с бубном! Я думал это будет не сложнее регистрации в Google Search Console... Хотел вывести свой инструмент по проектированию баз данных database-design.ru на глобальный рынок, уже перевёл на английский и китайский, а тут ещё недостаточно перевести оказалось... Ну ладно, двигаемся дальше..
Полностью согласен с автором. Я сам ведущий разработчик, и получал ТЗ от системного аналитика, где тот пытался спроектировать схему базы данных. В силу недостатка опыта, схема у него получилась далёкая от оптимальной, и её всё равно приходилось переделывать мне. То есть лучше бы он не начинал этим заниматься, ведь всё равно - какой смысл... Кстати для проектирования баз данных могу порекомендовать Database Design
но при этом обязательно быть поваром (обладать навыками приготовления пищи), чтобы рассуждать о способах приготовления пищи.
и действительно сравнивать способы "приготовления пищи" и делать какие-либо выводы о них может лишь повар, практиковавший эти способы. иначе все эти "выводы и сравнения" будут лишь пустозвонством.
Все работают и развиваются, просто по разному. Поэтому я и привожу наглядный пример с тем, что видно мгновенно - как выглядит рабочее место. Вы конечно можете спорить, считая, что можно работать за одним монитором всю жизнь, или за ноутбуком. С яркой лампой накаливания над головой. Да, можно. Если хотите достичь среднестатистических результатов, а не впечатляющих для самого себя. Личный выбор каждого. И про порядок в коде - я уже в статье всё написал. Если после прочтения не стало понятно, и захотелось спорить, доказывать свою точку зрения сравнивая подход с которым есть опыт с подходом в котором нет опыта - тут я ничем не могу помочь. Спорьте. Действуйте только как раньше. Вы абсолютно правы во всём. Оставайтесь правыми дальше.
я-то могу сравнить оба подхода, т.к. писал и без пустых строк, и с пустыми строками. и я выбираю второй вариант, для меня после моего практического опыта, его преимущества очевидны. как и для коллег, которые прошли через сопротивление и адаптацию.
а кто не может себе позволить попробовать писать с пустыми строками - не могут и сравнивать, из за банального сопротивления непривычному
если ты считаешь, что много мониторов может быть только у охранника, можешь глянуть следующий видос, в котором кстати в том числе раскрывается тема мониторов
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Объясню для чего это нужно. Часто приходится работать над несколькими файлами одновременно, т.к. их логика связана друг с другом. Если у вас на дисплее открыт только один файл с кодом - значит лишь то, что вы не открыли для себя возможность открывать одновременно 2, 3 и более файлов с кодом одновременно, разделяя рабочее пространство редактора кода, экономя время и свой фокус внимания, вместо того, чтобы переключаться между вкладками или окнами.
Когда одновременно открыто несколько файлов, чем более сжатый код, тем больше его помещается в не таком уж и широком окне области одного файла. А код желательно видеть полностью (по ширине), чтобы опять же не тратить время на листание влево-вправо.
Насколько мы можем сжать код? Один пробел - это один символ. Пробелы нужны, на одном пробеле не построить табуляцию, т.к. будет путаница. Получается минимальное расстояние - два пробела. Его мы и используем. Можно хоть 10 поставить, но всегда нужно понимать - ради чего.
Сейчас автомобили с ИИ начинкой ездят на автопилоте по реальным автомобильным дорогам, там масштаб ответственности повыше будет, чем "не попасть по пальцу забивая гвоздь"
Если использовать LLM чтобы он делал работу ВМЕСТО вас, то да, результат будет не обнадёживающий. Здесь же речь идёт о том, чтобы использовать его В ПОМОЩЬ себе, проверяя и дорабатывая его результаты. Приведены примеры как это можно сделать. Некомпетентные архитекторы БД были и до LLM, и всегда будут. А компетентным ИИ может помочь в работе, например массово внося изменения в таблицы. Неужто этот факт настолько плох, что нужно яростно минусить и статью с примерами, и все мои комменты?)))
Я сам не перестаю удивляться, я был в восторге ещё когда просто в режиме чата можно было общаться как с человеком, а сейчас ИИ уже и в файлах с кодом ориентируется, может создавать новые, вносить изменения сразу в несколько файлов, базы данных проектирует, и прогресс в ИИ-инструментах очень быстро идёт! Только и успевай узнавать, что ещё нового вышло, и как этим улучшить свои процессы!
Абсолютно верно, и ИМХО больше всего ценятся и будут цениться как раз специалисты, обладающие глубокой технической экспертизой, и навыками эффективного использования современных вспомогательных инструментов вроде искусственного интеллекта. Такие люди всегда будут очень востребованны, и как выразился pg_expecto, будут диктовать ценник за услуги
Благодарю за комментарий! Почувствовал в нём нотку сарказма, здесь стоит упомянуть, что всё приносит пользу при правильном использовании, и вред при неправильном. И молотком можно ударить по пальцем, но это не значит, что молоток плохой – то же самое и с использованием нейросетей. Если их использовать бездумно, без понимания технического аспекта, не проверяя результат, и не пытаясь понять как он устроен – на выходе будет УГ. А если же точечно просить ИИ выполнить что-то, декомпозируя задачи, и детально описывая желаемый результат и его особенности, то достаточно быстро можно получить очень достойный результат. Что касается ORM – за счёт своей универсальности и удобства чтения, они действительно порой генерируют неэффективный громоздкий код, который долго выполняется. И тут между прочим, кроме шуток, может хорошо помочь ИИ, который напишет под задачу чистый SQL запрос.
Где вот только взять этого редкого зверя "профессионального ИТ-менеджера"? Я вот ищу-ищу, кого-то нахожу, только вот меня никак не может пока никто заменить. Людям проще слиться с проекта, или зафакапиться, чем включиться и грамотно довести дело до конца...
Жесть, сколько танцев с бубном! Я думал это будет не сложнее регистрации в Google Search Console... Хотел вывести свой инструмент по проектированию баз данных database-design.ru на глобальный рынок, уже перевёл на английский и китайский, а тут ещё недостаточно перевести оказалось... Ну ладно, двигаемся дальше..
Полностью согласен с автором. Я сам ведущий разработчик, и получал ТЗ от системного аналитика, где тот пытался спроектировать схему базы данных. В силу недостатка опыта, схема у него получилась далёкая от оптимальной, и её всё равно приходилось переделывать мне. То есть лучше бы он не начинал этим заниматься, ведь всё равно - какой смысл... Кстати для проектирования баз данных могу порекомендовать Database Design
ХабрФриланс был единственной адеватной биржей РФ, и кормил меня и мою семью более 10 лет. Светлая память!
Абсолютно полностью согласен с автором статьи по поводу нынешней системы образования и предложений по её улучшению. Золотые слова!
бом-бом 😃
но при этом обязательно быть поваром (обладать навыками приготовления пищи), чтобы рассуждать о способах приготовления пищи.
и действительно сравнивать способы "приготовления пищи" и делать какие-либо выводы о них может лишь повар, практиковавший эти способы. иначе все эти "выводы и сравнения" будут лишь пустозвонством.
видит шире своего мнения лишь тот, кто пробует смотреть с разных точек зрения, а не с единственной 😃
я писал код и другими способами, а вы не писали код предложенным мной способом
и кто из нас видит шире своего мнения, сравнивая эти два подхода? (вопрос риторический 🤓)
Все работают и развиваются, просто по разному. Поэтому я и привожу наглядный пример с тем, что видно мгновенно - как выглядит рабочее место. Вы конечно можете спорить, считая, что можно работать за одним монитором всю жизнь, или за ноутбуком. С яркой лампой накаливания над головой. Да, можно. Если хотите достичь среднестатистических результатов, а не впечатляющих для самого себя. Личный выбор каждого. И про порядок в коде - я уже в статье всё написал. Если после прочтения не стало понятно, и захотелось спорить, доказывать свою точку зрения сравнивая подход с которым есть опыт с подходом в котором нет опыта - тут я ничем не могу помочь. Спорьте. Действуйте только как раньше. Вы абсолютно правы во всём. Оставайтесь правыми дальше.
но вряд-ли представляете как достичь результатов, которые я достиг даже не сейчас, а ещё года 4 назад 😀
я тут скорее про то, как выглядит ваше рабочее место, после 20 лет опыта в разработке
Вот вы петросяните, а я между прочим - нет
я-то могу сравнить оба подхода, т.к. писал и без пустых строк, и с пустыми строками. и я выбираю второй вариант, для меня после моего практического опыта, его преимущества очевидны. как и для коллег, которые прошли через сопротивление и адаптацию.
а кто не может себе позволить попробовать писать с пустыми строками - не могут и сравнивать, из за банального сопротивления непривычному
ну а ты как думаешь?))))
если ты считаешь, что много мониторов может быть только у охранника, можешь глянуть следующий видос, в котором кстати в том числе раскрывается тема мониторов
Не нужно миллион. У вас в коде не бывает более 3х уровней вложенности? Откуда такое сопротивление на менее широкий TAB? В статье есть пример как выглядит файл кода с ТАВ в 4 пробела и в 2, ровно один и тот же файл.
Объясню для чего это нужно. Часто приходится работать над несколькими файлами одновременно, т.к. их логика связана друг с другом. Если у вас на дисплее открыт только один файл с кодом - значит лишь то, что вы не открыли для себя возможность открывать одновременно 2, 3 и более файлов с кодом одновременно, разделяя рабочее пространство редактора кода, экономя время и свой фокус внимания, вместо того, чтобы переключаться между вкладками или окнами.
Когда одновременно открыто несколько файлов, чем более сжатый код, тем больше его помещается в не таком уж и широком окне области одного файла. А код желательно видеть полностью (по ширине), чтобы опять же не тратить время на листание влево-вправо.
Насколько мы можем сжать код? Один пробел - это один символ. Пробелы нужны, на одном пробеле не построить табуляцию, т.к. будет путаница. Получается минимальное расстояние - два пробела. Его мы и используем. Можно хоть 10 поставить, но всегда нужно понимать - ради чего.