СММ-АК-2024. Стратегирование метода работы

Посты студентов Методология
1

Написан пост, в котором вы описываете стратегирование для метода работы, занимавшей максимальный процент времени вашей работы на прошлой неделе. В посте отмечено, как вы выполняли стратегирование для этой работы в жизни, а также приводится вариант стратегирования, который вы выполнили бы сейчас, с учётом знаний курса «Методология».

как я делал

Метод - разработка(подметод - разработка с помощью LLM моделей)
В моем случае нормального стратегирования, естественно, не было. Все было почти на уровне рефлексов.
Я уже не помню как точно узнал об этом методе, но было это где-то ± год-полтора назад. Когда github или выпустили или только объявили о запуске “github copilot” и повалили отзывы от людей, что вещь стоящая, реально помогает в работе и хорошо справляется с рутиной.
Посмотрел всякие ролики на ютубе - там у людей получалось быстрее какие-то вещи делать вот и я захотел попробовать. Попробовал, сначала не зашло, т.к. все было как-то топорно и код за меня он не писал; оказалось, что нужно уметь правильно давать команды-промпты, не во всех случаях он мог что-то толковое предложить. Поэтому было несколько итерация проб-отказов, но потом втянулся.
Сейчас LLM-based решение неотъемлимая часть моей практики разработки. За это время перепробовал кучу разных инструментов, на работе у нас есть корпоративная подписка на github copilot. Для личных использую cursor(claude 3.5).

делаем иначе с учетом знаний курса “Методология”

Во-первых разложить метод на составляющие:

  • понимание задачи
  • проектирование
  • собственно написание кода(я через TDD люблю)
  • тестирование(сюда же дописывание тестов, переделки и т.д.)
  • отладка/оптимизация(PR-review сюда же)
  • документирование
  • развертывание

Неплохо бы понять какой процент времени занимает каждое разложение и какой процент на каждом разложении может сэкономить copilot и если экономия маленькая, или изначально разлолжение занимает малый процент времени - нет смысла этим заморачиваться.

И тут вопрос: а как посчитать сколько времени на что ушло? Можно попробовать таймером это все на себе разметить.
Еще вариант - поискать в интернете, может уже были какие-то исследования на эту тему и можно взять данные оттуда(вряд ли мои результаты будут сильно отличаться?).
Думаю, что лучше всего будет найти какие-то результаты исследований на эти темы, а потом посмотреть что чего.

То что я нагуглил:

  • понимание задачи - 10-20%
    • тут цифры очень разнятся от стадии проекта и бизнес-домена, есть цифры до 50%(это совсем уж экстремальный случай и не каждый день такое происходит) но в основном это 10-20%
    • estimation - How much of your work day is spent coding? - Stack Overflow
  • проектирование - 10-20%
  • написание кода - 10-20%
  • тестирование - 10-50%
  • отладка/оптимизация ~10-30%
    • т.к. тут уже вовлекаются другие люди - неэффективный процесс может просто впустую сожрать очень много. Не раз в моей практике видел, что PRы зависают на неделю, а потом уже и контекста нет и все плохо
  • документирование <10%
    • тут обычно по остаточному принципу. Если не хватает времени на документацию - тем хуже для документации
  • развертывание ~1-10%
    • тоже все по разному, но в целом уже есть куча решений и инструментов для быстрого развертывания CI/CD пресловутый уже много где есть

То, что я тут посмотрел https://www.researchgate.net/publication/279259268_Software_Developers’_Perceptions_of_Productivity

Pasted image 20241017074553
Pasted image 20241017074553698×702 49.2 KB

У них вышло больше на написание кода чем я нагуглил, но это ничего

какие выводы

я бы сказал, что ориентироваться на эти цифры можно, но хорошо бы померить это все на себе, чтобы лучше понимать где “низковисящие плоды” есть. Например в моем случае - непосредственно написание кода занимает действительно мало времени, поэтому внедрить всякие копайлоты конечно хорошо, но если я начну тратить не 50 минут в день на написание, а 35-40(20-30% экономии) это конечно приятно, но как-то радикально ничего не улучшит. Но если программисты в моей команде тратят по 4 часа в день на написание кода, а будут по 2.8-3.2(те же 20-30% экономии) это уже существенно.

На что стоит обратить внимание при таком подходе - мы понимаем с чем работаем и работаем с важным, конкретно для нас. Ну по крайней мере у нас есть все инструменты для этого. Так можно конкретные улучшение привнести с минимальной ценой. В противовес моему подходу где я был подвержен маркетингу и понесся за хайпом(плохого, конечно не случилось, но могло бы быть намного лучше)

