Представьте себе, что вас пригнали на несколько докладов на типичную конференцию типа WWDC по структуре: Презентации по полчаса, несколько выступающих о том как повысились надои в бекенде с подробным разжевыванием того, что сделано и Q&A в конце, часть тем вам интересна, а часть нет.
Текст хорош тем, что по нему легко искать, легко общаться асинхронно, он может быть визуален (отступы, буллиты, жирнота и прочее).
Голос хорош тем, что он не занимает руки (можно одновременно показывать что-то и говорить, например) он принудительно синхронен (обычно не принято просто так класть трубку и куда-то уходить — в чате это делается достаточно легко), многим проще говорить чем печатать.
Голос хорош если нужен быстрый обмен короткими сообщениями и желательно побыстрее получить результат.
При большой асинхронности приходится угадывать что собеседник уже знает и писать всякие введения с запасом для тех, кто не знает, в чате или голосом можно сначала это выяснить а потом написать или сказать сфокусированное сообщение.
Хреновые созвоны не учитывают эти особенности:
слишком много лишних людей, которые и бесполезны и им не интересно
не используется интерактив (получается что-то типа видеоролика который нельзя промотать)
не используется возможность подготовки заранее (формулирования повестки, например, случайный выбор участников и так далее)
В хорошем созвоне участвют только те, кому это надо и интересно. Результат может быть зафиксирован текстом (именно результат, все промежуточные переговоры не интересны).
А вот интересно как в ФП стиле решить эту задачу. Только чтобы перечень героев игры был расширяем. Мы делаем движок с человеком, а кошки и разные модели кормушек в аддонах.
Smalltalk's graphics class had a method for this called 'highlight', whose implementation was just a call to the method 'reverse' [4]. The name of the method was longer than its implementation — but that didn't matter because there was a big distance between the intention of the code and its implementation.
Есть еще проект MAUI планируется на .NET 6, судя по странице, как-то Linux может поддерживаться (там написано community, как у Xamarin Forms, вероятно, это будет делать не MS, а классический opensource)
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test.
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.
Если для вас приемлемы sociable юнит тесты с фейками, то: создаем единственный фейк на кеш. При его изменении его меняем. Надо поменять только тесты на кеш и фейк. Тесты тех, кто использует кеш остаются, примерно такими же, кроме новых требований (т.е. ситууации когда возвращаются ItemState отличный от того который раньше кодировался булеаном и это важно в конкретном требовании).
Так же см разные паттерны у Шора. Например, использование signature shielding.
Еще можно сохранить совместимость с boolean либо просто добавив новый метод вместо переделки существующего, либо сделав imlicit cast к булеан. Последним, правда, я не пользовался, если у кого-то есть какой-то опыт, было бы интересно узнать.
Вы пытаетесь использовать ветки для документации истории изменений. Но они для этого не предназначены. Они нужны для изоляции кода.
Как раз для изоляции — фич друг от друга.
Для документации изменений существуют комментарии к коммитам, где может быть любая исчерпывающая информация.
Коммиты бывают разные — например в процессе разработки фичи могут быть эксперименты, откаты на предыдущие версии, мердж с мастером и так далее.
Все это нужно до того момента, когда надо интегрировать фичу, после того как фича готова, это можно засквешить.
Мердж коммит находится «вдалеке» от основного коммита и надо искать где находится тот, про который написано в мердже.
Делается squash merge и я вижу только один коммит. Если не хочется сквешить, то можно проребейзить перед мерджем и они будут рядом.
А в мастер не обязательно мержить, когда вся фича готова. Можно замерджить и 10 фич и полфичи.
Чем больше объем мерджа тем больше разбираться что сломало CI, меньше гранулярность при черрипике, если надо будет, больше объем ревью и так далее.
Полфичи можно, но тут надо понять, чтобы не было неконситентного нового наблюдаемого поведения. Если его нет, то либо эти пол фичи можно выделить в фичу, либо будет мертвый код. Хотя, это, в принципе допустимо, многие так делают изолировав новое поведение фичетаглами.
Необязательно: она может быть сделана, но непроревьювена.
Зачем ее тогда брать, после ревью может быть сильно изменена?
Почему нельзя взглянуть сразу в коммит сообщения, где так же будет ссылка на таску в джире (если коммит связан с таской). Зачем мне идти в мердж коммит, который фиг знает где, открывать пул реквест и только там смотреть конкретные таски?
Что значит фиг знает где? Он составляет историю мастера.
Я совершенно не против, чтобы там были и идентификаторы фич. Просто если их много удобнее видеть ссылку PR в целом и текстовый осмысленный коммент, если нужны детали можно открыть PR и ходить по ссылкам на фичи если их несколько.
Если она одна, наверное, иметь ссылку на PR чуть менее удобно, чем на фичу в джире на один дополнительный клик. Зато имея ссылку на PR можно посмотреть и дополнительные вещи (типа кто ревьюил и какие были замечания.)
У меня обычно наиболее гранулярные коммиты содержат атомарные правки типа "переименование метода", который мало кому интересны кроме меня, но я зато всегда могу откатиться на предыдущую версию в процессе работы над фичей, но там обычно нет ссылки на багу. На багу ссылается ветка в целом.
Зачем что-то мержить в мастер пофично?
Потому, что вы можете работать, как вы сами говорили, над несколькими фичами, одна может быть готова отправке в мастер, другая не готова — тесты не дописаны, не компилируется, нет документации или какие там у вас характеристики проверяет билд еще.
какую версию кода брать для дальнейшей работы над другими задачами: с фичей или без неё.
Если она не вмерджена в мастер, значит не готова. Берите всегда из мастера. (Кроме того случая, когда вы работаете над долгоиграющей фичей — тогда берите из фичи, над которой работаете)
Совершенно верно. Собственно так это и задумывалось
Приведите цитату плиз, я там услышал что им удобно репо на команду, а не ветку на разраба
Merge commit будет содержать название ветки, но что мне это даст?
Обычно он содержит ссылку на PR которую можно открыть и посмотреть все детали
Как фича бренчи улучшают понимание, если разработчики синхронизируются только с мастер веткой?
Если они синхронизируются с мастером, то, по крайней мере, можно для работе в процессе понять какие изменения для какой фичи предназначены. Можно так же мерджить их в мастер пофично (всегда решить какую фичу вмерджить, а какую — нет). Для готовой работы есть уже мастер с его историей.
Но зачем засорять гит тысячами мелких бренчей мне непонятно.
Так они его не засоряют. Обычно они живут пока фича разрабатывается и умирают после мерджа в мастер — причем, это автоматически происходит при завершении пулл реквеста. При следовании соглашениям о наименовании для бранчей типа feature/AddLoginDialog их можно не видеть, пока явно не захочешь, но зато, если захочешь можно увидеть.
Что значит зачем? Программирование — это творческий процесс. Разработчики работают, как им удобнее. Если у меня есть 2 задачи по фронту и бакенду для фичи A и фронт+бакэнд для фичи B.
То мне может показаться удобнее написать сначала бакэнд для обеих фич а затем фронт для обеиз фич.
Ок тут согласен — вполне допустимо в каких-то случаях создавать ветку на несколько связанных задач, если их удобнее сделать как одну.
Но вы-то предлагает ветку на разработчика — т.е. там должны быть вообще все зачачи разработчика даже логически не связанные или как?
В коммитах должно быть описание. Ваши ветки в этом, кстати, мало помогают. Ибо разработчики смотрят историю основной ветки (как правило).
Наверное тут какое-то недопонимание. Я подразумеваю, что ветки сливаются в какой-то момент в основную. Соответсвтенно, merge commit будет содержать описание и ссылку на задачу и можно будет посмотреть в истории по master.
История в фичебранчах как правило не нужна другим разработчикам, кроме того, случая, когда они совместно работают над долгоживущим бранчем. Но этот случай вообще непонятно, как решать в режиме "ветка на разработчика".
Я например постоянно переписываю документацию. И что мне для каждой опечатки таску и отдельную ветку создавать?
Ага, с моей точки зрения это не должно занимать сильно больше времени, чем написание данного коммента.
Во первых возникает туева хуча веток. Часто работу нельзя правильно разбить по этим веткам, да и не нужно.
Что такое "правильно разбивать" и почему их невозможно разбить?
Кроме того разработчики часто работают над несколькими задачами одновременно. Надо постоянно переключаться между ветками.
Что их заставляет так делать? Как они поступают когда одна задача готова, а другая — еще нет? Как потом в истории разобраться зачем именно было сделано конкретное изменение?
Непонятно куда девать коммиты которые не связаны непосредственно с тасками, либо таски не созданы, либо уже закрыты.
Давайте, переведу на русский — непонятно, куда девать комиты которые не связаны с задачами, либо задач нет либо они уже выполнены.
С моей точки зрения, все коммиты связаны с задачами, если у вас нет никакой задачи не создавайте коммит. Если у вас есть задача, оформите это в багтрекере. Если у вас коммит связан с закрытой задачей, значит в багтрекере вранье — либо задача не закрыта, либо это новая задача, связанная с данной.
Вы имеете ввиду что на одного разработчика ровно одна ветка? Или что ветка на фичу И разработчика?
Ссылка на forking workflow она про создание форков репы а не про ветки.
Если разработчик заводит ветку на инкремент (багу или новую фичу) то все плюсы, которые у вас упомянуты уже соблюдаются.
Разрабочик создает ветку, ассоциируюет ее с таксой в багтрекере — сразу видно кто занимается, после того как он закончил работу он делает пулл реквест и изменение попадает в мастер после ревью. В процессе работы он может мерджить свежий мастер не блокируется другими людьми.
Почти все идеи неуниверсальны. Это не значит, что их не надо поддерживать. Надо просто применять там, где это пододит.
Наверное здесь "локально" означает "в тестовой среде" она может быть нелокально, а в облаке, просто код в тестовом инстансе развернут из данного конкретного бранча. Судя по тексту, автор имел ввиду "я провел ручное End-To-End тестирование этого кода"
Представьте себе, что вас пригнали на несколько докладов на типичную конференцию типа WWDC по структуре: Презентации по полчаса, несколько выступающих о том как повысились надои в бекенде с подробным разжевыванием того, что сделано и Q&A в конце, часть тем вам интересна, а часть нет.
Вы сначала определите, что именно вы хотите отсчитывать? Рабство, расизм или что-то еще? Если расизм то официальный или неофициальный?
Вы лет на 100 где-то промахнулись
Текст хорош тем, что по нему легко искать, легко общаться асинхронно, он может быть визуален (отступы, буллиты, жирнота и прочее).
Голос хорош тем, что он не занимает руки (можно одновременно показывать что-то и говорить, например) он принудительно синхронен (обычно не принято просто так класть трубку и куда-то уходить — в чате это делается достаточно легко), многим проще говорить чем печатать.
Голос хорош если нужен быстрый обмен короткими сообщениями и желательно побыстрее получить результат.
При большой асинхронности приходится угадывать что собеседник уже знает и писать всякие введения с запасом для тех, кто не знает, в чате или голосом можно сначала это выяснить а потом написать или сказать сфокусированное сообщение.
Хреновые созвоны не учитывают эти особенности:
В хорошем созвоне участвют только те, кому это надо и интересно. Результат может быть зафиксирован текстом (именно результат, все промежуточные переговоры не интересны).
А вот интересно как в ФП стиле решить эту задачу. Только чтобы перечень героев игры был расширяем. Мы делаем движок с человеком, а кошки и разные модели кормушек в аддонах.
Оптимизация, это не всегда упрощение (кеш, предсказание переходов, JIT это усложенение, а не упрощение)
Мне ваш анализ ситуации непонятен. Некешированный доступ к бд — источник тормозов, но, в то же время кеш ничего бы не исправил.
Я правильно понимаю, что исследование произваодительности показало, что узкое место — доступ к БД (т.е. задача IO/Network bound)?
А что именно в этом доступе к БД тормозило? Генерация запросов, latency в сети, составление планов? Исполнение запросов?
https://martinfowler.com/bliki/FunctionLength.html
А как это связано с разбиением на функции?
Есть еще проект MAUI планируется на .NET 6, судя по странице, как-то Linux может поддерживаться (там написано community, как у Xamarin Forms, вероятно, это будет делать не MS, а классический opensource)
undel.
Может зависеть от платформы, напримерп, поддерживает ли компилятор инлайнинг. А может было что-то еще. Надо профилировать.
Тут вопрос, что вы называете моками и что юнит тестами.
Вот терминология у Фаулера моки
Юнит тесты
Если для вас приемлемы sociable юнит тесты с фейками, то: создаем единственный фейк на кеш. При его изменении его меняем. Надо поменять только тесты на кеш и фейк. Тесты тех, кто использует кеш остаются, примерно такими же, кроме новых требований (т.е. ситууации когда возвращаются ItemState отличный от того который раньше кодировался булеаном и это важно в конкретном требовании).
Так же см разные паттерны у Шора. Например, использование signature shielding.
Еще можно сохранить совместимость с boolean либо просто добавив новый метод вместо переделки существующего, либо сделав imlicit cast к булеан. Последним, правда, я не пользовался, если у кого-то есть какой-то опыт, было бы интересно узнать.
Как раз для изоляции — фич друг от друга.
Коммиты бывают разные — например в процессе разработки фичи могут быть эксперименты, откаты на предыдущие версии, мердж с мастером и так далее.
Все это нужно до того момента, когда надо интегрировать фичу, после того как фича готова, это можно засквешить.
Делается squash merge и я вижу только один коммит. Если не хочется сквешить, то можно проребейзить перед мерджем и они будут рядом.
Чем больше объем мерджа тем больше разбираться что сломало CI, меньше гранулярность при черрипике, если надо будет, больше объем ревью и так далее.
Полфичи можно, но тут надо понять, чтобы не было неконситентного нового наблюдаемого поведения. Если его нет, то либо эти пол фичи можно выделить в фичу, либо будет мертвый код. Хотя, это, в принципе допустимо, многие так делают изолировав новое поведение фичетаглами.
Зачем ее тогда брать, после ревью может быть сильно изменена?
Я бы сказал, что это нетипичный случай.
Что значит фиг знает где? Он составляет историю мастера.
Я совершенно не против, чтобы там были и идентификаторы фич. Просто если их много удобнее видеть ссылку PR в целом и текстовый осмысленный коммент, если нужны детали можно открыть PR и ходить по ссылкам на фичи если их несколько.
Если она одна, наверное, иметь ссылку на PR чуть менее удобно, чем на фичу в джире на один дополнительный клик. Зато имея ссылку на PR можно посмотреть и дополнительные вещи (типа кто ревьюил и какие были замечания.)
У меня обычно наиболее гранулярные коммиты содержат атомарные правки типа "переименование метода", который мало кому интересны кроме меня, но я зато всегда могу откатиться на предыдущую версию в процессе работы над фичей, но там обычно нет ссылки на багу. На багу ссылается ветка в целом.
Потому, что вы можете работать, как вы сами говорили, над несколькими фичами, одна может быть готова отправке в мастер, другая не готова — тесты не дописаны, не компилируется, нет документации или какие там у вас характеристики проверяет билд еще.
Если она не вмерджена в мастер, значит не готова. Берите всегда из мастера. (Кроме того случая, когда вы работаете над долгоиграющей фичей — тогда берите из фичи, над которой работаете)
Приведите цитату плиз, я там услышал что им удобно репо на команду, а не ветку на разраба
Обычно он содержит ссылку на PR которую можно открыть и посмотреть все детали
Если они синхронизируются с мастером, то, по крайней мере, можно для работе в процессе понять какие изменения для какой фичи предназначены. Можно так же мерджить их в мастер пофично (всегда решить какую фичу вмерджить, а какую — нет). Для готовой работы есть уже мастер с его историей.
Так они его не засоряют. Обычно они живут пока фича разрабатывается и умирают после мерджа в мастер — причем, это автоматически происходит при завершении пулл реквеста. При следовании соглашениям о наименовании для бранчей типа feature/AddLoginDialog их можно не видеть, пока явно не захочешь, но зато, если захочешь можно увидеть.
Ок тут согласен — вполне допустимо в каких-то случаях создавать ветку на несколько связанных задач, если их удобнее сделать как одну.
Но вы-то предлагает ветку на разработчика — т.е. там должны быть вообще все зачачи разработчика даже логически не связанные или как?
Наверное тут какое-то недопонимание. Я подразумеваю, что ветки сливаются в какой-то момент в основную. Соответсвтенно, merge commit будет содержать описание и ссылку на задачу и можно будет посмотреть в истории по master.
История в фичебранчах как правило не нужна другим разработчикам, кроме того, случая, когда они совместно работают над долгоживущим бранчем. Но этот случай вообще непонятно, как решать в режиме "ветка на разработчика".
Ага, с моей точки зрения это не должно занимать сильно больше времени, чем написание данного коммента.
Что такое "правильно разбивать" и почему их невозможно разбить?
Что их заставляет так делать? Как они поступают когда одна задача готова, а другая — еще нет? Как потом в истории разобраться зачем именно было сделано конкретное изменение?
Давайте, переведу на русский — непонятно, куда девать комиты которые не связаны с задачами, либо задач нет либо они уже выполнены.
С моей точки зрения, все коммиты связаны с задачами, если у вас нет никакой задачи не создавайте коммит. Если у вас есть задача, оформите это в багтрекере. Если у вас коммит связан с закрытой задачей, значит в багтрекере вранье — либо задача не закрыта, либо это новая задача, связанная с данной.
Вы имеете ввиду что на одного разработчика ровно одна ветка? Или что ветка на фичу И разработчика?
Ссылка на forking workflow она про создание форков репы а не про ветки.
Если разработчик заводит ветку на инкремент (багу или новую фичу) то все плюсы, которые у вас упомянуты уже соблюдаются.
Разрабочик создает ветку, ассоциируюет ее с таксой в багтрекере — сразу видно кто занимается, после того как он закончил работу он делает пулл реквест и изменение попадает в мастер после ревью. В процессе работы он может мерджить свежий мастер не блокируется другими людьми.
Возможно, вам помогут идеи Джеймса Шора
Какое у вас тестовое покрытие? Как оно измерено?
Почти все идеи неуниверсальны. Это не значит, что их не надо поддерживать. Надо просто применять там, где это пододит.
Наверное здесь "локально" означает "в тестовой среде" она может быть нелокально, а в облаке, просто код в тестовом инстансе развернут из данного конкретного бранча. Судя по тексту, автор имел ввиду "я провел ручное End-To-End тестирование этого кода"