Поэтому поведение должно быть зафиксировано тестами. Какой там будет сгенерирован в пайплайне код для реализации тестов не важно. Так что аналогию провести можно. И точно так же как рукописный, ии код поддерживать не надо, в этом и смысл. Надо поддерживать задачу которую ты ставил ии + тесты. Я ближайшее будущее вижу только так. Иначе ии это просто помощник программиста, как инструмент, но не более того.
Ну справедливости ради должен заметить что и текущая его роль сильно полезна. Я, например, недавно с его помощью решил задачу за которую без него даже не взялся бы, потому что было очевидно что это займёт неприемлемое количество времени. С ним мы справились довольно быстро.
Я не об этом. Я о том что к сгенерированнному коду почему-то предъявляются такие же требования как к рукописному, что само по себе нонсенс. Например если в сгенерированном есть дублирования кода, да и хрен с ним. Этот код вообще смотреть не надо. Надо лишь делать хорошие способы проверки работоспособности такого кода. Возможно в будущем будут более высокоуровневые языки которые будут выглядеть как правильно оформленная постановка задачи для ии, а сам код будет генериться в пайплайне. Вот я про что. Но тема новая, это всё только предстоит сделать и придумать.
Но другое дело когда ии делает маленький кусочек, а ты его потом допиливаешь. Но фактически ты полностью сам ревьюишь и дорабатывешь код. Но это другое.
Потому что способ создания кода поменялся, а парадигмы разработки, проектирования и тестирования нет. В зтом и проблема. Например, допустим ты сгенерил класс, какие-то там методы и т.п. ты не сильно вникал что там внутри получилось, тебе важно чтобы оно делало то что надо и делало это хорошо. Очевидно что такой код должен иметь минимальную связность, должен быть покрыт тестом и должен иметь описание постановки задачи для ии, чтобы можно было его перегенерить сколько угодно раз. Код становится черным ящиком , и это нормально. Код становится дешевым, проектирование остается дорогим, даже становится ещё дороже. И не нужны там никакие анализаторы правильности кода, т.к. такой код должен восприниматься как черный ящик. Если черный ящик работат неправильно, он за несколько минут перегенерируется на новый черный ящик.
Вот что я имею в виду. Способ программирования поменялся, всё остальное осталось старым, хотя тоже должно поменяться.
Очень согласен. Расскажу немного свой опыт. Я профессионально программирую на работе по 8 часов в день примерно 18 лет, сколько ещё до этого, никто не знает. За всё это время по-настоящему что называется эргономичного стула нигде не было ни разу. Последние несколько лет работаю как положено, в основном на удалёнке. Дома у меня вообще нет офисного кресла и рабочего стола, поэтому работаю полулёжа на диване с раскладной подставкой под ноут. И ничего у меня не болит, и спина не устаёт. А происходит это потому, что у меня дома вместо всяких эргономичных столов и стульев есть силовая рама, штанга, скамья и т.д. Ты берёшь, делаешь становую тягу, приседания и жим лёжа. Вот что реально помогает от спины, а не вот то всё что перечислено у автора в посте. И нечего тут выдумывать, это всё уже давно известно и проверено. Особенно умиляют советы типа монитор на уровне глаз. Вот от таких советов точно пипец твоей спине будет, сидеть в таком напряжении с вытянутой шеей.
Я не специалист по яндекс маркету, предпочитаю туда не попадать. Про плюс минус не хуже я написал условно, имею в виду смысл там такой же, реализацию сравнивать не берусь. Да, раньше можно было сверять спецификациии, как ты отлично выразился, а сейчас ощущение что ты на черкизон пришёл.
Раньше яндекс маркет был энциклопедией или, если хотите, каталогом техники и не только. Можно было вбить любое название и пожалуйста. Ты видишь все модели, что чем отличается и т.д. Если тебе нало было понять чем один комп отличается от другого или чем один фотик отличается от другого или какая моьила лучше по твоим критериям, ты шёл в яндекс и получал ответы на все хти вопросы.
Последние несколько лет яндекс стал точно таким же как вайлдбериз и озон. Ничем не лучше, ничем не хуже (плюс минус). Но, мы лишились того что было раньше. Больше такого каталога не существует в рунете. Был уникальный продукт, стал такой же как у всех. Уж могли бы придумать как делать деньги из того что было раньше, чем щас. Вот главная проблема. Шас уже даже какой-нибудь днс в этом плане лучше стал. Там и профильтровать норм можно и купить, ассортимент у них норм. И это магазин, в отличии от цыганского яндекс рынка.
Подтверждаю, всё в точности как было и у меня, включая email режим. Думаю, а может стоит сделать режим оплаты который перебрасывает на внешний ресурс и позволяет использовать всякие быстрые платежи, сберпэи и всё остальное.. пока не решил. Но конкретно текущий встроенный в телегу режим работает отлично.
Вопросы дурацкие, особенно про кота. После него можно встать и молча выйти. Но похоже что автор и сам не знает ответы на сво же вопросы, потому что пример про класс с временем текушим назад это полный бред. У тебя там ничего никуда не течет, это просто класс с двумя мат операциями над временем. Класс времени которое течет назад это надо создать инстанс, записать там текущее время и потом в методе Now вернуть стартовое время - (текущее- стартовое)
Почему автор как достижение говорит про вот такие вещи, что стало меньше ошибок по невнимательности:
Типичный пример: пишем в контроллере POST вместо GET.
Вот зачем на это вообще писать тесты? Объясните мне? Это пишется 1 раз, проверяется 1 раз и больше не меняется никогда. Нафига тратить время на тестирование статического функционала?
Писать тесты надо на вещи которые можно случайно испортить и не заметить этого. Как можно испортить метод в контроллере? Дописать логику и случайно переписать гет на пост? Запустить тест и понять что, ой, я сломал контроллер, надо было оставить гет как было раньше.
Любой анализ может привести к убыткам. Наибольшая вероятность выйти в плюс это купить в долгосрок стабильные дивидендные акции. Либо торговать внутри дня супер короткими позициями, если ты натрентровался и научился видеть динамику. Любая позиция от одного дня может быть убыточной в любой, казалось бы беспроигрышной ситуации. Всё, больше ничего можешь не читать, пользуйся. Простой пример из последнего. Неделя до лив отсечки лукойла. Из всех чайников все трендят про то что надо покупать и через несколько дней перед отсечкой продавать. Изи мани. Но никто не ожидал что эту всю неделю лукойл, как впрочем и весь рынок упадёт больше чем собственно сами будущие дивиденды. Причём на ровном месте. Да, там было ожидание ставки ЦБ, но, извините, ожидание увеличения в 1% не должно было привести к падению рынка на 5-10%.
Что это у вас там за такое ужасное легаси, которое через 3 месяца на 10% покрыто тестами. Легаси которое мне всю жизнь попадается обычно такое, что оно вообще не поддаётся никакому покрытию тестами. Так что это у вас видимо шикарное легаси.
Я тоже раньше работал в райфе программером но суть не в этом. Наш мидл и в скором времени синьор аналитик мог по дороге в метро на смартфоне написать на питоне скрипт обращения к стороннему веб сервису, проанализировать ответы и, прийдя на рабочее место, писать для разрабов чё куда какие педали нажимать. Вот это мощь.
Нет четкого определения кто такой тимлид и что должен делать. Поэтому много вопросов на этот счёт. По нашему это называется руководитель группы разработки. Т.е. очевидно, человек должен руководить процессом разработки в своей группе. В зависимости от типа компании, состава команды, специфики заказчиков, типа проектов, процесс разработки может быть сильно отличающимся. Задача руководителя разработки сделать так, чтобы работа была сделана как можно качественнее за как можно меньшее время. Он должен уведомлять вышестоящее руководство о проблемах, которые требуют их участия, например, нехватка программистов, нехватка компетенций, проблемы с аналитикой тестированием и т.п. Если для решения этих задач ему надо программировать, он должен программировать. Не вижу противоречий. И не могу представить тимлида который сказал бы что не хочет ни в коем случае писать код. Например, он решил что надо попробовать новую либу или новый подход. Он может поручить исследование разработчику. Если разработчики заняты, может исследовать сам, почему нет. Если ему постоянно приходится выполнять роль обычного разработчика делая задачи спринта большую часть своего времени, значит в команде не хватает разработчиков, его задача послать сигнал руководству. В конце концов, сами смотрите что надо делать, конечная задача ясна.
Вероятность выполнения таких условий в компаниях в РФ стремится к нулю
Во-первых это не так. Даже я однажды работал в месте где техлид не писал совсем. А во вторых, допустим ты стал тимлидом, что тебе мешает доходчиво объяснить руководству почему делать надо так, а не иначе?! Думаю причина в том, что тот кто у вас там тимлид просто не может это сделать. А раз не имеет способности блестнуть лидерскими качествами и даром убеждения, ну пусть пишет код тогда. Так что становись тимлидом и меняй процессы.
Никто специально никому ничего предоставлять не будет. Ни у кого нет времени делать 10 разных схем и мапить их друг на друга. Есть одна схема, оркестрирующая бизнес процесс, и она либо понятна, либо не понятна. Если она в виде визульных кубиков со стрелочками, к бабке не ходи, что это а сто раз понятнее любого текстового описания без картинок.
Поэтому поведение должно быть зафиксировано тестами. Какой там будет сгенерирован в пайплайне код для реализации тестов не важно. Так что аналогию провести можно. И точно так же как рукописный, ии код поддерживать не надо, в этом и смысл. Надо поддерживать задачу которую ты ставил ии + тесты. Я ближайшее будущее вижу только так. Иначе ии это просто помощник программиста, как инструмент, но не более того.
Ну справедливости ради должен заметить что и текущая его роль сильно полезна. Я, например, недавно с его помощью решил задачу за которую без него даже не взялся бы, потому что было очевидно что это займёт неприемлемое количество времени. С ним мы справились довольно быстро.
Я не об этом. Я о том что к сгенерированнному коду почему-то предъявляются такие же требования как к рукописному, что само по себе нонсенс. Например если в сгенерированном есть дублирования кода, да и хрен с ним. Этот код вообще смотреть не надо. Надо лишь делать хорошие способы проверки работоспособности такого кода. Возможно в будущем будут более высокоуровневые языки которые будут выглядеть как правильно оформленная постановка задачи для ии, а сам код будет генериться в пайплайне. Вот я про что. Но тема новая, это всё только предстоит сделать и придумать.
Но другое дело когда ии делает маленький кусочек, а ты его потом допиливаешь. Но фактически ты полностью сам ревьюишь и дорабатывешь код. Но это другое.
Потому что способ создания кода поменялся, а парадигмы разработки, проектирования и тестирования нет. В зтом и проблема. Например, допустим ты сгенерил класс, какие-то там методы и т.п. ты не сильно вникал что там внутри получилось, тебе важно чтобы оно делало то что надо и делало это хорошо. Очевидно что такой код должен иметь минимальную связность, должен быть покрыт тестом и должен иметь описание постановки задачи для ии, чтобы можно было его перегенерить сколько угодно раз. Код становится черным ящиком , и это нормально. Код становится дешевым, проектирование остается дорогим, даже становится ещё дороже. И не нужны там никакие анализаторы правильности кода, т.к. такой код должен восприниматься как черный ящик. Если черный ящик работат неправильно, он за несколько минут перегенерируется на новый черный ящик.
Вот что я имею в виду. Способ программирования поменялся, всё остальное осталось старым, хотя тоже должно поменяться.
По инивестициям бы добавили ещё. Вот лучший @StockRobotWinBot
Очень согласен. Расскажу немного свой опыт. Я профессионально программирую на работе по 8 часов в день примерно 18 лет, сколько ещё до этого, никто не знает. За всё это время по-настоящему что называется эргономичного стула нигде не было ни разу. Последние несколько лет работаю как положено, в основном на удалёнке. Дома у меня вообще нет офисного кресла и рабочего стола, поэтому работаю полулёжа на диване с раскладной подставкой под ноут. И ничего у меня не болит, и спина не устаёт. А происходит это потому, что у меня дома вместо всяких эргономичных столов и стульев есть силовая рама, штанга, скамья и т.д. Ты берёшь, делаешь становую тягу, приседания и жим лёжа. Вот что реально помогает от спины, а не вот то всё что перечислено у автора в посте. И нечего тут выдумывать, это всё уже давно известно и проверено. Особенно умиляют советы типа монитор на уровне глаз. Вот от таких советов точно пипец твоей спине будет, сидеть в таком напряжении с вытянутой шеей.
Я не специалист по яндекс маркету, предпочитаю туда не попадать. Про плюс минус не хуже я написал условно, имею в виду смысл там такой же, реализацию сравнивать не берусь. Да, раньше можно было сверять спецификациии, как ты отлично выразился, а сейчас ощущение что ты на черкизон пришёл.
Раньше яндекс маркет был энциклопедией или, если хотите, каталогом техники и не только. Можно было вбить любое название и пожалуйста. Ты видишь все модели, что чем отличается и т.д. Если тебе нало было понять чем один комп отличается от другого или чем один фотик отличается от другого или какая моьила лучше по твоим критериям, ты шёл в яндекс и получал ответы на все хти вопросы.
Последние несколько лет яндекс стал точно таким же как вайлдбериз и озон. Ничем не лучше, ничем не хуже (плюс минус). Но, мы лишились того что было раньше. Больше такого каталога не существует в рунете. Был уникальный продукт, стал такой же как у всех. Уж могли бы придумать как делать деньги из того что было раньше, чем щас. Вот главная проблема. Шас уже даже какой-нибудь днс в этом плане лучше стал. Там и профильтровать норм можно и купить, ассортимент у них норм. И это магазин, в отличии от цыганского яндекс рынка.
Как ты далёк от того что делается в банках, даже не представляешь.
Подтверждаю, всё в точности как было и у меня, включая email режим. Думаю, а может стоит сделать режим оплаты который перебрасывает на внешний ресурс и позволяет использовать всякие быстрые платежи, сберпэи и всё остальное.. пока не решил. Но конкретно текущий встроенный в телегу режим работает отлично.
Вопросы дурацкие, особенно про кота. После него можно встать и молча выйти. Но похоже что автор и сам не знает ответы на сво же вопросы, потому что пример про класс с временем текушим назад это полный бред. У тебя там ничего никуда не течет, это просто класс с двумя мат операциями над временем. Класс времени которое течет назад это надо создать инстанс, записать там текущее время и потом в методе Now вернуть стартовое время - (текущее- стартовое)
Почему автор как достижение говорит про вот такие вещи, что стало меньше ошибок по невнимательности:
Типичный пример: пишем в контроллере POST вместо GET.
Вот зачем на это вообще писать тесты? Объясните мне? Это пишется 1 раз, проверяется 1 раз и больше не меняется никогда. Нафига тратить время на тестирование статического функционала?
Писать тесты надо на вещи которые можно случайно испортить и не заметить этого. Как можно испортить метод в контроллере? Дописать логику и случайно переписать гет на пост? Запустить тест и понять что, ой, я сломал контроллер, надо было оставить гет как было раньше.
Любой анализ может привести к убыткам. Наибольшая вероятность выйти в плюс это купить в долгосрок стабильные дивидендные акции. Либо торговать внутри дня супер короткими позициями, если ты натрентровался и научился видеть динамику. Любая позиция от одного дня может быть убыточной в любой, казалось бы беспроигрышной ситуации. Всё, больше ничего можешь не читать, пользуйся. Простой пример из последнего. Неделя до лив отсечки лукойла. Из всех чайников все трендят про то что надо покупать и через несколько дней перед отсечкой продавать. Изи мани. Но никто не ожидал что эту всю неделю лукойл, как впрочем и весь рынок упадёт больше чем собственно сами будущие дивиденды. Причём на ровном месте. Да, там было ожидание ставки ЦБ, но, извините, ожидание увеличения в 1% не должно было привести к падению рынка на 5-10%.
Что это у вас там за такое ужасное легаси, которое через 3 месяца на 10% покрыто тестами. Легаси которое мне всю жизнь попадается обычно такое, что оно вообще не поддаётся никакому покрытию тестами. Так что это у вас видимо шикарное легаси.
Я тоже раньше работал в райфе программером но суть не в этом. Наш мидл и в скором времени синьор аналитик мог по дороге в метро на смартфоне написать на питоне скрипт обращения к стороннему веб сервису, проанализировать ответы и, прийдя на рабочее место, писать для разрабов чё куда какие педали нажимать. Вот это мощь.
Нет четкого определения кто такой тимлид и что должен делать. Поэтому много вопросов на этот счёт. По нашему это называется руководитель группы разработки. Т.е. очевидно, человек должен руководить процессом разработки в своей группе. В зависимости от типа компании, состава команды, специфики заказчиков, типа проектов, процесс разработки может быть сильно отличающимся. Задача руководителя разработки сделать так, чтобы работа была сделана как можно качественнее за как можно меньшее время. Он должен уведомлять вышестоящее руководство о проблемах, которые требуют их участия, например, нехватка программистов, нехватка компетенций, проблемы с аналитикой тестированием и т.п. Если для решения этих задач ему надо программировать, он должен программировать. Не вижу противоречий. И не могу представить тимлида который сказал бы что не хочет ни в коем случае писать код. Например, он решил что надо попробовать новую либу или новый подход. Он может поручить исследование разработчику. Если разработчики заняты, может исследовать сам, почему нет. Если ему постоянно приходится выполнять роль обычного разработчика делая задачи спринта большую часть своего времени, значит в команде не хватает разработчиков, его задача послать сигнал руководству. В конце концов, сами смотрите что надо делать, конечная задача ясна.
Во-первых это не так. Даже я однажды работал в месте где техлид не писал совсем. А во вторых, допустим ты стал тимлидом, что тебе мешает доходчиво объяснить руководству почему делать надо так, а не иначе?! Думаю причина в том, что тот кто у вас там тимлид просто не может это сделать. А раз не имеет способности блестнуть лидерскими качествами и даром убеждения, ну пусть пишет код тогда. Так что становись тимлидом и меняй процессы.
У нас раньше техлид был человек который вообще не программист ни разу даже. А тимлида не было, т.к. по скраму не положено.
Никто специально никому ничего предоставлять не будет. Ни у кого нет времени делать 10 разных схем и мапить их друг на друга. Есть одна схема, оркестрирующая бизнес процесс, и она либо понятна, либо не понятна. Если она в виде визульных кубиков со стрелочками, к бабке не ходи, что это а сто раз понятнее любого текстового описания без картинок.
Не вижу причин почему в bpmn нельзя всё то же самое изобразить. Это просто кубики на схеме, пиши там что хочешь
Будет прикольно посмотреть как ты думаешь заполняешь таблицу последовательности действий со сложными ветвлениями в зависимости от условий.
Я кстати не привык строить схемы, но это единственная возможность понять что вообще происходит.