Вы подходите к ответу к моему комментарию и комментариям выше с убеждением в том, что разработчики не хотят принимать реальность наличия ai инструментов, потому что закостенели или по какой-то другой причине.
Мы используем множество инструментов в своей работе, в том числе различные llm`ки. Их никто не отрицает, наоборот, здорово, когда инструмент облегает тебе работу. Зная их текущие возможности и границы применения, как в личных проектах, так и в упомянутом вами enterprise, мы и пишем то, что пишем.
Попробуйте читать комментарии с пониманием того, что не вы один (и далеко не самый первый) пощупали и поделали разное с помощью AI. И при этом, те, кто отвечают вам, действующие разработчики в крупных компаниях (знают кухню изнутри).
Моего комментария не было бы, если бы посыл статьи был такой: "С помощью AI теперь можно проверить свою гипотезу с меньшими затратами". С этим трудно было бы спорить, ибо вы, как фаундер, реализовали свои хотелки (в хорошем смысле), не нанимая команду специалистов. Хотя вы ещё даже не проверили свою гипотезу, потому что продаж нет.
Но когда вы беретесь что-то утверждать о том, о чем имеете весьма поверхностное понимание (без обид), это для человека "в теме" выглядит забавно. Принимайте критику достойно, с пониманием того, что вы на техническом ресурсе, а не на "vc.ru или TechCrunch", и тут немало людей, имеющих компетенцию в технической части выше вашей, в том числе и в области применения AI =)
Уважаемый автор, это не техническая статья, а ваши размышления о том, насколько дешевле сделать MVP в одного с помощью llm`ок, а не нанимая полноценную команду (да и то, это не MVP, а ваш pet-проект, строго говоря).
Описываемые вами "боли" - это боли фаундеров, но не инженеров. И так как статья с технической точки зрения постная, а ваши утверждения столь категоричны, то интересна экономика вашего проекта, чтобы хоть как-то сматчить эти утверждения с реальностью. И потому вопрос: "Где деньги, Зин?" - уместный, а вот ответа на него нет, что как бы намекает.
Стадия "горящие глаза" и "я изменил парадгму" - это нормально. Когда рациональность сменит эмоции, взгляды отшлифуются.
Они также меняются, как того требует структура проекта. Если у вас только что созданный проект, то да, написание юнит-тестов нужно отложить до момента, когда проект более менее устаканится. В ином случае вы будете тратить тонну времени на изменение тестов не по причине добавления/изменения функциональности, а из-за рефакторинга. А в устоявшемся проекте изменение тестов происходит в рамках выполнения задачи за вменяемое время.
Зачем нужен тест, которому я заранее говорю, что будет на выходе, а потом проверяю, что на выходе именно это?
Вы не говорите в тестах проверяемому методу, что надо вернуть. Вы говорите классам/объектам, которые вызываются в тестах, что надо вернуть. Тем самым вы проверяете только работу проверяемого метода. А результат работы метода, если он есть, сравнивается с ожидаемым значением.
Большая часть юнит-тестов проверяет только количество вызовов при разных вызовов, а не данные.
Это возможно, если у вас большая часть void методов. На практике это не частое явление. А так для проверки, на вскидку, есть:
Возвращаемое значение
Выбрасываемые ошибки
Кол-во вызовов методов
Проверка того, что какой-то метод не вызывался
Интеграционные делают всю основную работу тестирования и служат гораздо более яркими лампочками - и в гораздо меньших количествах, не перегружая мозг, - чем юнит.
Зависит от того, кто и для каких целей пишет. Основной инструмент тестирования разработчика ⟶ юнит-тесты. Мы проверяем только свой код, мокая всё остальное. Запускаются и проходят эти тесты также сильнее быстрее (не забываем, что для интеграционных нужно поднимать всю инфру) А вот тестировщика основным инструментом являются интеграционные тесты, так как задача у тестировщика другая.
Большое количество юнит-тестов сильно замедляет деплой, сиди и жди, пока они все пробегут.
Если юнит-тесты проходят дольше интеграционных (это надо сильно сильно постараться), то такие тесты написаны неправильно. С другой стороны, куда-то торопитесь? 5 минут времени критично?
Ваш СТО всё прекрасно знает и понимает, и работает на свои KPI. Он получит премии за это и уйдёт на другой проект. Автор, ты не привык к закулисным играм, которыми заняты люди на подобных должностям, поэтому тяжело противодействовать: нет понимания того, как это можно сделать, ведь ты не этим занимаешься в работе.
Либо борись в этим, используя грязные способы, либо делай вид, что ты согласен со своим СТО, давай ему минимум, необходимы для того, чтобы оставаться на работе, а сам делай своё дело.
У вас разные приоритеты. Ты за красоту, чистоту и правильность, а он за KPI.
Может быть ещё надо степень получить, чтобы Обсидианом начать пользоваться? Господа, есть люди, которые используют самый базовый функционал, и этого хватает за глаза. (15 минут чтения). Но всегда найдётся увлечённый человек, который расскажет, что перед использованием надо прочитать, понять, запомнить талмуд рекомендаций. Спасибо, не надо.
Так вот, контекстами общаются в основном восточно-европейские разработчики (РФ, РБ, Польша, Сербия, Словакия, Венгрия). Американцы и европейцы начиная с Австро-Германии редко проводят общение с контекстом и предпочитают подробно расписывать всё, как для человека, который вчера пришел на проект. И это долго, реально долго.
А потом ты попадаешь в ситуацию, когда действительно только пришёл на проект, а задачи формулируются типа: "Не работает вот эта штука в таком-то сервисе". И сидишь тратишь время на то, чтобы понять, что он тебя нужно, что хотят в итоге, где это вообще находится, лишнее общение с тем, кто завёл задачу.
Конечно, в этом нужен баланс, но вот читать описание задач, общение в PR, документацию, где люди общаются контекстами - это та ещё радость. Им, конечно, удобно, а тем, кто придёт после них?
Редко мы думаем над тем, насколько просто будет разобраться тем, кто придёт после. Общение в личках, описание таски в виде контекста и т.д. А ты потом пытаешься что-то отыскать и понять, но сделать это можно только найдя кого-то через пятые руки, попутно подождав полдня ответа от каждого из цепочки.
Если хотите заслужить уважение — работайте больше положенного.
Больше всех в колхозе работала лошадь, но председателем она так и не стала.
Так повелось, что когда у меня заканчивались задачи, я всегда придумывал, чем заняться в проекте. Это происходило не потому, что я стахановец по натуре, а из-за страха остаться без работы.
Так причина ваших овертаймов в страхе уволнения, а не потому, что если работать нормально, то вас уволят.
Какой адекватный менеджер даст джуну на испытательном сроке сложную задачу с жёстким дедлайном? Или автор приукрашивает, или менеджер плохо понимает, что делает, но это уже не вина разработчика.
Моё поведение на испытательном сроке было примерно таким же, как у автора, потому ряд советов:
НЕ работайте больше положенного без оплаты. Если вы не ставите менеджера в известность, что перерабатываете, то он считает, что вы так всегда работаете => выполняете большой объём задач за рабочий день. Когда вы в последующем решите работать в рамках рабочего дня, то ваш менеджер будет неприятно удивлён вашей продуктивности. Не говоря уже про выгорание, которые не заставит себя ждать
Ведите себя естественно. Вам в этой компании ещё работать. Если вы будете на испытательном сроке изображать из себя очень общительного и активного человека, то опять же, все будут в недоумении, когда это прекратится.
Отстаивайте свои интересы и границы даже если вы, о боже, на испытательном сроке. Ваш менеджер и вы привыкнете к тому, что с вашими мнением можно не считаться, а это чревато.
17 плюсов без комментариев к статье - сильно, парни
Вы подходите к ответу к моему комментарию и комментариям выше с убеждением в том, что разработчики не хотят принимать реальность наличия ai инструментов, потому что закостенели или по какой-то другой причине.
Мы используем множество инструментов в своей работе, в том числе различные llm`ки. Их никто не отрицает, наоборот, здорово, когда инструмент облегает тебе работу.
Зная их текущие возможности и границы применения, как в личных проектах, так и в упомянутом вами enterprise, мы и пишем то, что пишем.
Попробуйте читать комментарии с пониманием того, что не вы один (и далеко не самый первый) пощупали и поделали разное с помощью AI. И при этом, те, кто отвечают вам, действующие разработчики в крупных компаниях (знают кухню изнутри).
Моего комментария не было бы, если бы посыл статьи был такой:
"С помощью AI теперь можно проверить свою гипотезу с меньшими затратами".
С этим трудно было бы спорить, ибо вы, как фаундер, реализовали свои хотелки (в хорошем смысле), не нанимая команду специалистов. Хотя вы ещё даже не проверили свою гипотезу, потому что продаж нет.
Но когда вы беретесь что-то утверждать о том, о чем имеете весьма поверхностное понимание (без обид), это для человека "в теме" выглядит забавно.
Принимайте критику достойно, с пониманием того, что вы на техническом ресурсе, а не на "vc.ru или TechCrunch", и тут немало людей, имеющих компетенцию в технической части выше вашей, в том числе и в области применения AI =)
Уважаемый автор, это не техническая статья, а ваши размышления о том, насколько дешевле сделать MVP в одного с помощью llm`ок, а не нанимая полноценную команду (да и то, это не MVP, а ваш pet-проект, строго говоря).
Описываемые вами "боли" - это боли фаундеров, но не инженеров.
И так как статья с технической точки зрения постная, а ваши утверждения столь категоричны, то интересна экономика вашего проекта, чтобы хоть как-то сматчить эти утверждения с реальностью.
И потому вопрос: "Где деньги, Зин?" - уместный, а вот ответа на него нет, что как бы намекает.
Стадия "горящие глаза" и "я изменил парадгму" - это нормально. Когда рациональность сменит эмоции, взгляды отшлифуются.
Успехов!)
Да уж лучше так, чем когда в команде из 15 человек список задач и статусы в головах исполнителей
Они также меняются, как того требует структура проекта.
Если у вас только что созданный проект, то да, написание юнит-тестов нужно отложить до момента, когда проект более менее устаканится. В ином случае вы будете тратить тонну времени на изменение тестов не по причине добавления/изменения функциональности, а из-за рефакторинга.
А в устоявшемся проекте изменение тестов происходит в рамках выполнения задачи за вменяемое время.
Вы не говорите в тестах проверяемому методу, что надо вернуть.
Вы говорите классам/объектам, которые вызываются в тестах, что надо вернуть. Тем самым вы проверяете только работу проверяемого метода.
А результат работы метода, если он есть, сравнивается с ожидаемым значением.
Это возможно, если у вас большая часть void методов. На практике это не частое явление.
А так для проверки, на вскидку, есть:
Возвращаемое значение
Выбрасываемые ошибки
Кол-во вызовов методов
Проверка того, что какой-то метод не вызывался
Зависит от того, кто и для каких целей пишет.
Основной инструмент тестирования разработчика ⟶ юнит-тесты. Мы проверяем только свой код, мокая всё остальное. Запускаются и проходят эти тесты также сильнее быстрее (не забываем, что для интеграционных нужно поднимать всю инфру)
А вот тестировщика основным инструментом являются интеграционные тесты, так как задача у тестировщика другая.
Если юнит-тесты проходят дольше интеграционных (это надо сильно сильно постараться), то такие тесты написаны неправильно.
С другой стороны, куда-то торопитесь? 5 минут времени критично?
Ваш СТО всё прекрасно знает и понимает, и работает на свои KPI. Он получит премии за это и уйдёт на другой проект.
Автор, ты не привык к закулисным играм, которыми заняты люди на подобных должностям, поэтому тяжело противодействовать: нет понимания того, как это можно сделать, ведь ты не этим занимаешься в работе.
Либо борись в этим, используя грязные способы, либо делай вид, что ты согласен со своим СТО, давай ему минимум, необходимы для того, чтобы оставаться на работе, а сам делай своё дело.
У вас разные приоритеты. Ты за красоту, чистоту и правильность, а он за KPI.
Может быть ещё надо степень получить, чтобы Обсидианом начать пользоваться?
Господа, есть люди, которые используют самый базовый функционал, и этого хватает за глаза. (15 минут чтения).
Но всегда найдётся увлечённый человек, который расскажет, что перед использованием надо прочитать, понять, запомнить талмуд рекомендаций. Спасибо, не надо.
А потом ты попадаешь в ситуацию, когда действительно только пришёл на проект, а задачи формулируются типа: "Не работает вот эта штука в таком-то сервисе". И сидишь тратишь время на то, чтобы понять, что он тебя нужно, что хотят в итоге, где это вообще находится, лишнее общение с тем, кто завёл задачу.
Конечно, в этом нужен баланс, но вот читать описание задач, общение в PR, документацию, где люди общаются контекстами - это та ещё радость. Им, конечно, удобно, а тем, кто придёт после них?
Редко мы думаем над тем, насколько просто будет разобраться тем, кто придёт после. Общение в личках, описание таски в виде контекста и т.д.
А ты потом пытаешься что-то отыскать и понять, но сделать это можно только найдя кого-то через пятые руки, попутно подождав полдня ответа от каждого из цепочки.
Больше всех в колхозе работала лошадь, но председателем она так и не стала.
Так причина ваших овертаймов в страхе уволнения, а не потому, что если работать нормально, то вас уволят.
Какой адекватный менеджер даст джуну на испытательном сроке сложную задачу с жёстким дедлайном?
Или автор приукрашивает, или менеджер плохо понимает, что делает, но это уже не вина разработчика.
Моё поведение на испытательном сроке было примерно таким же, как у автора, потому ряд советов:
НЕ работайте больше положенного без оплаты.
Если вы не ставите менеджера в известность, что перерабатываете, то он считает, что вы так всегда работаете => выполняете большой объём задач за рабочий день.
Когда вы в последующем решите работать в рамках рабочего дня, то ваш менеджер будет неприятно удивлён вашей продуктивности.
Не говоря уже про выгорание, которые не заставит себя ждать
Ведите себя естественно. Вам в этой компании ещё работать.
Если вы будете на испытательном сроке изображать из себя очень общительного и активного человека, то опять же, все будут в недоумении, когда это прекратится.
Отстаивайте свои интересы и границы даже если вы, о боже, на испытательном сроке.
Ваш менеджер и вы привыкнете к тому, что с вашими мнением можно не считаться, а это чревато.