0: Последние несколько месяцев полностью разрушили мою уверенность в себе практически все постулаты, на которых я опирался, они оказались несостоятельными, сами знаете, по каким причинам нужно.

1: Полностью пересматривать всю концепцию. Я вам сегодня несколько примеров покажу, в которых я уже пересмотрел принципы свои поменял и к этому вас призываю, но не настаиваю, поскольку они не настояли.

2: 20 лет ещё не прошло, и, возможно, через несколько месяцев все поменяется. Опять посмотрим, на чем все основывается. Какая главная. Главный фактор, который повлиял на ситуацию, это объём кода.

3: За последний год количество коммитов, которые приходят на гитхаб, выросли в 15 раз. Количество программистов осталось тоже, а количество коммитов выросло на порядок. Сами понимаете, кто причина. Сами понимаете, кто автор этих.

4: Вы понимаете, что это не люди, а это роботы. Огромная лавина кода на наши головы. За последний год. За последние месяцы вылилась и эта лавина, эта волна она снесла.

5: Большое количество правил и принципов, на которых мы, на которые мы опирались, но вынудило придумать новые. Давайте посмотрим, какие они всего. Их будет 7, и помним об этом ключевом факторе. Объём определяет

6: Сейчас все наши, все наши концепции, все наши формулы, по которым нужно жить. 1 пример от простого будем идти к сложному много лет подряд. Я считал, что я считал

7: Мы считали, что код должен быть читаемый, должно быть понятно не мне, автору, а читателю, который будет читать то, что я пишу, поэтому код нужно, что комментировать, код нужно объяснять, недостаточно просто написать алгоритм, а ещё и запутать.

8: Алгоритм. Нужно добавить комментарии в эпоху ллм, в эпоху агентов никто код читать не будет. Человек больше код не читает, никому не интересны ваши комментарии и никому не интерес не интересен. В принципе, ваш код, кроме робота, кроме

9: Агента, а робот путается, когда видит в комментариях 1, а в исходном коде другое. И роботу комментарии не нужны. Ему не нужно разжёвывать, что вы сделали? Он, глядя на код, понимает прекрасно, что происходит, мы не понимаем, я не понимаю, он понимает.

10: Поэтому комментарии мешают, как показывают исследования, они могут даже путать, хотя исследования 2 двухлетней давности, но сейчас, я думаю, ситуация ещё хуже. Чем больше пишем комментариев, тем делаем хуже нам. То есть сейчас важно, чтобы код был нечитаемый, а код был

11: Максимально минимальный, упрощённый, точный. Он должен только то делать, что он должен делать без лишних слов. Приведу вам пример. Мы в наших проектах запрещаем комментарии скриптами на сборке в хаске.

12: Или мы полностью запрещаем комментарии в java скрипте, полностью запрещаем любые комментарии какие бы то ни было в джаве, мы на перепутье, сейчас мы на пути к полному запрету комментариев, скрипт жёстко запрещает любые комментарии в исходном коде такого.

13: Не было в течение 20 лет. И вот новая реальность.

14: Вы все знаете, что такое legacy код?

15: Это то, что написали год назад мы, причём с вами и сегодня читать мы это не хотим, потому что оно нечитаемое, оно непонятное, тяжёлое, старые зависимости, тесты не запускаются. Проще это выбросить и написать заново, либо не трогать, либо

16: Проигнорировать тот факт, что мы потратили много времени и сил на кодовую базу, которая больше не рабочая ситуация поменялась. Сегодня мы не переписываем, мы оживляем проекты и делать это легко. Я приведу конкретный пример.

17: Весной взял свой проект, который был создан 10 или 12 лет назад мною на джаве. Когда я его сделал, мне было интересно им заниматься. Потом он стал использоваться. Это статический анализатор, который мы используем.

18: Всех наших java проектах он использовался и мною, и многими другими, но поддерживать его было лень, ну потому что это определённая работа, тогда никакого клода не было, и поддержкой никто не занимался, за 10 лет накопилось.

