СММ-АК-2024. Методология как фундаментальный метод мышления

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

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

После курса вы должны понимать

  • как описывать разложение/составление метода
  • как дробить и составлять метод

Поглядим, пока не понятно, но я уже привык

Если не обучаться новым методам - теряешь конкурентоспособность. Для качественного обучения - нужно уметь сравнивать два метода

Хорошая и лаконичная мысль


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

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

Сигнатура это список параметров метода(входных и выходных)

Например сигнатура метода в кулинарии. (Готовим мы пиццу маргарита)::метод, сигнатура:

  • (готовая пицца)::(результат)
  • (тесто, сыр)::ингридиенты::параметры, (температура, время выпекания)::параметры
    Тут просто

Чуть сложнее. По какому методу я как разработчик действую? Разработки::метод
сигнатура

  • вход
    • требования/гипотезы/пожелания/ограничения внешних проектных ролей
    • умения/ограничения/пожелания внутренних проектных ролей
  • выход
    • работающее решение, удовлетворяющее потребности бизнеса

Вот есть сигнатура метода разработка. Как это может мне помочь? Ну например подойти с таким же вопросом к коллегам. И что я слышу?(“моя работа взять тикет из TODO и сделать так чтобы он оказался в DONE. Писать эти тикеты - не моя работа”: СММ-АК-2024. Графы создания). Получается он действует по методу с сигнатурой:

  • вход
    • тикеты TODO
  • выход
    • тикеты DONE

Тикеты меняют состояние, двигается альфа воплощения целевой системы? (вот тут вообще не уверен, плаваю в альфах)

Получается мы с ним действуем по разным методам, не смотря на то, что называем их одним и тем же и даже оргроль у нас одна и та же.
Ну а дальше есть уже пространство для действия: какой метод лучше/хуже/нужнее?
Может нам действительно нужны оргзвенья которые могут действовать по второму методу, а не по первому? Отличный вопрос.

Имеет смысл??

Еще мысль: “я хочу получить должность такую-то”, какая сигнатура у метода этой оргроли?

P.S> еще раз замечаю, насколько тесно переплетены в мозгу конструктивные и функциональные компоненты и как тяжело разделить их

2 лайка
2

Вот тут с программными продуктами надо очень аккуратно. Исходный код - это описание. Воплощение системы - это работающая программа в момент исполнения исходного кода.

Тикеты напрямую ничего не меняют вообще. Тикеты отмечают продвижение альфы описания. Альфу воплощения меняет выкатывание версии на прод.

1 лайк
3

Ага, альфа воплощения - это именно состояние “воплощения”, текущее состояние ЦС/Нашей системы. А тикеты не являются частью альфы, тикеты это какая-то документация к альфе воплощения?

4

Тикеты - это часть альфы описания. При этом помним, то само описание и альфа описания - разные вещи!

Тикеты, документы описания - это всё относится к альфе описания. Но тикеты не входят в состав описания системы, тикеты - это описание системы создания.

1 лайк
5

Можете подсказать, где в курсе Методологии почитать про сигнатуру метода в том смысле, что она описывает вход и выход метода ?

Нашел только то, что она состоит из метода и предмета метода.

Тогда этот пример

Например сигнатура метода в кулинарии. (Готовим мы пиццу маргарита)::метод, сигнатура:

  • (готовая пицца)::(результат)
  • (тесто, сыр)::ингридиенты::параметры, (температура, время выпекания)::параметры

Превратится в этот

  • Сигнатура 1: Готовим::метод пиццу::предмет метода
  • Сигнатура 1.1.: Раскатываем::метод тесто::предмет метода
  • Сигнатура 1.2.: Натираем::метод сыр::предмет метода
  • Сигнатура 1.3.: Выпекаем::метод заготовку пиццы::предмет метода
6

Нигде) Это сигнатура из языков программирования.

String.reverse(string)

