Kanban честно визуализирует поток задач, но при малейшем отсутствии дисциплины превращается в кладбище бесконечно висящих стикеров в колонке «в процессе» и легитимизирует многозадачность на грани нервного срыва.
При отсутствии дисциплины и не следовании правилам любая методология начинает хромать на обе ноги.
Kanban как раз-таки наоборот прямо запрещает более одной задачи в статусе а-ля in progress у исполнителя.
Неподготовленному человеку (кто раньше не занимался или имеет противопоказания: большой лишний вес, больные суставы, травмы связок и т.п.) начинать надо не с бега, а с ходьбы по 1-2 часа в день. ИМХО. А так - молодцы.
Даёт удобство развёртывания в обмен на жертву некоторой степени производительности, безопасноcти и необходимости поддерживать доп. инструмент. В какую сторону и насколько склоняться - вопрос конкретного проекта. It depends.
Хз никогда не работал с подманом.
Где прописали, там и будут) или это вопрос на знание команды docker logs и подобных?
читать программу сложнее, чем писать.Потому что для чтения - требуется понимание. А для написания это необязательно - можно писать небрежно, можно копипастить из stackoverflow и всяких "ИИ" и т.п.
В разработке с "ИИ", ревью от опытного специалиста - это и есть бутылочное горлышко. Реальная революция начнётся тогда, когда "ИИ" начнёт решать задачи без или с минимальным ревью. Пока это не так, так что хайпа больше, чем реального прироста производительности.
LLM это не разработка, а имитация разработки. Иногда прокатывает, а иногда нет. Но самое интересное начинается, когда не прокатило и надо в сжатые сроки вникнуть в наспех нагенеренную белиберду...
так баг может вылазить на границах, когда нагрузочные равномерно давят по максимуму.
Это означает: забили на пользовательские сценарии и дата флоу. Или по-другому: нет времени думать, запиливай в продакшн быстро! У нас квартальный отчёт в понедельник! =) Не, понимаю, такое бывает. Проблемы начинаются, когда такое систематически и техдолг растёт аки снежный ком.
пока крупные компании пытаются заменить разработчиков искусственным интеллектом, сами разработчики избавляются от потребности в крупных компаниях с помощью ИИ))
В моей команде нет чёткого разделения на бизнес‑аналитика, системного аналитика, руководителя проекта и разработчика.
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
AI ушёл дальше: “сделай мне форму регистрации с валидацией телефона по российским правилам, с подтверждением через SMS, с проверкой что номер уникальный в БД, дизайн как у соседних форм в проекте”.
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
повторяющуюся, шаблонную часть работы делает машина.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
При отсутствии дисциплины и не следовании правилам любая методология начинает хромать на обе ноги.
Kanban как раз-таки наоборот прямо запрещает более одной задачи в статусе а-ля in progress у исполнителя.
Можно и к инту кастануть:
<?= (int) $n ?>
Неподготовленному человеку (кто раньше не занимался или имеет противопоказания: большой лишний вес, больные суставы, травмы связок и т.п.) начинать надо не с бега, а с ходьбы по 1-2 часа в день. ИМХО.
А так - молодцы.
Заблуждения обывателей о разработке через ИИ. Мнение разработчика
Ай хорош!
С этими вредителями надо что-то делать...
Даёт удобство развёртывания в обмен на жертву некоторой степени производительности, безопасноcти и необходимости поддерживать доп. инструмент. В какую сторону и насколько склоняться - вопрос конкретного проекта. It depends.
Хз никогда не работал с подманом.
Где прописали, там и будут) или это вопрос на знание команды docker logs и подобных?
https://habr.com/ru/articles/937844/comments/#comment_28718842
https://habr.com/ru/articles/1015730/comments/#comment_29731246
https://habr.com/ru/articles/1021494/comments/#comment_29806754
Это означает: забили на пользовательские сценарии и дата флоу. Или по-другому: нет времени думать, запиливай в продакшн быстро! У нас квартальный отчёт в понедельник! =) Не, понимаю, такое бывает. Проблемы начинаются, когда такое систематически и техдолг растёт аки снежный ком.
Согласен, на практике так и есть.
А как же нагрузочные тесты?
В точности мои мысли уже года два как.
Потому что "не можете", понятно? Владельцы заводов-пароходов хотят себе денег, а не проблем. (sarcasm)
Раз статистика в 1000 откликов не устраивает, надо "точечно" проверить, чтоб результаты и вызываемые ими эмоции были как задумано.
Мощно...
Осталось еще ролей понакидывать: фронтендер, бекендер, девопс, (веб-)дизайнер, безопасник, тестировщик, DBA, дата инженер, ML-щик и пр.
А в идеале ("в корпоративной парадигме") это вообще должен быть один человек, обвешанный "ИИ". Остальных уволить, на эскономленные деньги построить себе дачу, например.
Когда начнётся пожар (человек уволится или техдолга станет слишком много) объяснить борде и стейкхолдерам "сложную рыночную ситуацию" и перейти в другую компанию. А там можно повторить сначала. P - profit.
Вот кому интересно, и так всё это знают.
А кому не интересно - непонятно, зачем им этот курс нужен...
Красавчик.
Спасибо, - значит, не зря старался!
"По российским правилам" - это по каким? Чтоб с +7 начинался? (у Казахстана тоже кстати с +7 бывает) Или эти все правила на "усмотрение ИИ" остаются, он сам додумает (и нигде больше не пропишет их)?... =))) и что будет при смене модели при дальнейшей поддержке такого кода?
"с подтверждением через SMS" - предполагается, что уже есть настроенный смс шлюз. А если его нет, "ИИ" тоже его настроит? И как положит деньги на баланс? Что будет в тестовых окружениях, там тот же шлюз, или другой?
"с проверкой что номер уникальный в БД" - эта проверка в первую очередь должна быть на уровне БД, а форма должна ловить исключения и ошибки от БД. По такой инструкции, "ИИ" может просто навернуть проверку на уровне фронтенда (со всеми вытекающими приколами, например: номер забили -> форма проверила, все ок -> заполнили остальное, пытаемся сохранить форму -> либо ошибка, либо сохраняется дублирующий номер, если в бд нет проверки на уникальность).
"дизайн как у соседних форм в проекте" - соседние формы - это какие? и что если у нескольких соседних форм разные дизайны? и т.п.
Так-то давно существуют инструменты оптимизации "повторяющейся и шаблонной" части работы. Например, в любом +- "взрослом мейнстримном" ЯП или фреймворке есть инструменты метапрогаммирования, кодогенерации, создания набросков из шаблонов для классов, миграций, апи эндпойнтов и т.п.
Другое дело, что почти всегда этот "плейсхолдер код" приходится существенно кастомизировать руками - и вот тут-то и нужен разработчик.
А тут получается, что вместо того, чтобы сразу поправить и дописать руками, надо придумывать промпт, чтобы "ИИ" это же самое написал. И платить ещё за это $200 в месяц, молясь, чтоб токены не закончились или чтоб доступ к "ИИ" не обрубили.
Не говорю, что "ИИ" бесполезен - тесты может писать, документацию, какие-то идеи, анализ выдавать. А вот так, чтоб "хочу получить это" - и сразу получаешь без свистоплясок - этого не наблюдаю...
ИМХО.
Спасибо! Ну, возможно несколько сложноват или не было попадания в целевую аудиторию.