19: Более 400 тикетов внутри бэклога это опенсорсный проект. Весной я попросил клод код исправить все 400 ошибок, полностью восстановить кодовую базу, привести её в актуальное состояние, проапгрейдить зависимости.

20: И сделать из него чистый современный проект. Около недели у нас ушло на это. Я не трогал код. Естественно, я только нажимал кнопку дальше, дальше, дальше. И так. В течение недели. В итоге я получил свежий проект, полностью восстановленный, живой в нём

21: Чистенький бэклог, всего несколько дефектов, их легко поддерживать, мы живём дальше, автор статьи рассказывает подобную историю, они вместо того, чтобы потратить полтора года на работу, они потратили 3 недели, несколько тысяч долларов и полностью.

22: Восстановили проект, то есть в новой реальности мы не выбрасываем репозитории, мы не считаем их легаси. Мы вообще термин легаси убираем. Нет больше legacy кода. Есть просто код, который пока по каким-то причинам не попался в руки клод коду, ну или другому агенту.

23: То, что было раньше, проблемой, становится сейчас возможностью вы можете взять старый репозиторий, восстановить легко и получить снова работающий продукт.

24: Много лет я считал, что главная задача архитектора в проекте мейнтейнера опенсорс репозитория не только опенсорс в том, чтобы контролировать 2 главные точки в проекте. 1, что такое дефекты, то есть

25: Вам приходят репорты об ошибках, и вы должны решать, это дефект или это не дефект? Ну, по-английски трай эджин. То есть вы должны направлять входящие запросы либо в мусорник, либо либо в мусорную корзину, либо в бэклог. И 2, вы должны смотреть на

26: Диффы на change, реквесты на пулл, реквесты и тоже принимать решение принимаем или нет вот 2 точки контроля, и вы должны внимательно относиться к своим обязанностям. Чем внимательнее, чем тщательнее вы будете выбирать, что для вас дефекты и что для вас допустимые изменения, чем

27: Точнее будете давать ответ тем, кто присылает, тем будет project выше качество внимание было важным, вы не можете этого больше делать, если вы будете уделять внимание пулл реквестам и баг репортам лично руками вы будете.

28: Наносить вред своему проекту, потому что объёмы растут, скорость растёт, роботы присылают изменения, люди их больше не присылают, роботы присылают. Если вы руками своё личное время человеческое тратите на такую работу, вы только снижаете.

29: Скорость в проекте и снижаете его качество. И об этом пишут. Говорят, что в современных реалиях невозможно потратить интеллектуальные усилия на проверку, и все превращается просто в, как они говорят, рабер стемпинг. То есть мы просто ставим печать на

30: Чем бы то на всем подряд у нас в репозитории репозиторий не супер большой, там 1500 звёзд каждый день приходит порядка 100 багрепортов 100. Каждое утро я просыпаюсь, открываю у меня 100 новых багрепортов, я не могу.

31: Физически их посмотреть, даже если я буду очень погружён в проект. А у меня таких проектов, таких репозиториев, ну, штук 10, точно активно в активной разработке. То есть я примерно в день получаю 1000 багрепортов. Ну, эти цифры, которые никак на человека не

32: А сами понимаете, что мы сделали. Мы сейчас имеем агентов. По крайней мере, у меня так это происходит. Агент, который каждое утро, а то и несколько раз в день запускается и делает автоматическую проверку входящих багрепортов, и принимает их, и говорит, да, это багрепорт принимаем.

33: За меня и проверку пулл реквестов, и автоматически их мерджит автоматически я не вижу, что попадает в репозиторий. Я просыпаюсь с утра и к вечеру у меня 40 50 пулл реквестов попало в кодовую базу без моего внимания. Это активный

34: Проект в разработке, он в продакшене, он используется, и он в автомате, в автоматическом режиме вслепую попадают ко мне пулреквесты. Это к вопросу о том, что, может клод и что не может. Я доверяю сейчас уже агенту настолько, насколько я доверяю самому себе.