Функция/метод reverse на вход принимает строку, и на выходе у него строка (но перевернутая). Так программистам обычно привычнее думать про сигнатуру.

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

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

7

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

8

А покажите хотя один пример описания тикета, где описан метод? Вот ни разу не видела, чтобы разработчику описывали, как ему делать его работу. Спецификации и ТЗ это не как, это что и форма.

9

Мой посыл в том что, разработчик - это роль. Роль определяется методом, а тикеты не ограничен только методами где необходима роль “разработчик”. Если в тикете указано что нужно, зайти ночью на сервер в такое-то время и проверь “все ли работает” (можно подставить конкретное описание), то это и есть описание работы (как единственного экземпляра метода). Но роль уже не “разработчик”, но очень легко может быть назначена члену команды “обычно” выполняющего работы по методам разработчика.

10

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

1 лайк
11

А можете дать ссылку на книгу или стандарт по которому можно почитать про “сигнатуру из языков программирования”? Например, Java это язык программирования и в его сигнатуры результат не включается, а включается только функция и параметры.

12

В статически типизированных языках было бы очень странно не указывать возвращаемый тип. Но и динамические языки какие то виды спецификаций уже поддерживают.

У нас вот так:

Functions
at(string, position)
@spec at(t(), integer()) :: grapheme() | nil

  • Имя функции: at
  • Типы параметров: String.t, integer
  • Возвращаемый тип: grapheme или nil

Returns the grapheme at the position of the given UTF-8 string. If position is greater than string length, then it returns nil.

Examples

String.at("elixir", 0)
"e"

String.at("elixir", 1)
"l"

String.at("elixir", 10)
nil

Вот ИИ отвечает, с моими знаниями не расходится:

В языках программирования сигнатура — это уникальная характеристика функции, метода или процедуры, которая определяет её имя, типы параметров и возвращаемое значение. Сигнатура помогает компилятору или интерпретатору идентифицировать и различать функции, особенно в случаях перегрузки функций или методов.

Основные элементы сигнатуры:

  1. Имя функции/метода — название, по которому вызывается функция.
  2. Типы параметров — типы аргументов, которые принимает функция. Порядок параметров также важен.
  3. Возвращаемый тип — тип значения, которое функция возвращает (если есть).

Примеры сигнатур в разных языках:

1. C++

int add(int a, int b);
  • Имя функции: add
  • Типы параметров: int, int
  • Возвращаемый тип: int

2. Python

def greet(name: str) -> str:
  • Имя функции: greet
  • Тип параметра: str
  • Возвращаемый тип: str

3. Java

public String concat(String s1, String s2);
  • Имя метода: concat
  • Типы параметров: String, String
  • Возвращаемый тип: String

4. JavaScript

function multiply(a, b) {
  return a * b;
}
  • Имя функции: multiply
  • Параметры: a, b (в JavaScript типы параметров не указываются в сигнатуре)
  • Возвращаемое значение: результат умножения (тип не указан явно).

Зачем нужна сигнатура?

  1. Перегрузка функций: в языках, поддерживающих перегрузку (например, C++, Java), сигнатура позволяет различать функции с одинаковыми именами, но разными параметрами.
  2. Контроль типов: сигнатура помогает компилятору или интерпретатору проверять корректность вызова функции.
  3. Документация: сигнатура делает код более понятным, так как сразу видно, какие параметры принимает функция и что она возвращает.

Исключения:

  • В некоторых языках (например, Python) сигнатура может быть менее строгой, так как типы параметров и возвращаемого значения не всегда указываются явно.
  • В функциональных языках (например, Haskell) сигнатура часто включает типы и может быть частью системы вывода типов.
13

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

А если продолжать историю с сигнатурами и аналогиями из программирования, то получается, что Ваш коллега написал функцию

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

Что мы с такими функциями в коде делаем? Дробим на отдельные смысловые части. Можно ли так же поступать с методами работы? Однозначно, можно.