4 лайка
2

а это этапы или все-таки разложения? ) У меня теперь слова “этапы” и “стадии” стали красными флагами.
Вообще интересно не только время, затрачиваемое на работы по каждому методу, но и как качество работ по одним методам, влияют на взаимосвязанные работы по другим методам.

1 лайк
3

Разложения, конечно, спасибо, поправил

4

У вас там “понимание задачи” и “проектирование” без указания метода, я бы считал это сигнатурой. Скажем, event storm и DDD для этих сигнатур. А поскольку речь про business domain, то o1 Canvas может быть и получше.

Про TDD тоже есть много вариантов того, как это делать – сегодня TDD звучит для меня не как метод, а как сигнатура, которую очень по-разному можно разложить на составляющие.

Так что вы просто взяли аспект “использую не ручку-бумажку и не экранный редактор, а экранный редактор с подсказками” – но это один из аспектов метода, важный, но сегодня это как “гигиена”, все так делают. Вот то, что вы привели разложение на уровне сигнатур (скажем, TDD упомянуто) – это и есть разбирательство с методом. И то, что пытались определить, какая из этих работ занимала много времени (и поэтому можно ли её улучшить, заменив метод – не просто “использовав редактор с AI покруче”, а какие-нибудь принципы разработки. Скажем, event storm для понимания задачи – хотя event storm явно бледная тень от тех методов оргмоделирования, которые учат на нашем курсе).

1 лайк
5

С процентами на конкретные подметоды всё очень сложно) У меня сейчас в голове волнообразные пики на любом из них возможны. На раз два может застрять где угодно. При этом тестирование и отладку я не разделаю. Для меня тестирование это не у меня локально пара тестов проходят, а с бизнес данными функционал работает на стенде, как заявлено в фиче. Документирование входит в написание кода. Потому что если оно будет в конце, его никто не будет делать) Развертывание тоже ломается с какой-то периодичностью, не смотря на “кучу решений/инструментов”.

Здесь как раз интересная штука, что локальная оптимизация любого кусочка конвейера бессмысленна сама по себе. Окей, мы ускорили прогон CI на 10 минут, а задача на ревью лежит три дня или тестировщика ждёт неделю. Или разработчики стали писать код быстрее с помощью роботов, но проектирование по бизнесу как было кривое, так и осталось. Код пишется быстро, а потом выбрасывается. Сложно всё…

3 лайка
6

Разложение метода либо состоит в выделении практик разных системных уровней (то есть в анализе стека практик), либо в выявлении сильно взаимодействующих практик одного системного уровня (то есть когда hump diagram показывает множество одновременно реализуемых практик одного уровня). Если практики метода разделены во времени и выполняются не переплетённо, не взаимодействуют друг с другом - говорить про разбиение на этапы вполне правильно!

3 лайка
7

Интересно было бы посмотреть, какой стэк методов лежит за вашим программированием. Например, использование LLM - общая практика где-то внизу стека, а практики тестирования и документирования - выше, и обе опираются на LLM.

8

стэк - имеется в виду как с разложением плаванья/бега в предыдущих главах?

9

Да. Не практики одного уровня, а поддерживающие друг друга.

1 лайк
10

Имеется в виду, что это сигнатура неуказанного метода?

Т.е. имеется в виду, что TDD это сигнатура - как есть несколько разных реализаций TDD с одной и той же сигнатурой? Поэтому нельзя сказать, что я действую по TDD, нужно уточнять?

11

Тут наверно надо разбираться, что понимаем под TDD. Изначально TDD это практика/метод, который пришёл из extreme programming. Что этот метод означает? Означает он, что метод разработки ПО должен включать в себя написание тестов. Причём test-first development. И реализуется это через цикл red, green, refactoring. Пишем тест, он падает (кода то нет), пишем какой-то код пытаясь сделать тест зелёным. Написали какой-то код, тест позеленел, теперь надо из какого-то кода сделать нормальный (refactoring). Но это по книжке. Что мы имеем в реальности. В реальности работают две модификации TDD: 1) каноническая (test-first) 2) тесты пишутся во время/после написания кода. Но тесты должны быть обязательно. MR/PR без тестов не пройдёт code review.

Дальше возникают вариации с учётом на какой код мы пишем тесты:

  • новый функционал (тут всё как описано выше)
  • баг (должен быть добавлен тест на кейс, который этот баг вызывает)
  • рефакторинг какого-то кода (либо уже должны быть тесты на этот код, либо их придётся написать, мы себе не можем доверять)
  • легаси (просто код старый и без тестов, реанимация подразумевает, что тесты надо постепенно добавлять, мы так и разбираемся с кодом, и защищаемся)