35: В этом вопросе, конечно, есть оговорка в процессе, в этом скрипте, который делает такую процедуру, есть оговорка. Если ты встречаешь изменения, которые тебе кажутся слишком сложными или слишком радикальными, то не

36: Не делай, не сливай пулреквест, оставь его для ручной проверки и меня там. Затегай, поставь меня в ревьюеры, и я дальше посмотрю попозже. Такие тоже бывают. Их всего несколько в день. Я вручную их просматриваю и потом принимаю. То есть внима.

37: Которое раньше было добром, сегодня это зло, это отвлечение только отвлекает наше внимание. Вы должны научиться настраивать агентов таким образом, чтобы они за вас принимали изменения и решали, что хорошо, что плохо в проекте.

38: Больше вы как ревьюверы, никому не нужны. Больше ваша ценность. Как мы думали, я к вам обращаюсь к себе точно также наша ценность как людей, способных анализировать изменения и принимать решения. Она ниже, чем

39: Способность машин и поэтому мы вредим, а не помогаем проекту.

40: Я учил студентов на своём курсе, о котором я вас, я вам сказал, что очень важно в open source территории, которая очень токсична по определению уважать своего оппонента собеседника, если вам присылаю.

41: Pull request. И вы понимаете, что там изменения недостаточно качественные, не той функциональности и вообще не соответствуют вашему пониманию о добре, то вы должны вежливо используя. Спасибо, пожалуйста, извините, со своим собеседником.

42: Взаимодействовать, коммуницировать, чтобы он не обиделся, потому что ваши контрибьюторы, ваши программисты это ваш актив. Они завтра придут с новыми изменениями, они снова пришлют вам код, вам необходимо с ними быть вежливым.

43: Все это в прошлом. Сейчас напротив меня машина робот. Я понимаю, что программиста нет в пулреквесте. Это не программист, это курьер, это человек, который запустил агента, нажал кнопку сделать пулл. Реквест посидел 15 минут.

44: Увидел, что пуллреквест сделан, и закрыл компьютер. Он не программировал, а значит, ему все равно, вежливый я с ним или нет. То есть тратить время на обсуждение, на разговоры, на переговоры с человеком не имеет смысла. На той стороне находится робот.

45: Поэтому нужно быть максимально жёстким. Мы можем наконец то имеем возможность быть максимально жёсткими и делать reject, не совершенно не беспокоясь о том, какие чувства и какую эмоциональную реакцию это вызовет у.

46: Автора пулл реквеста или у автора багрепорта он прислал вам фичу, которую вы не хотите имплементировать, вы нажимаете кнопку close на этом все, никто не обидится, там никого нет.

47: Там пустота, там робот, машина. Ему наплевать, чего вы должны добавить и что мы можем сейчас добавить. Это инструменты автоматического реджекта. Я вам приведу пример. Мы много лет считали в наших командах, что пул. Реквесты должны быть короткими. 100 строк кода изменены.

48: Ну, 200 строк это уже предел пулреквест, в котором 1000 строк кода изменено. Это заведомо плохой пулреквест. У нас были дебаты в офисах, у нас были обсуждения, кто-то был не согласен, кто-то говорил, ну как, если я имплементирую большую фичу, там может быть 1000 строк, я не хочу.

49: Разбивать его, её на 5 пулл реквестов. Я пришлю 1 на 1000 строк и это все обсуждения, дебаты, споры и так далее. Что мы сделали сейчас, буквально полгода назад, мы сделали скрипт внутри нашего, нашей

50: Хаб платформы, где проверка идёт автоматическая на каждый пул реквест. Если у вас ваш пулл реквест больше чем 200 строк кода суммарно добавление или удаление, то просто автоматически сиай говорит, красный цвет и ваш пулл реквест не прохо.

51: Проходит проверку и нам все равно что вы чувствуете в этот момент и вам не с кем разговаривать, потому что это si это автоматическая автоматический флажок, который красного цвета, у вас нет возможности какой-либо диспут открыть на эту тему и таких.

