Что-то похожее на SDD. Часто бывает что одно чиниться - другое ломается? Приходилось генерировать, таким образом, что-то больше чем CRUD, какую-то сложную бизнес логику?
Маленькие проекты можно легко генерировать. Но что-то объемное, сложное то что занимает только в генерации несколько месяцев - "по файлом" не сгенерировать. Уже нужны инженерные навыки и понимание области. Иначе получиться либо совсем плохо, либо вообще не получиться.
Это, скорее, вопрос подхода к разработке, чем привычки. У нас уже есть методология TDD, - хорошая, но плохо применимая. Тут что-то очень похожее. TDD плох на практике, - но красив в теории. С ИИ он находит новые смысле. Я в следующей статье хочу написать как раз о подходах в разработке через ai-first и разобрать плюсы и минусы каждого.
Возможно. Но в статье речь скорее о специализированных знаниях, зоне ответственности и способности создавать и развивать программный продукт целиком.
Я рассматриваю программиста как более широкое понятие: человек, который пишет код. Разработчик - это специалист, который помимо написания кода понимает задачу, архитектуру, ограничения, принимает технические решения и отвечает за результат.
Я встречал часто разработчиков, которым нужны инструкции что и как делать. И это тонкий момент, потому что спрашивать о том как сделать - это хорошо, это процесс обучения. Но ждать указаний - плохо. Есть и другие - которые супер инициативно делают какую-то дичь. Если такого человека поставить руководителем - его будут называть самодуром. Это тоже плохо. Поэтому разработчик/инженер он понимает что делает, делает это хорошо и готов осознано нести ответственность за результат.
Условно: программист относится к разработчику примерно так же, как оператор набора текста - к автору того-же текста. Оба работают с текстом, но уровни работы - разные.
Тут не все так однозначно. Метрики действительно важны. Только их собирать можно по разному. И собирать можно не те метрики. А от этого зависит и восприятие того на что смотреть.
Я в командах не смотрю на метрики до тех пор, пока все и каждый не начали работать по одним и тем же правилам. Иначе по метрикам всплывают бестолковые суперспециалисты. Которые по метрикам делают быстро, а по факту - плохо
Результат в моменте отличается от долгосрочной стратегии.
Опираться стоит на реальность, а не стандарты из реестра. Для меня это как начальник и руководитель. Первый самодур с должностью, второй уважаемый за проф.пригодность.
Все верно.
Просто привычка от ZF использовать встроенные функции, даже когда есть альтернативы. Такая же как и использовать Yii::app()->request->getPost() вместо $_POST. Других причин нет.
Зачем эта функция нужна в Yii и как сюда попала лучше спросить у автора фреймворка. Может он посчитал что она быстрее будет работать?! А может просто решил "пусть будет" )). В ZF принято всегда пользоваться функциями фреймворка а не нативного языка. В Yii таких рекомендаций нет, и каждый ложит что угодно куда угодно и использует что угодно где угодно.
Я бы добавил что те которые испытывают имеют не один сервер за пазухой. И нагрузка между этими серверами балансируется. А значит можно вернутся к разговору о том что сессии это вообще не проблема. Если, конечно, в них не хранить том «Война и Мир» ))
При грамотном проектировании ничего на них не сэкономишь. А при не грамотном лучше оптимизировать запросы к БД. Потому как чаще всего там кроются все проблемы.
Как я понимаю маленькие микросервисы или отдельное и не связанное между собой маленькое ПО. Такое, как правило, дейсвительно хорошо генерируеться
Что-то похожее на SDD. Часто бывает что одно чиниться - другое ломается? Приходилось генерировать, таким образом, что-то больше чем CRUD, какую-то сложную бизнес логику?
Поделитесь вашим подходом к созданию кода через ИИ.
Маленькие проекты можно легко генерировать. Но что-то объемное, сложное то что занимает только в генерации несколько месяцев - "по файлом" не сгенерировать. Уже нужны инженерные навыки и понимание области. Иначе получиться либо совсем плохо, либо вообще не получиться.
Так и есть. И это уже вопрос о том как использовать ИИ в работе.
Спасибо за мнение
Благодарю за совет
Это, скорее, вопрос подхода к разработке, чем привычки. У нас уже есть методология TDD, - хорошая, но плохо применимая. Тут что-то очень похожее. TDD плох на практике, - но красив в теории. С ИИ он находит новые смысле. Я в следующей статье хочу написать как раз о подходах в разработке через ai-first и разобрать плюсы и минусы каждого.
Возможно. Но в статье речь скорее о специализированных знаниях, зоне ответственности и способности создавать и развивать программный продукт целиком.
Я рассматриваю программиста как более широкое понятие: человек, который пишет код. Разработчик - это специалист, который помимо написания кода понимает задачу, архитектуру, ограничения, принимает технические решения и отвечает за результат.
Я встречал часто разработчиков, которым нужны инструкции что и как делать. И это тонкий момент, потому что спрашивать о том как сделать - это хорошо, это процесс обучения. Но ждать указаний - плохо. Есть и другие - которые супер инициативно делают какую-то дичь. Если такого человека поставить руководителем - его будут называть самодуром. Это тоже плохо. Поэтому разработчик/инженер он понимает что делает, делает это хорошо и готов осознано нести ответственность за результат.
Условно: программист относится к разработчику примерно так же, как оператор набора текста - к автору того-же текста. Оба работают с текстом, но уровни работы - разные.
Тут не все так однозначно. Метрики действительно важны. Только их собирать можно по разному. И собирать можно не те метрики. А от этого зависит и восприятие того на что смотреть.
Я в командах не смотрю на метрики до тех пор, пока все и каждый не начали работать по одним и тем же правилам. Иначе по метрикам всплывают бестолковые суперспециалисты. Которые по метрикам делают быстро, а по факту - плохо
Соболезную, а вы чем занимались?
Мир действительно сильно быстро меняется, что очень сложно за ним успеть. Но это только начало трансформации
Результат в моменте отличается от долгосрочной стратегии.
Опираться стоит на реальность, а не стандарты из реестра. Для меня это как начальник и руководитель. Первый самодур с должностью, второй уважаемый за проф.пригодность.
Хоть в чемто вы согласны
Просто привычка от ZF использовать встроенные функции, даже когда есть альтернативы. Такая же как и использовать Yii::app()->request->getPost() вместо $_POST. Других причин нет.
Зачем эта функция нужна в Yii и как сюда попала лучше спросить у автора фреймворка. Может он посчитал что она быстрее будет работать?! А может просто решил "пусть будет" )). В ZF принято всегда пользоваться функциями фреймворка а не нативного языка. В Yii таких рекомендаций нет, и каждый ложит что угодно куда угодно и использует что угодно где угодно.