Потом жили жили и вдруг поняли, что классическое TDD, где у нас AAA (arrange-act-assert) это не совсем похоже на жизнь. Я тестирую “утверждение”, вызов моей функции равно 3. Классно конечно, но это вполне может быть false positive, т.е. вовсе не означает что оно работает, как должно. И тут же люди поняли, что (достаточно) высокое тестовое покрытие это необходимое условие, но недостаточное для того, чтобы сказать что у нас качественно сделано. И появилось BDD (behavior-driven development), мы хотим тестировать не какие-то функции, мы хотим проверить поведение! Условно если объект ведёт себя как утка, то мы считаем что это утка. Но я по-честному видела, что это прижилось только в Ruby, и даже не только прижилось, а вытеснило тестирование утверждений. Фреймворк по умолчанию в Ruby on Rails это rspec, и это BDD фреймворк. Кое-как эти веяния просачиваются и в другие языки, но мы например продолжаем использовать TDD библиотеку (она дефолтная в языке).

Что я ещё не написала? TDD подразумевает, что мы говорим о unit testing. Т.е. о тестах, которые пишут разработчики внутри своего приложения. Тут могут появиться типы тестов по разному признаку. Например doctest (код написанный в описательной части перед кодом, автоматически становится тестом, если соблюдать нотацию), test (классический AAA, который лежит в папке с тестами, на которую автоматом натравлен фреймворк тестирования), property-based test (вариации теста, где мы одно “свойство” тестируем набором сгенерированных чуть отличающихся параметров, их много и они рандомные, мы себе сэкономили на придумывании граничных кейсов). Так же тесты можно различать по тому, какой слой кода они тестируют: тесты бизнес-логики (модулей, контекстов и т.д.), тесты контроллеров, тесты представлений. И это только backend, у фронтендеров будут свои примочки, типа тестирования скриншотами.

А если test-driven взять широко, как просто наличие стадии тестирования в процессе разработки. То окажется у нас целая пирамида тестирования и юнит тесты это только часть. А потом окажется, что в зависимости от архитектуры приложения, одни из стратегий тестирования можно реализовать, а другие уже нет. Например в монолитном приложении мне легко написать интеграционный тест, а в микросервисном нет.

4 лайка
12

Очень интересно, но понимание у меня на уровне “притянуть за уши”:

Похоже в целом на концепцию использования )

а это use case напомнило )

1 лайк
13

Тест это на самом деле тест-кейс, т.е. он по хорошему из use case и берётся/делается. Сценарий пользователя “я делаю вот такую штуку”, тестовый сценарий “я делаю вот такую штуку и в результате получаю вот это” (это классический TDD) или “я делаю вот такую штуку и происходят вот такие вещи/события” (BDD). Но там чем ниже уровень тем оно более программерское. Тесты контроллеров “я вызываю вот такой роут API, в ответ получают вот такие примерно данные”. Тесты запросов в БД “я делаю вот такой запрос, получаю вот такие данные из БД”. Тесты представления “Я получаю вот такие данные, представление их преобразует вот в такой формат, что-то убрано, что-то преобразовано”.

1 лайк
14

Ещё кстати забыла написать, есть фреймворки тестирования, которые позволяют писать тесты на естественном языке) На английском, даже на русском. Как раз хотели, чтобы некий бизнес кто-то (эксперт, аналитик), мог сформулировать как он понимает обычным текстом. Там он чуть форматированный текст, но в целом предложения это. Вот он пишет свой use case. Отдаёт разработчикам, а фреймворк позволяет на предложение на естественном языке привязать команды на языке программирования. Типа “я как работник склада(роль) получаю остатки по стульям красного цвета”, дальше мы такие “я работник склада” это будет “get_users.where(role: “warehouse_worker”)”. И т.п. И в итоге тест выполняет конкретный код, но отрабатывает по сценарию, который написал текстом не программист) Меня одно время очень вдохновляла эта идея.

Вообще большой вопрос в какой момент и с какой периодичностью надо пересматривать/выбирать методы, которыми работаешь. Наткнулась что там ещё что-то придумали и я уже видимо понятия путаю TDD vs BDD vs ATDD

1 лайк
15

Вот я тоже несколько раз был свидетелем как такой подход пробовали внедрять. По итогу все выходило плохо, в лучшем случае не-программисты пару раз тыкнут, а потом будут дергать программистов написать. В общем не синтаксис языка является препятствием

2 лайка