52: Контроль таких контролирующих флажков должно быть побольше в ваших репозиториях, потому что никто не будет плакать, что они красного цвета. Просто робот увидит, что он красного цвета поймёт, что pull request в этом репозитории должен быть небольшого размера разобьёт.

53: Его на 2 или 3 пулл реквеста и пришлёт их отдельно. Точка. Вы никого не обидите, вы сделаете хорошо себе, вы становитесь максимально эгоистичны в вопросах качества своего репозитория и никого этим не ущемляете. Так не было 20 лет подряд. И вот теперь

54: Пришло это время, это здорово. Я считаю, мы можем добавлять больше и больше контролирующих механизмов, которые в итоге будут давать Зиро толеранс у нас будет 0, у нас будет нулевое, нулевая толерантность относительно качества, относительно низкого качества. Все

55: Что вы считаете низким качеством, закладывайте в автоматические проверки, и вы будете получать просто рост качества, потому что с той стороны будут роботы, добивающиеся качества и умеющие это делать.

56: Я написал двухтомник в прошлом году и в этом посвящённый юнит тестированию как правильно писать тесты, как их оформлять, как делать их дизайн так, чтобы они были понятны читателю, чтобы они были поддерживаемы.

57: Чтобы они были расширяемые, чтобы вы могли вернуться к тестам через несколько лет и сделать их мощнее и так далее. Все это здорово. Этот материал актуален, но не для нас, людей больше машины. Пускай читают мои книги. Люди больше их читать не

58: Будут мы, когда приходит к нам изменения, когда приходит пулреквест и в нём изменены несколько Тестов, мы их не читаем руками. Как уже было сказано, мы не вчитываемся в то, что там мы наблюдаем визуально. У нас нет на это времени для того, чтобы

59: Изменения были визуально понятны человеку нужно в кодовой базе делать так, чтобы любые изменения или большинство изменений приводило к изменению чего-то визуально легко читаемого например yaml файл я вам приведу конкретный пример у нас есть 1 из

60: Проектов. Это парсер исходного кода. У нас есть свой язык программирования, к нему есть парсер, который принимает на вход программу на этом языке и должен на выходе выдавать иксэмэль. Было большое количество джава, Тестов. Вот вам на вход блок

61: Кода вот вам на выходе xml сравниваем, находим и этих Тестов много много написано было, в итоге мы от них отказались и сделали 1 тест и большое количество ямл файлов так называемый так называемых тест фиксер и в этих тестовых ямлах.

62: Yaml файлов ямл файлах фрагмент кода, который нужно парсить, и фрагмент иксэмэль, который должен получиться теперь, когда приходит пулл реквест, я в нём визуально, не вчитываясь в изменение кода, в которых я вообще не пойму уже сейчас ничего, я сам.

63: Не понимаю код, который пишут мои агенты, и не пытаюсь его понять, потому что это не принципиально, нет у меня времени на это, но яму файл я вижу, я понимаю, что вот вчера мы получали такой вход и получали такой выход. Что-то там изменил агент в java парсере, что теперь?

64: У меня вход такой, а выход такой. Стоп, с этим я не согласен. Это я не принимаю. А если я вижу, что изменилось, хорошо, то принимаю. То есть вы должны писать код так, чтобы изменение в нём приводило к изменению визуальных артефактов, визуально просто понятных.

65: Человеку код тяжело читать, ямал файл читать легче. Должны быть текстовые файлы в репозитории, которые являются отпечатками тестового выполнения. Тесты прогоняются, и в итоге они генерируют какие-то или

66: Они работают по yaml файлам, то есть используют их как источник, либо их генерируют. И это решение проблемы объёма, о которой я говорил в начале. Огромная волна кода приходит 100 пулреквестов в день ко мне приходит. Я быстро могу десяток из них.

67: Открыть, увидеть, где поменялись ям файл, понять, изменения критичны или нет, быстро принять без этого чтение кода это трагедия.

