Я бы сказал так - сегодняшний разработчик не использующий ии, это вчерашний разработчик, не использовавший гугл. А код копипастили и раньше, до появления гпт.
Плюс за интуитивно понятный интерфейс. Вот уж действительно, когда кто-то про свой продукт это заявляет, то скорее всего, там максимально не интуитивны интерфейс 😂
Сам постоянно использую гпт и не перестаю удивляться, как просто можно получить любую нужную информацию из окна с одним инпутом)
Проблема точной оценки заключается в отсутствии понимания двух вещей: как выглядит бизнес-процесс и как он сейчас реализован в конкретно взятой системе со всеми её нюансами, которую нужно поправить. Это и есть контекст задачи. Если вы полностью знаете контекст, то легко дадите хорошую оценку по срокам, прям как в примере с самолётами.
В идеально-простом случае, если программу писал один человек с самого начала, он легко даст оценку, так как знает весь контекст. На практике - писал один, потом после него ещё 10 человек и все они давно уволились унеся с собою то самое, ценное понимание контекста. Документацию, естественно, никто не писал. В итоге имеем черный ящик. И вот как оценивать такую задачу, если вы новонанятый разработчик в этой конторе?
С этим можно бороться по разному:
Описывать бизнес-процессы, чтоб в первую очередь, сам бизнес знал, какие у него есть процессы, как они должны быть устроены и как их нужно модифицировать.
При разработке в приоритете всегда должна быть простота. Каждый лишний слой абстракции - это сильное усложнение (сложность растёт: n^n).
Писать сопроводительную документацию и комментарий в коде на будущее, чтоб при увольнении разрабов, ценный контекст не утекал безвозвратно вместе с ними. Написать документацию к коду после решения задачи стоит 1$, а чтоб потом восстановить весь контекст новому разработчику без помощи и подсказок будет стоить: n^n$.
Ну и на самом деле есть много разных способов и технических решений, как можно бороться с ростом сложности и "утиканием" знания контекста из компании. В терминальном случае, если вы не справитесь и раздуете сложность до неподъёмной, придется "переписать всё с нуля", заплатив кучу денег и скорее всего обанкротившись.
Не знаю как сейчас, а раньше комиссия была не 30%, а чуть ли не все 50% по итогу. Рекламная монетизация - полный отстой, ты обязан использовать только их сетку и не можешь настроить водопад. Никакой конкуренции среди сеток у них.
А вы уверены, что использование API это именно "модификация" ПО, а не запланированное разработчиком использование - аналог GUI интерфейса. По сути, API так и расшифровывается - Application Program INTERFACE.
Вы когда нажимаете на кнопочку стрелять, не модифицирует же программу. ?
Поддерживаю. Работал на одном таком проекте, где на каждый класс был свой интерфейс. Всё это выглядит как сова натянутая на глобус. Делайте проще.
Я бы сказал так - сегодняшний разработчик не использующий ии, это вчерашний разработчик, не использовавший гугл. А код копипастили и раньше, до появления гпт.
Плюс за интуитивно понятный интерфейс. Вот уж действительно, когда кто-то про свой продукт это заявляет, то скорее всего, там максимально не интуитивны интерфейс 😂
Сам постоянно использую гпт и не перестаю удивляться, как просто можно получить любую нужную информацию из окна с одним инпутом)
Проблема точной оценки заключается в отсутствии понимания двух вещей: как выглядит бизнес-процесс и как он сейчас реализован в конкретно взятой системе со всеми её нюансами, которую нужно поправить. Это и есть контекст задачи. Если вы полностью знаете контекст, то легко дадите хорошую оценку по срокам, прям как в примере с самолётами.
В идеально-простом случае, если программу писал один человек с самого начала, он легко даст оценку, так как знает весь контекст. На практике - писал один, потом после него ещё 10 человек и все они давно уволились унеся с собою то самое, ценное понимание контекста. Документацию, естественно, никто не писал. В итоге имеем черный ящик. И вот как оценивать такую задачу, если вы новонанятый разработчик в этой конторе?
С этим можно бороться по разному:
Описывать бизнес-процессы, чтоб в первую очередь, сам бизнес знал, какие у него есть процессы, как они должны быть устроены и как их нужно модифицировать.
При разработке в приоритете всегда должна быть простота. Каждый лишний слой абстракции - это сильное усложнение (сложность растёт: n^n).
Писать сопроводительную документацию и комментарий в коде на будущее, чтоб при увольнении разрабов, ценный контекст не утекал безвозвратно вместе с ними. Написать документацию к коду после решения задачи стоит 1$, а чтоб потом восстановить весь контекст новому разработчику без помощи и подсказок будет стоить: n^n$.
Ну и на самом деле есть много разных способов и технических решений, как можно бороться с ростом сложности и "утиканием" знания контекста из компании. В терминальном случае, если вы не справитесь и раздуете сложность до неподъёмной, придется "переписать всё с нуля", заплатив кучу денег и скорее всего обанкротившись.
Лишний раз заставляет задуматься, насколько сильно вы зависите от одного сервиса.
Я бы не пошел.
Не знаю как сейчас, а раньше комиссия была не 30%, а чуть ли не все 50% по итогу. Рекламная монетизация - полный отстой, ты обязан использовать только их сетку и не можешь настроить водопад. Никакой конкуренции среди сеток у них.
Где тут самый главный вопрос - о вилке и зп?
А вы уверены, что использование API это именно "модификация" ПО, а не запланированное разработчиком использование - аналог GUI интерфейса. По сути, API так и расшифровывается - Application Program INTERFACE.
Вы когда нажимаете на кнопочку стрелять, не модифицирует же программу. ?
А чего искать, тысячи их! Каждый уважающий себя пограммист писал свой движок, или до сих пор пишет)
Ох уж эта тема с движкописательством, спасибо за теплые воспоминания! ?