68: Вы знаете, этот твит известный, да, роберта Мартина. Летом он написал, что я больше не читаю исходный код. Все удивились, поставили ему какие-то миллионы лайков. И, в общем то, это очевидная вещь. Он прав. Мы действительно, как я вам говорю, не читаем исходный код. Это было понятно и до него.

69: Но он подтвердил важный момент в этой цитате, в том, что он говорит я получаю таким образом эдвентед от продуктивности.

70: Роботов агентов, то есть не читая исходный код, мы таким образом позволяем агентам интенсивнее забрасывать нас исходным кодом. Интенсивнее мы перестаём быть узким звеном. Но как же быть? Как же не читать исходный код?

71: Необходимо вместо того, чтобы опираться на диффы, как мы делали раньше, как, как мы делали раньше, 50 лет подряд, вам присылают дифф. Вы на смотрите на изменения кода, понимаете, хорошо это или плохо, потому что вы знаете архитектуру и принимаете изменения. Сегодня мы на диффы не смотрим.

72: Вообще, я думаю, может быть частично, но ещё пару месяцев. И мы просто, видимо, эту функцию в гитхабе уберут. Вы просто не будете видеть исходный код. Я утрирую. Шучу, конечно, но куда-то в эту сторону это идёт, что мы будем видеть, на что мы будем смотреть, как я сказал, пытайтесь.

73: Рпозитории делать так, чтобы каждый пул реквест производил или вычислял импект. То есть что случилось благодаря пулл реквесту, насколько изменилась производительность, где поменялись визуальные артефакты?

74: Насколько изменился объём кода, насколько изменилась, не знаю, ширина кода, насколько изменились показатели качества кода. То есть вы должны настраивать, вы должны настраивать свой ci таким образом, чтобы он вам в пулл реквесте в виде суммы какой-то, то ли в виде мессенджер.

75: То ли в виде отдельного репорта выдавал импект, он вам показывает, он вам должен в сжатом виде в человек под удобном для человека, для человека языке должен описать, к чему приведёт такое изменение. Не как мы изменили, не что мы

76: Изменили. А к чему это приводит в виде метрик. И вот когда мы сможем это сделать, в итоге полностью будем использовать ту логику, которую нам Роберт Мартин преподносит код, мы не читаем, но мы в каждом случае понимаем, куда движется проект, и вы должны тратить свою

77: Время не так, как я вам раньше говорил руками просматривать пулреквесты и делать разборку дефектов, а настраивать инструменты контроля импакта. То есть что происходит, на что влияют изменения.

78: И последнее, самое интересное я много усилий потратил на конференциях и в блоге писал о том, что continuous integration это хорошая штука, все знают что

79: Такое все его используют. Но проблема континиус, интегрейшен в том, в его базовой версии, в том, что предполагается, что мы собираем наш проект регулярно, раз в день, раз в час, раз в неделю, когда мы

80: Его собираем, мы понимаем, что произошли ошибки и эти ошибки исправляем. Такая была изначально оригинальная идея. Континиус интегрейшн ещё от фирмы майкрософт. Если я не ошибаюсь, но я говорил так не работает, потому что когда вы поймёте, что ваш проект не собирается, будет уже поздно. Это

81: Случится ночью. Вы придёте с утра, поймёте, что ночью он не собрался. Вам нужно будет останавливать разработку, потому что тесты не проходят. Билд не собирается, релиз не работает. Значит, нужно остановить всю команду, и эта вся команда должна заниматься фиксом того, что

82: Тот, того, что было сломано вчера 1 из программистов. И даже была такая оригинальная шутка. Когда контин интегрейшн внедрялся, предлагали надевать такую специальную шапку шапку позора на того человека, кто вчера нам сломал билд. И вот в этой шапке он

83: Должен сидеть весь день, поскольку вся команда занимается подчисткой того, что он сделал вчера. Это смешно, это забавно, но это не работает, потому что это останавливает девелопмент. Процесс. Чтобы работал континиус интегрейшен, нужно, чтобы при каждой, при каждом внесении изменений в ма.

84: Brunch, или в основную ветку разработки мы проходили полный билд, и только робот мог не тот робот, который сейчас не ai a built робот мог внести изменения в мастер бранч, то есть build робот должен брать вашу ветку, соединять с мастером у себя.

85: На машине запускать билд. Если все собирается, он делает пуш мастер такой префлайт билд, так называемый прекрасная идея. Она работала, и мы ею пользовались всегда. Но несколько месяцев назад мы поняли, что эта идея мертва, потому

86: Потому что к нам приходит, как я сказал, 100 пулл реквестов в день. Каждый билд у нас занимает порядка, ну, минут 10 на проекте. Умножьте 10 на 100. И при этом ещё учтите, что каждый пул реквест. После того, как он попадает в мастер, он меняет

87: Ситуацию в мастере и нужно следующий пулреквест запускать только после него, а github actions континьюс интегрейшн их внутренний, он предполагает, что после того, как что-то попало в мастер, то все остальные пулреквесты, они становятся невалидными поскольк.

88: Они были собраны, их ci. Флажки были установлены на старой версии мастера, и приходится делать апдейт бранч. Короче говоря, все это приводит к неразрешимой проблеме. Просто не хватает ресурсов. Гитхаб не разрешает нам запускать такое количество.

89: Процессов. Такое количество сборок одновременно и у нас все останавливается. Мы просто не можем собирать пулл реквесты на такой скорости мы в сутки не можем уложиться. Если каждый занимает по 10 минут, умножаем 100 на 10. Мы просто будем

90: Это в 1 репозитории. Мы будем долго ждать и никуда не продвинемся. Но континиус интегрейшен нам нужен для чего? Для стабильности? То есть мы хотим, чтобы сборка была у нас чистая. Мы хотим, чтобы build в основном репозитории, всегда собирался для того, чтобы

91: Программист мог взять мастер ветку от неё стартовать, и там все было чисто. Эта идея мертва. Так не будет. Мы пришли к Такому выводу, что мы не можем больше ожидать стабильности. Стабильность недостижима в реальных условиях сейчас.

92: На огромном таком объёме данных, и он будет только увеличиваться. Мы просто не можем ожидать, что мастер бранч стабилен. Мы должны исходить из постулата. Он сломан, скорее всего, и должны настраивать агентов правильно, чтобы они подхватывали.

93: Ситуацию сломанного мастер бранча, которая случается у нас сейчас 2 раза в день. И мы живём с этим. Мы понимаем, что раз мы хотим мерджить на скорости 100 пулреквестов в день, мы должны жить со сломанным мастер бранчем, но у нас должны быть настроены скрипты, кото

94: Который, как только он переходит в состояние красное, то есть сломан, мы тут же подхватываем ситуацию, запускаем клод код, он фиксит тот дефект, который случился, отправляет новый пул реквест. Мы этот pull request принимаем в мастер и продолжается разработка, то есть новая реал.

95: Это сломанный мастер бранч практически постоянно. Я не знаю, как по другому решить эту проблему. Предлагаю вам подумать, но наша ситуация такая. Он у нас был. Мы пытались удержать ситуацию стабильности. Мы пытались как-то ужимать, компрессировать, делать билды, Коро.

96: Но в итоге мы ниже, чем 10 минут, мы не можем опуститься на сборке, просто ниже она не бывает. И, ну, в нашей, в нашей ситуации, даже если мы разобьём проект на части, ну, 10 минут, это допустимое время для, для сборки проекта из 100000 строк кода, что де,

97: Делать, мы не знаем. В итоге мы пришли к выводу, что стабильность это какая-то идея из прошлого. Современная идея это скорость. Нужно делать все, чтобы сборки были, чтобы в мастер код попадал на максимальной скорости, жертвуем стабильностью. Ну вот.

98: В общем то, все это мой telegram канал, подписывайтесь и давайте вопросы.

99: Здравствуйте, спасибо.