Bear's Rambles | МЕДВЕДЬ ГОВОРИТ...

Сложные условия - верный путь в ад

Многострочные условия занимают прочное место в топе легальных издевательств над людьми, где-то сразу после «пенопластом по стеклу».

Давайте разберёмся как из чего-то ебанного типа (и это ещё не самый плохой пример

Если (ВажныеДанные = ПервоеЗначение
    ИЛИ ВажныеДанные = ВтороеЗначение
    ИЛИ ВажныеДанные = ТретьеЗначение
    //еще много значений
    ИЛИ ВажныеДанные = ЕщеОдноЗначение)
    И (ВажнаяДата >= ЗначениеВажнойДаты
    ИЛИ ВыполнятьВнеЗависимостиОтДаты)
    И СтатусВажныхДанных = ДействительныйСтатус
    И (ВажныеДанные.Свойство = ПервыйВариантСвойства
        ИЛИ ВажныеДанные.Свойство = ВторойВариантСвойства
        ИЛИ ВажныеДанные.Свойство = ТретийВариантСвойства) Тогда
    
    //какой-то код  
КонецЕсли;

сделать нечто удобоваримое.

Что нам может помочь?

Метод # 1. Объединение условий в переменные и/или методы

ЗначениеДанныхВыполняется = ВажныеДанныеНужногоЗначения(ВажныеДанные);
ДатаДанныхЗаебись = ВажныеДанныеПроверкаДаты(ВажныеДанные);
СтатусДанныхСоответствует = СтатусВажныхДанных = ДействительныйСтатус;
ДанныеОбладаютНужнымСвойством = СвойствоДанныхУдовлетворительно(ВажныеДанные);

Если ЗначениеДанныхВыполняется
    И ДатаДанныхЗаебись
    И СтатусДанныхСоответствует
    И ДанныеОбладаютНужнымСвойством Тогда

    //какой-то код
КонецЕсли;

Функция ВажныеДанныеНужногоЗначения(ВажныеДанные)
    Возврат ВажныеДанные = ПервоеЗначение
        ИЛИ ВажныеДанные = ВтороеЗначение
        ИЛИ ВажныеДанные = ТретьеЗначение
        //еще много значений
        ИЛИ ВажныеДанные = ЕщеОдноЗначение;
КонецФункции

Функция ВажныеДанныеПроверкаДаты(ВажныеДанные)
    Возврат ВыполнятьВнеЗависимостиОтДаты
        ИЛИ ВажныеДанные.ВажнаяДата >= ЗначениеВажнойДаты;
КонецФункции

Функция СвойствоДанныхУдовлетворительно(ВажныеДанные)
    Возврат ВажныеДанные.Свойство = ПервыйВариантСвойства
        ИЛИ ВажныеДанные.Свойство = ВторойВариантСвойства
        ИЛИ ВажныеДанные.Свойство = ТретийВариантСвойства;
КонецФункции

Или вообще засунуть все условия в один метод ВажныеДанныеПрошлиПроверки() - что в целом не очень информативно, потому что из тела основного метода не будет очевидно, какие именно проверки выполнялись

Метод # 2. При переборе строгих равенств использовать массив

ПодходящиеЗначения = Новый Массив;
ПодходящиеЗначения.Добавить(ПервоеЗначение);
ПодходящиеЗначения.Добавить(ВтороеЗначение);

ЗначениеДанныхВыполняется = ?(ПодходящиеЗначения.Найти(ВажныеДанные) = Неопределено, Ложь, Истина);

Метод # 3. Использовать логические функции

Операнды = Новый Массив;

Операнды.Добавить(ВажныеДанные = ПервоеЗначение);
Операнды.Добавить(ВажныеДанные = ВтороеЗначение);
Операнды.Добавить(ВажныеДанные = ЕщеОдноЗначение);
ЗначениеДанныхВыполняется = Коньюкция(Операнды);

Операнды.Очистить();

Операнды.Добавить(ВыполнятьВнеЗависимостиОтДаты);
Операнды.Добавить(ВажныеДанные.ВажнаяДата >= ЗначениеВажнойДаты);
ДатаДанныхЗаебись = Дизъюнкция(Операнды);

Операнды.Очистить();

Операнды.Добавить(ВажныхДанных.Свойство = ПервыйВариантСвойства);
Операнды.Добавить(ВажныхДанных.Свойство = ВторойВариантСвойства);
Операнды.Добавить(ВажныхДанных.Свойство = ТретийВариантСвойства);
ДанныеОбладаютНужнымСвойством = Дизъюнкция(Операнды);

Операнды.Очистить();

Операнды.Добавить(ВажныеДанныеНужногоЗначения);
Операнды.Добавить(ДатаДанныхЗаебись);
Операнды.Добавить(СтатусВажныхДанных = ДействительныйСтатус);
Операнды.Добавить(ДанныеОбладаютНужнымСвойством);

Если Коньюкция(Операнды) Тогда
    //какой-то код
КонецЕсли;

Функция Коньюкция(Операнды)
  Для Каждого Операнд Из Операнды Цикл
    Если Не Операнд Тогда
      Возврат Ложь;
    КонецЕсли;
  КонецЦикла;
  
  Возврат Истина;
КонецФункции

Функция Дизъюнкция(Операнды)
  Для Каждого Операнд Из Операнды Цикл
    Если Операнд Тогда
      Возврат Истина;
    КонецЕсли;
  КонецЦикла;
  
  Возврат Ложь;
КонецФункции

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

#медвежийкодстайл

Взгляд на ступени самосознания разработчика через полиморфизм.

Лирическое отступление.

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

Если попытаться просто описать полиморфизм и все его ответвления, то получится что-то типа «для многих проблем — одно решение».

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

Ступень первая. Частное.

Для решения задачи скорее всего родится какой-нибудь метод ВажныеДанныеПоЗначениюПараметра(ЗначениеПараметра). Выглядит вполне себе ок. Когда наступит момент и придёт понимание, что задача должна решаться и для нескольких объектов, родится метод ВажныеДанныеПоНесколькимЗначениям(МассивЗначенийПараметра). Вроде тоже ок. Как будто.

Ступень вторая. Обобщение.

Разработчик начинает задумываться, что вроде как оба метода решают одну задачу и было бы хорошо, чтобы метод всё-таки был один. И приходит к созданию некоторого метода-обёртки

Функция ВажныеДанные(Параметр)
  Если ТипЗнч(Параметр) = Тип("Массив") Тогда
    Результат = ВажныеДанныеПоНесколькимЗначениям(Параметр)
  Иначе
    Результат = ВажныеДанныеПоЗначниюПараметра(Параметр)
  КонеЦЕсли;

  Возврат Результат;
КонецФункции

Ступень третья. Приведение.

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

Функция ВажныеДанные(Параметр)
  ПараметрКакМассив = ПреобразоватьВМассив(Параметр);
  Результат = ВажныеДанныеПоНесколькимЗначениям(ПараметрКакМассив)
  Возврат Результат;
КонецФункции

Функция ПреобразоватьВМассив(Параметр)
//есть ОбщегоНазначенияКлиентСервер.ЗначениеВМассиве
//но для раскрытия примера лучше будет так
  Результат = Параметр;
  
  Если Не ТипЗнч(Параметр) = Тип("Массив") Тогда
    Результат = Новый Массив;
    Результат.Добавить(Параметр);
  КонеЦЕсли;
  
  Возврат Результат;
КонецФункции

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

Ступень четвертая. Понимание границ.

Это хорошо, когда разработчик задумывается о независимости и вариативности метода. Полиморфизм является основой для многих паттернов программирования.

Но не менее важно понимать, когда излишняя универсализация идёт во вред. Конкретно в этом примере — хорошо, когда результатом метода является одно исходящее значение, и логике, в целом, всё равно, на каком количестве входящих данных оно построено.

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

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

В нашем же случае, это может выглядеть примерно так

Функция ВажныеДанныеПоЗначениюПараметра(ЗначениеПараметра)
  Результат = ВажныеДанные(Параметр);
  Возврат Результат[ЗначениеПараметра];
КонецФункции

Функция ВажныеДанныеПоНесколькимЗначениям(МассивЗначенийПараметра)
  Результат = ВажныеДанные(МассивЗначенийПараметра);
  Возврат Результат;
КонецФункции

Функция ВажныеДанные(Параметр)
  ПараметрКакМассив = ПреобразоватьВМассив(Параметр);
  Результат = ВажныеДанныеПоНесколькимЗначениям(ПараметрКакМассив)
  Возврат Результат;
КонецФункции

Функция ПреобразоватьВМассив(Параметр)

  Результат = Параметр;
  
  Если Не ТипЗнч(Параметр) = Тип("Массив") Тогда
    Результат = Новый Массив;
    Результат.Добавить(Параметр);
  КонеЦЕсли;
  
  Возврат Результат;
КонецФункции

И это совсем не то, с чего мы начинали

#медвежийкодстайл

Штамм. Неприятные вампиры.

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

Штамм – это трилогия из книг «Начало», «Закат» и «Вечная ночь» (будете искать – ищите «Штамм. Название книги»), написанная Гильермо Дель Торо (сценарист и режиссер кучи хороших фильмов) и Чаком Хоганом – неплохим писателем, один из чьих романов точно превратился в хороший фильм («Город воров», если смотрели). Трилогия была экранизирована в виде сериала с таким же названием продолжительностью в четыре сезона.

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

Сериал сохраняет динамику, в нём нет звёзд первой величины, но при этом каст очень хороший – все актёры на своём месте, многие из них примелькались то тут, то там, мысль «где-то я его/её видел» при просмотре точно возникнет.

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

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

Собственно, о чём книги (ну и сериал, ясное дело тоже): про вампирский апокалипсис. Если бы у меня был художественный талант, я бы написал что-то в духе «авторы погружают нас в до жути реалистичную картину захвата власти в мире вампирами, если бы таковые взаправду существовали». Но, поскольку таланта во мне нет… Вампиры тут другие. Не вот эта вся пропаганда из сумерек и иже с ними, где они трахаются с едой и всё в таком духе. Вампиры тут очень неприятные. Как поведенчески, так и физиологически. Так что, если Вам не нравятся истории про злых вампиров – не читайте и не смотрите.

Мой вердикт.

Я не знаю по какой причине ни книги, ни сериал не зашли массовой аудитории, моя оценка - крепкие 8 из 10 и тому, и другому. Если вы еще этого не сделали, то смело читайте, смотрите чуть менее смело. Всё-таки ужасы.

Фото взято из открытых источников.

#медведьрекомендует #почитать #посмотреть

Первые 5 простых способов сделать метод лучше

Да-да, я в курсе, все пишут идеальный код и чё я вообще лезу со своим кодстайлом в эпоху, когда код пишут модели. Но мало ли, кому-то пригодится для «друга»

1️⃣Ранний возврат. У него есть кое-что общее с Маx: кто, что и сколько бы о нём ни говорил, используют всё равно ещё не все. Смысл в чём: если какой-то параметр критичен для выполнения метода, то явная его проверка на входе
➡️сокращает количество ненужных операций
➡️упрощает процесс поиска требований к данным

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

2️⃣Заключите контракт. Если метод что-то возвращает, сразу обозначьте это что-то. Можете даже назвать Результат – я вот часто так делаю. Присвойте Неопределено или пустое значение ожидаемого типа. Если результат метода – коллекция, сразу опишите коллекцию. Если это структура с важными для последующей обработки ключами: укажите эти ключи

Функция ВажныеДанные(ВажныеПараметры)
    Результат = Новый Структура();
    Результат.Вставить("ПервыйКлюч", Ложь);//показываем, что тип булево
    Результат.Вставить("ВторойКлюч", Справочники.Контрагенты.ПустаяСсылка());//показываем, что ссылка определенного типа
    Результат.Вставить("ТретийКлюч", Неопределено);//показываем, что может быть 
                                                    //составной тип
                                                    //произовольное значение 
                                                    //значние может быть не заполнено
                                                   //лучше указать, что именно

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

3️⃣Соблюдайте контракт. Не меняйте описанный результат: его тип или свойства (ключи, колонки и т.д.). Ибо грех и кары небесные.

4️⃣Явное получение необходимых данных. Если в рамках метода нужно что-то, кроме входящих параметров - позаботьтесь об этом сразу: обеспечьте прозрачность используемой информации. А ещё может быть полезно для оптимизации

//Пример (простой)

Для Каждого СтрокаТаблицы из ТабличнаяЧасть Цикл
    //какой-то код
    ОченьНужныеДанные = ОбщегоНазначения.ЗначениеРеквизитаОбъекта(СтрокаТаблицы.Свойство, "ИмяРеквизита");
    //какой-то код
КонецЦикла;

Из хорошего о разработчике, написавшем этот код:
➡️не обращается через точку к реквизиту - знает, что фу-фу-фу, западло и мама не велит
➡️шарит за БСПшную функцию для получения реквизита
Из плохого:
➡️не в курсе, что внутри БСПшной функции - запрос, и ебашит его в цикле
➡️в целом пох на то, как будет читаться его код – получение нужных данных может быть спрятано очень искусно в нагромождениях чего попало или в другом методе

Вердикт: ебанно❌ А вот так – лучше👍

МассивСсылок = ОбщегоНазначенияКлиентСервер.СвернутьМассив(ТабличнаяЧасть.ВыгрузитьКолонку("Свойство")); 
ОченьНужныеДанные = ОбщегоНазначения.ЗначениеРеквизитаОбъектов(МассивСсылок, "ИмяРеквизита");
Для Каждого СтрокаТаблицы из ТабличнаяЧасть Цикл
    //какой-то код
    ОченьНужныеДанныеПоСтроке = ОченьНужныеДанные[СтрокаТаблицы.Свойство];
    //какой-то код
КонецЦикла;

И вот уже сразу понятно, какие дополнительные данные нужны внутри метода, и даже код оптимизирован

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

5️⃣Чем меньше возвратов - тем лучше. В идеальном методе после раннего возврата существует только один – в последней строке исполняемого кода.

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

#медвежийкодстайл

Ненавижу, бл🤬ть, каскады

В мире разработчиков ходят легенды, что рабочее тело каждого метода, за редким исключением, можно уместить в один экран. Мало кто пробовал, еще у меньшего количества это получалось. У единиц - сделать при этом методы ЧИТАЕМЫМИ. Это так, чтобы человеку не требовался весь жизненный опыт всех разработчиков, приложивших руку к методу, чтобы в нём разобраться.

Обеспечивается это много чем - от хороших имён (переменных - это когда понятно, что в ней хранится, и методов - это когда понятно, что выполняется, а главное, контракт того, что выполняется ТОЛЬКО ЭТО) до контроля цикломатической сложности (а вы, кстати, знали, что это - минимальное количество тестов, необходимых для покрытия всего пути?)

Но сегодня про одну из самых бесячих, лично для меня, вещей - if-каскады. Это когда через бесконечную переборку условий выполняются какие-то действия.

Думаю, каждый встречал хоть раз в жизни что-то вот такое:

Процедура ВажныеДействияСВажнойСущностью(ВажнаяСущность)
  Если ВажнаяСущность = ПервоеЗначение Тогда
    //какой-то
    //исполняемый
    //код
  ИначеЕсли ВажнаяСущность = ВтороеЗначение Тогда
    //ещё
    //исполняемый
    //код
  ИначеЕсли ВажнаяСущность = ТретьеЗначение Тогда
    //дохрена
    //исполняемого
    //кода
  //еще
  //очень
  //дохрена
  //переборов
  //важных
  //значений
  Иначе
    //а может и не быть
  КонецЕсли;
КонецПроцедуры

Делать так - ебанно❌!

А вот так - хорошо👍

Процедура ВажныеДействияСВажнойСущностью(ВажнаяСущность)
  ТекстИсключения = ТекстВажныеДействияНеОписаны();
  
  ИмяМетода = ИсполняемыеМетоды()[ВажнаяСущность];
  Если Не ЗначениеЗаполнено(ИмяМетода) Тогда
    ВызватьИсключение ТекстИсключения;
  КонецЕсли;
  
  ПараметрыМетода = ПараметрыДляМетодов(ВажнаяСущность)[ИмяМетода];
  Если ПараметрыМетода = Неопределено Тогда
    ВызватьИсключение ТекстИсключения;
  КонецЕсли;
  
  ОбщегоНазначения.ВыполнитьМетодКонфигурации(ИмяМетода, ПараметрыМетода);
КонецПроцедуры

Функция ИсполняемыеМетоды()
  Результат = Новый Соответствие;
  
  Результат.Вставить(ПервоеЗначение, "ИмяПервогоМетода");
  Результат.Вставить(ВтороеЗначение, "ИмяВторогоМетода");
  //еще сколько надо пар КлючЗначение
  
  Возврат Результат;  
КонецФункции

Функция ПараметрыДляМетодов(ВажнаяСущность)
  Результат = Новый Соответствие;
  
  Результат.Вставить("ИмяПервогоМетода", ПараметрыПервогоМетода(ВажнаяСущность));
  //еще сколько надо пар КлючЗначение
  
  Возврат Результат;
КонецФункции

Процедура ИмяПервогоМетода(Параметры) Экспорт
  //какой-то исполняемый код
КонецПроцедуры

Процедура ИмяВторогоМетода(Параметры) Экспорт
  //какой-то исполняемый код
КонецПроцедуры

Функция ПараметрыПервогоМетода(ВажнаяСущность)

  Результат = Новый Структура;

  Результат.Вставить("Параметр1", ВажнаяСущность.Свойство1);
  Результат.Вставить("Параметр2", ВажнаяСущность.Свойство2);

  Возврат Результат;
КонецФункции

Функция ТекстВажныеДействияНеОписаны()
  Возврат НСтр("ru = 'Ваш разработчик не предусмотрел выполнение сценария.
        |Свяжитесь с его начальником, он даст ему просраться'");
КонецФункции

Результат этого подхода
➡️повышается читаемость метода
➡️упрощается расширение
➡️упрощается изменение
➡️появляется возможность разделить ответственность (если ВажнаяСущность может быть различными объектами, то перенести исполняемые методы в соответствующие модули)

ОбщегоНазначения.ВыполнитьМетодКонфигурации - это обёртка безопасного выполнения кода из БСП
ОбщегоНазначения.ВыполнитьМетодОбъекта - это вариант, если требуется выполнение метода, описанного в модуле конкретного объекта

Отдельная функция ПараметрыДляМетодов() - это усложнение на случай, если Вам требуются разные параметры для каждого случая, чаще это не так и можно обойтись без неё.

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

#медвежийкодстайл

(Не)чистый код.

Как и обещал, для начала немного теории.

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

И собрал я джунов своих, И увидел я код их,
И пиздил оных за ошибки, совершенные ими.
И передал им паттерны свои.
И сказал я: это хорошо

Книга Дядюшки Боба 1.01.01

🔴В АБЗАЦЕ НИЖЕ ЕСТЬ ДОЛЯ ШУТКИ🔴

Вообще, не «чистый код» - не такая уж проблема, если подумать. Знаете, почему Мартин выбрал прилагательное «чистый», а не «правильный»? Да потому что «грязный» код – тоже будет работать, и вполне себе правильно.

Чистый код – это прежде всего легко читаемый, изменяемый и масштабируемый код. Нечистый код тоже может быть оптимальным с точки зрения выполнения своей прямой функции. Но при этом разобраться в нём, не говоря уж про какое-то сопровождение будет очень тяжело.

За чистоту кода отвечают, преимущественно, 3 философских принципа, которыми неплохо руководствоваться и в жизни

👉KISS – Keep It Simple Stupid – призывает нас не быть сложнее, чем необходимо. Один метод – одна задача. Небольшие методы. Логичные имена переменных. Переиспользование. Всё это берёт начало с каких-то дремучих годов, а сам акроним был придуман проектировщиком военных самолетов из Lockheed.
👉BDUF – Big Design Up Front – известное всем русскоязычным людям с детства как «Семь раз отмерь - один раз отрежь». Думаю, даже пояснять не надо.
👉YAGNI – You Aren’t Gonna Need It – А оно тебе точно, бля@ть, надо? И самой близкой аналогией здесь будет бритва Оккама. Главное, не применяйте его слишком широко, а то можно задуматься, а нужна ли Вам вообще работа, семья…

Помимо этих, есть еще прямо или косвенно следующие из предыдущих принципы

👉DRY – Don’t Repeat Yourself – про недопустимость дублирования кода с одинаковой функциональностью
👉GIGO – Garbage In Garbage Out – про требования к валидации входящих данных. Да-да, это именно та история, когда мы, работая, к примеру, с персданными сотрудников должны проверять дату рождения (неплохо было бы, ограничивать её хотя бы XIX веком снизу и текущей датой сверху)
👉LIAR – Leave, Its Already Ready – Отъебись, и без тебя работает. В целом понятно, что имеется в виду: не стоит переделывать что-либо, с чем ты не согласен до конца, если не знаешь точно, нахрена оно сделано именно так.

Венцом всего это считается сугубо практический принцип проектирования – да, именно он – SOLID, что тоже является аббревиатурой

➡️S – Single – принцип единственной ответственности. То самое «один метод/класс – одна задача»
➡️O – Open/Close – открытость для расширения, но закрытость для модификации (расширять функционал можно, изменять контракт входящих/исходящих данных нельзя)
➡️L – принцип подстановки Барбары Лисков – про полиморфизм и наследование
➡️I – требование к специализации интерфейсов, хороший интерфейс – узконаправленно решающий определенную задачу, плохой интерфейс – принуждающий посетить группу анонимных наркоманов при бронировании поездки на Марс. Для не разработчиков, интерфейс – это не только куда тыкать, это еще и место взаимодействия между частями системы.
➡️D – Dependency – про вертикальные зависимости (более высокоуровневый модуль не должен зависеть от более низкоуровневого для 1Сников – не допускается вызов из модуля менеджера метода из модуля формы), уменьшение связности, увеличение гибкости и отграничивание от несущественного.

Практическим результатом влияния всего этого на код являются уже паттерны программирования – всякие фабрики, наблюдатели, стратегии и прочая… Но главное – если Вы будете следовать этим принципам – Вы интуитивно будете применять паттерны, даже не зная их.

Если подход к чистому коду основан на определенных принципах, то подход к «грязному» - исключительно на человеческой лени и тупости. И поэтому имя им – легион. Всеми любимые спагетти, пиццы, равиоли, говнокод, китайский код и еще куча различных моделей. Погружаться я в них не особо хочу – все-таки рука уже соскальзывает с воображаемой границы сообщения. Да и зачем? Вы всё это умеете и без моих объяснений.

#медвежийкодстайл

Анонс.

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

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

Аналитик + Разработчик. Итог.

⭐️Первая очевидная вещь

Единственная выполняемая разработчиком функция: реализация требований заказчика в ПО.

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

⭐️Вторая очевидная вещь

Единственная выполняемая аналитиком функция: реализация требований заказчика в ПО.

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

⭐️Главная идея: степень взаимодействия должна зависеть от жизненного цикла, на котором находится продукт⭐️

Для задач разработки и развития – степень взаимодействия должна быть максимальной.

👉Привлечение разработчика к сбору и анализу требований позволит на ранних этапах
➡️сформулировать ограничения – накладываемые выбранным стеком разработки, ресурсами и конфликтами с существующими реализациями
➡️заложить точки вариации – по сути, начать работу с бэклогом уже на стадии проектирования системы.

👉Привлечение аналитика к разработке архитектуры позволит заложить у него понимание структуры и даст в дальнейшем возможность сократить участие разработчиков в проработке задач в других жизненных циклах проекта.

Подобный подход потребует двух сильных специалистов, но ведь на самом деле, никто не планирует разработку серьезной функциональности парой джунов, так?

Разграничивать ответственность на данном этапе максимально неэффективно – как минимум, это ведет к увеличению количества итераций «всё хуйня, переделывай», а как максимум – к ошибкам в проектировании.

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

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

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

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

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

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

#медведьразмышляет #рольаналитика

Нормальная структура команды. Набор рекомендаций.

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

Логическое упущение.

Я не буду говорить про QA и DevOps – не очень умещается в контекст взаимодействия аналитика и разработчика.

Небольшое лирическое отступление.

Жизненный цикл продукта выглядит следующим образом
🔘Разработка – сбор требований, описание бизнес-процессов, проектирование, реализация
🔘Внедрение – установка, настройка, импорт данных, обучение персонала, ввод в эксплуатацию
🔘Развитие – масштабирование, добавление нового функционала
🔘Сопровождение – модификация системы после передачи в эксплуатацию, обусловленная возникающими потребностями или проблемами, проактивная деятельность по мониторингу возникающих угроз, как технических, так и на уровне бизнес-процессов.
🔘Поддержка – реакция на инциденты, выполнение действия по восстановлению работоспособности системы.

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

Для начала необходимо понять, за счет чего можно достичь главную цель команды разработки – эффективность
👉Гибкость – способность быстро подстраиваться под изменяющиеся условия.
👉Коммуникация – взаимодействие, позволяющее обмениваться знанием, опытом, что приводит к взаимному росту и сокращает время погружения в задачи
👉Ответственность – понимание конечных целей, своей роли в достижении этих целей

Ответственность начинается с головы – поэтому хотя бы в рамках стека разработки (примитивно: 1С, не1С, мобильная разработка) во главе стоит один человек. Его функция – получать ответственность (и пиздюлей) и раздавать её (желательно без пиздюлей). Это на самом деле то, что встречается очень часто.

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

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

Если РП нет – то с ролью, по сути, владельца продукта отлично справляются аналитики. Причем в более широком понимании продукта как «ценности» - мы можем спуститься до конкретных бизнес-процессов, когда один аналитик полностью погружен в их ограниченное количество, а не пытается залезть во все сразу.

Одна из функций тимлида по функциональному центру – направлять ДОСТАТОЧНЫЕ ресурсы. Не по принципу «год назад Ваня запилил нам охрененную систему, поэтому пусть он добавит в неё 3 строчки кода». А именно выделять того специалиста, чьей квалификации в определенном направлении будет хватать для решения определенной задачи.

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

Финансовая составляющая может внести свои корректировки: если применяется модель финансирования по центрам затрат, то ничего не поделаешь.

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

#медведьразмышляет #управление

Интерактив, ёпта!

Есть два варианта кода, выполняют одно и тоже, один с явной логикой, второй нет. Какой стул выберешь?

Функция ОпределениеВажныхДанных(ТожеВажныеДанные, СоответствиеМеждуВажнымиДанными)
  ТаковПуть = ВажныеДанныеЧерезМарапупу();//булево
  
  Если ТаковПуть Тогда
    ВажныеДанные = СоответствиеМеждуВажнымиДанными[ТожеВажныеДанные];
    Если Не ЗначениеЗаполнено(ВажныеДанные) Тогда
      ВажныеДанные = ТожеВажныеДанные;
    КонецЕсли;
  Иначе
    ВажныеДанные = ТожеВажныеДанные;
  КонецЕсли;
  
  Возврат ВажныеДанные;
КонецФункции

Функция ОпределениеВажныхДанных(ТожеВажныеДанные, СоответствиеМеждуВажнымиДанными)
  ТаковПуть = ВажныеДанныеЧерезМарапупу();//булево
  ВажныеДанные = Неопределено;
  
  Если ТаковПуть Тогда
    ВажныеДанные = СоответствиеМеждуВажнымиДанными[ТожеВажныеДанные];
  КонецЕсли;
  Если Не ЗначениеЗаполнено(ВажныеДанные) Тогда
    ВажныеДанные = ТожеВажныеДанные;
  КонецЕсли;
  
  Возврат ВажныеДанные;
КонецФункции

#всратыеопросыотмедведя

Channel name was changed to «Bear's Rambles | МЕДВЕДЬ ГОВОРИТ...»

Немного о TTOP. Часть III. Что с этим не так? Продолжение

👉Ну и как вишенка на небольшом таком торте недостатков – стабильные команды.

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

Но чуете, чем повеяло? Ага, именно им – болотцем.

Обратная сторона всего этого – команда мыслит всё более и более одинаково, и всё меньше и меньше остается места разнообразию решений и применению каких-либо инноваций.

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

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

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

Да, я писал – изначально следующий текст планировался, как финальный в качестве объединения нескольких тем. Его пришлось в каких-то смыслах упрощать, в каких-то, наоборот, усложнять, в том числе и такими вот постами с контекстом – потому что важные моменты не были проговорены заранее. Но вышло, как вышло: захотелось мне ускориться через конкретную тему. Её и закроем. А дальше буду думать, что делать с поломанным планом.

А озвучки не будет. В Google поменяли что-то в проверке доступности и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень

#медведьразмышляет #управление #ttop

Немного о TTOP. Часть III. Что с этим не так? Начало

Ну, в целом - если прищуриться и скрестить пальцы в кармане – всё так. Реально, очень хорошая штука. Без шуток. Как готовая модель управления – идеальна, насколько вообще может быть идеальна готовая модель управления.

Но по порядку.

👉Первое, что напрочь игнорируют люди при натягивании TTOP на какой-нибудь сферический предмет – область применения. То, что я написал в самом начале

Team Topologies это методология построения командной работы, ставящая во главу угла БЫСТРОЕ ДОСТИЖЕНИЕ РЕЗУЛЬТАТА

Прямо на обложке одной из двух основополагающих книг методики достаточно внятным шрифтом написано «organizing business and technology teams for fast flow». FAST, БЛЯТЬ, FLOW. Флоу само по себе во всей этой теории воспринимается с примесью не только поставки, но и скорости. А тут еще и фаст.

Короче, Вы поняли: главное – скорость. А теперь давайте подумаем, когда важна скорость? Даже так: СКОРОСТЬ. Первое, что приходит на ум: необходимо пофиксить баги. Выпустить патчи. Еще когда?...

Знаете, скорость в целом никогда не была главной проблемой при разработке. Сейчас, с увеличением роли ИИ, станет еще меньшей.

Надо пояснить? Ну ок.

➡️Смотрите, сколько реально новых фич способен клиент ввести в свой «рацион»? и в какой промежуток времени? Реально ли больше, чем команда способна произвести? А если выкинуть «мусорные» фичи, типа «давайте ебанем на кнопки вместо томатно-красного бисмарк-фуриозо»? Это первый аспект.

➡️Второй аспект в скорости – это возникновение бэклога, но уже на стороне клиента, когда у него накапливаются изменения, которые он еще не использовал. По итогу вы растягиваете «время до оценки» на неопределенный, возможно даже, бесконечный срок.

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

Так что, если у Вас нет необходимости в fast flow – начните думать по-другому. Не как натянуть сову на глобус, а как взять от этой совы что-то, что будет реально полезно в конкретной ситуации. А то и сову порвёте, и головой крутить на 360 не сможете. Я периодически говорю об этом по разным поводам. Теория – это хорошо. Но её необходимо анализировать перед применением.

👉Второе, что сразу бросается в глаза – в TTOP остается очень много серых зон, которые регламентируются «самосознанием» команд. Этаким коллективным бессознательным, которое должно управлять адаптивностью команд.

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

Так что бросьте. TTOP – вообще не про гибкость и адаптацию. Более того, TTOP тут само себе противоречит, с одной стороны призывая к адпативности, с другой - настаивая на том, что лучшее, что может случится с Вашей компанией - долгоиграющая команда. Я утрирую, там есть поползновения в сторону золотой середины, но кого это ебёт.

👉Отсюда мы получаем очередную границу применимости TTOP – финансы. Беда всех проектных кроссплатформенных команд: они очень неохотно делятся кадрами. А если у вас в них занято подавляющее большинство сотрудников, то оптимизация их использования при низкой адаптивности будет минимальной. Именно поэтому столь впечатляющий список гигантов, использующих подход Team Topologies, и столь плохо модель применима в варианте «как есть» на чём-то более мелком.

А озвучки не будет. В Google поменяли что-то в проверке доступности и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень

#медведьразмышляет #управление #ttop

Немного о TTOP. Часть II. Про что это? Продолжение

Практические нотации.

Два главных паттерна, а скорее даже вывода TTOP: типы команд и виды взаимодействий.

Тут я ввиду отсутствия устоявшегося русскоязычного аналога приведу и англоязычные оригиналы.

Типы команд

👉Stream-aligned team – команда, ориентированная на поток – по сути это кросс-функциональная команда, заточенная на постоянную работу непосредственно над «ценностью».

В TTOP используется слово «value» в смысле чего-то, что имеет значение для конечного пользователя. При этом у этих ценностей существует иерархия – логично подразумевается, что одна команда в размере 5-9 человек не может целиком отвечать за какой-нибудь большой продукт, поэтому воспринимать «ценность» следует, скорее, как некую функциональность, службу, делить которую на какие-то части не имеет смысла либо в виду потери связанности, либо в виду того, что команда вменяемого размера способна справиться с ней самостоятельно.

Предполагается, что этот тип – базовый в компании, их число может достигать 80% от всех команд разработки. Собственно, главные особенности таких команд – минимальные горизонтальные зависимости от остальных и end-to-end ответственность за продукт.

👉Enabling team – команда-помощник. Пожалуй, самый размытый типаж. Некоторые люди вообще понимают эти команды как некоторое подобие наполеоновской гвардии, которая приходит в отчаянный момент и всех спасает.

На самом деле – это более широкое понятие, скорее про в целом оценить необходимое воздействие, возможно обучить базовым навыкам. Своеобразный менторинг. Команда не обязательно должна быть постоянно в статусе «enabling» - это может быть команда другого типа, которая обладает требуемыми навыками, предположим, потоковой команды – таким образом, это скорее уже описание взаимодействия, чем типа команды. Главное – это взаимодействие должно носить временный характер.

👉Complicated subsystem team – команда сложных подсистем. Отвечают за разработку механизмов, которые будут использоваться другими командами по библиотечному принципу. К примеру, распознавание лиц.

👉Platform team – команда инструмента. Кажется, что это очень похоже на предыдущий тип, но нет. Я осознанно заменил «платформу» на инструмент, чтобы было понятнее, что имеется в виду. «Platform» тут скорее говорит о большем масштабе, чем «subsystem». Большей трудоёмкости, необходимости постоянной поддержки и совершенствования.

Это команды, разрабатывающие и сопровождающие «ценности», но не для клиента, а для других команд. Типа разнообразных бэкстейдж-инструментов, готовых сред разработки, пайплайнов, инструментов мониторинга.

Режимы взаимодействия.

👉Collaboration – тесное взаимодействие. Две команды работают вместе для решения общей задачи.

Сотрудничество в таком формате подразумевается только с одной командой в один момент времени ввиду высоких накладных расходов. По этой же причине рассматривается исключительно как временная мера, которая имеет возможность перерасти во взаимодействие X-as-a-Service.

👉X-as-a-Service – использование результата деятельности другой команды, как сервис, некий «чёрный ящик», с известными входными и выходными параметрами, без непосредственного взаимодействия с разработчиками.

По сути, это использование результата деятельности команд сложных подсистем или инструментов. Или взаимодействие между ячейками микросервисной архитектуры.

👉Facilitating – помощь. Одна команда помогает другой в рамках решения общей задачи. Да-да, это именно про взаимодействие с enabling team. Чтобы не повторяться – вернитесь и прочтите, если не помните.

Вот в целом и всё. И как я уже говорил – вроде всё по делу. И, как я уже говорил – есть «но». Я дам немного времени Вам отдохнуть и даже может быть самим подумать, что не так с TTOP. Даже скорее, где и почему TTOP теряет свою охуенность.

А озвучки не будет. В Google поменяли что-то в проверке региона и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень

#медведьразмышляет #управление #ttop

Немного о TTOP. Часть II. Про что это? Начало

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

Принципы, требующие реализации, и паттерны, реализующие принципы.

Подход TTOP опирается на набор из нескольких принципов, которые и отвечают за «быструю доставку ценностей»

1️⃣ Самый базовый. Сосредоточенность на потоке. Поток – это скорость, с которой из идеи получается конечный результат. Все остальное, в том числе организационная структура, важно лишь в том случае, если она помогает ускорить поток.

2️⃣Доверие должно быть фундаментом. Излишний контроль порождает избыточность документации и неэффективных процедур, замедляющих работу.

3️⃣Стабилизируйте команды. В командах, которые работают вместе годами, формируется общее понимание задач и модели коммуникации, ускоряющие выполнение задач.

4️⃣Изменения должны быть небольшими и безопасными. Как в продукте, так и в работе команды. Цель в постоянном повышении качества продукта небольшими и безопасными шагами, а не редкими и огромными обновлениями, которые могут провалиться.

5️⃣Не раздувайте нагрузку. Каждая команда должна чётко понимать границы ответственности, а при постоянном их расширении даже компетентные команды становятся неэффективными. Более того, перегруженная команда не имеет собственного видения развития продукта, она лишь реагирует на возникающие «угрозы». Оставляйте время на эксперименты – они проводят к прорыву в развитии продукта.

6️⃣ Откажитесь от идеального планирования. Невозможно продумать всё заранее, проектируйте системы, отталкиваясь от адаптивности.

7️⃣Главный враг производительности – ожидание одной команды другой. Устраните зависимости между командами.

8️⃣Исключайте испорченный телефон: команды должны общаться напрямую с клиентами (пользователями, заказчиками). Доверяйте своим людям (пункт 2), чтобы они правильно понимали и интерпретировали нужды клиентов. Наличие необязательных промежуточных звеньев, во-первых, противоречит первому закону робототехники сосредоточенности на потоке, во-вторых, может привести к искажению изначальной идеи, когда она пройдет корпоративный ад согласований.

Согласитесь, набор принципов – очень здравый. Достигать их предполагается с помощью некоторых паттернов управления

👉Непрерывная адаптация команд. Ответственности и структурная. Вместе с изменением продукта или технологий меняются и команды. Эти изменения происходят оперативно, небольшими порциями, не накапливая организационный долг. Главное – делают это естественно. В идеале команды сами договариваются об изменениях, без реструктуризации сверху.

👉Упрощение используемых инструментов. Хороший инструмент должен предоставлять ровно необходимый набор возможностей, не создавая дополнительных зависимостей.

А озвучки не будет. В Google поменяли что-то в проверке региона и теперь их aistudio мне недоступна даже через три весёлых буквы. Пока разбираться лень

#медведьразмышляет #управление #ttop

Такая только у меня и у Майкла Джордана. Как создать команду мечты?

Часть II. Немного о TTOP. Часть I. Что это?

Да-да, внимательный читатель, ты не ошибся – эта часть будет разбита еще на части🤦🏻‍♂️ Эта – контекст к контексту😂

Team Topologies это методология построения командной работы, ставящая во главу угла быстрое достижение результата. Звучит вкусно. И на самом деле толково. Но всегда есть «но», до которого тоже дойдём.

Вообще, у Team Topologies есть свой сайт, на котором Вы можете оставить заявку – и за какую-то большую мзду к Вам придут специально обученные люди и скажут, что с Вами не так. Есть две книги (одна даже пережила повторное издание), за авторством главных «рупоров» методики: Мэтью Скелтона и Мануэля Паиса. Кстати, не переведенные на русский язык.

Список компаний, который используют TTOP впечатляющий: тут и классические ИТ-гиганты разработки ПО (мелкомягкие, красношляпочные, SAP, аттласиан), онлайн-гиганты (Amazon, Netflix, Spotify), крупные банки (морган), крупные опсосы (T-mobile, Vodafone) и куча-куча всего еще, даже docker. Так что в целом, похоже на то, что стоит разобраться поподробнее, чтобы понять, что мы, ребята поменьше, можем утащить к себе.

Почему всё-таки TTOP удостоилась отдельных постов? Ну, штука-то на самом деле хорошая. С сохранением базовых принципов достаточно легко натягивающаяся на широкий круг команд.

Но при этом, если Вы поищите чего-то в рунете, то примерно 90% того, что Вы найдёте – сосредотачивается только лишь на типах предлагаемых в рамках концепции команд и их взаимодействий. Но если зацикливаться только на этом, без понимания общей картины – сама методология будет применима только к сильно ограниченному кругу компаний.

Эти типы – одно из следствий общего подхода, не понимая которого, нельзя понять нахрена оно всё.

Собственно, разбор самой TTOP и моё мнение о границах применимости будут завтра, двумя (вроде помещается) отдельными постами – с утра и в обед.

#медведьразмышляет #управление #ttop

Анонс. СППР, но с блекджеком и шлюхами

Предыстория.

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

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

И вот этот день настал — на прошедших выходных мы смогли встретиться и собрать требования (с меня).

Начну с впечатлений.

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

В чём вообще плюс начинать пет с кем-то? Всё банально: одна голова хорошо, а две — хорошо-хорошо. Роман здорово провёл "первичный опрос заказчика" и неплохо раскрутил развитие продукта. Какие-то вещи были в голове изначально, на какие-то вывел он. Предложил конкретные технологии, которые можно использовать в решении. Да и просто очень приятно, когда закрыть твою хотелку вписывается человек, с хорошим опытом и с которым оказываешься на одной волне.

Теперь подробнее на тему "что это будет?"

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

Толком функционала СППР не знаем ни я, ни он. Кстати, если у кого-то есть свежий релиз или хороший видео-обзор актуального СППР - скиньте в сообщения канала или комментарии, чисто посмотреть ради

Кратко по функционалу, который мы себе придумали и постараемся реализовать

👉Структурированное логирование задач по разработке в привязке к объектам метаданных и событиям, в рамках которых они выполняются
👉Построение графов связей и зависимостей между задачами и метаданными
👉Поиск похожих задач для использования и масштабирования уже имеющихся решений
👉Подключение ИИ для итоговой постановки ТЗ на разработку (для обратного процесса: когда задача начинается свой путь из нашей системы, а не вносится существующее решение)
👉Интеграции с уже используемыми трекинг-системами задач (к примеру, jira или еще какая похожая ебула)
👉Веб-морда с использованием технологии 1С:Элемент

И что теперь? ну поговорили Вы и поговорили...

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

Определим MVP. И какие-то вменяемые сроки. Думаю, в районе полугода. У обоих есть работа. Помимо, у меня другие проекты, а у Романа ещё и прокачка персонажа в реальной жизни (ребёнка то есть).

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

Будет ли это решение доступно для кого-то, кроме меня и Романа?

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

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

P.S. И тэг придумать надо. И название. Дохуя работы еще.

Такая только у меня и у Майкла Джордана. Как построить команду мечты?

Часть I. Краткий гайд по организационным структурам команд разработки.

1️⃣Начнём с базы на века. Вряд ли IT или какая-либо другая сфера сможет полностью от неё уйти, она древняя, как первые люди. Или еще древнее. Цеховой подход. Он же функциональный. Это там, где есть слово «отдел» или его синонимы. Объединение людей по функциональному признаку (аналитики, разработчики и прочие). Задача передается по принципу конвейера – из одного отдела в другой.

Как и у любого подхода, у него есть плюсы и минусы
➕понятное распределение ответственности
➕высокая эффективность на определенных задачах: крупные долгосрочные проекты, где не важна гибкость реакции, узкоспециализированные и требующие высокой квалификации задачи (всестороннее сложное тестирование, работа с большим техдолгом и т.д.)
➖сложность коммуникации – люди, работающие над одной целью, зачастую друг от друга вообще отключены
➖отсутствие ощущения конечной цели
➖медленная реакция на изменение процессов – для возвращения на предыдущий этап, надо сделать слишком много.

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

2️⃣кросс-функциональным. Если вы остановитесь и чутка подумаете, то легко дадите себе ответ на вопрос, что это такое. Не остановились и не подумали? Ок, сделаю за Вас: это команды, которые включают специалистов по всем необходимым навыкам для конкретного проекта. Они уже идеальнее, поскольку их плюсы закрывают минусы цеховых команд
➕упрощение взаимодействия
➕сфокусированность на общем результате
➕адаптивность к изменениям
➕а еще бонусом идёт горизонтальное развитие специалистов в виду более плотного взаимодействия

Но имеются и свои минусы, куда ж без них
➖повышенные требования к лидеру такой команды, он должен обладать достаточными навыками для синхронизации различных специалистов: как минимум быть авторитетом в своей области (управление) – не принимать идиотских решений, как максимум – обладать знаниями, хотя бы на уровне, позволяющем понимать, о чём говорят профильные специалисты.
➖нечеткие границы ответственности могут привести как к конфликтам внутри команды (особенно, если руководитель команды для галочки), так и в распределении нагрузки.

Появление кросс-функциональных команд с возможностью их перераспределения (именно это важно) – как раз таки следствие появления

3️⃣матричного подхода к управлению. Почему вдруг «матрица»? Очень просто: двумерная матрица это таблица. Каждая ячейка такой таблицы – конкретный специалист, подчинённый своему начальнику «по вертикали» (в рамках функциональной структуры, начальнику своего отдела, как там эту должность не назови), а «по горизонтали» - руководителю (или менеджеру, или как там еще у вас принято) проекта, на котором он занят.

Матрицы делят по полномочиям РП: слабая, сбалансированная, сильная. Если коротко, то на первом уровне функциональному руководителю вообще насрать, чё там происходит на проекте и он может забрать специалиста в любой момент. В сильной РП полностью управляет своими ресурсами.

Сильная чаще встречается в том случае, если речь идёт о выделении отдельного финансирования на конкретный проект, под который «бронируются» определенные специалисты, а их ФОТ за это время целиком покрывается из этих денег. В любом другом случае будет, скорее всего, сбалансированная матрица. Потому что даже не в идеальном, а в хотя бы насколько-нибудь адекватном мире никто не будет выдёргивать с проекта ключевого специалиста в напряженный момент.

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

➕позволяет настроить более эффективное использование ресурсов
➖конфликты между руководителями проектов за ресурсы
➖двойное управление может привести к путанице в подчинении

Team Topologies на очереди

Озвучка в комментариях

#медведьразмышляет #управление

Пост-контекст

Для дальнейшего развития темы "как правильно разработчику и аналитику взаимодействовать" считаю необходимым закинуть немного контекста по теме управления. Потому что логично: в рамках различных команд это взаимодействие должно выглядеть по разному.

Знаете, в чём проблема написания постов, создающих «фон» для дальнейших? Я вот теперь знаю: как не скатиться в повтор википедии и сделать подачу в целом достаточно общеизвестного материала интересной. Давайте проверим, получилось ли.

Если рассматривать всю литературу по управлению командами – это пиздец, товарищи. Сложить хотя бы по одному экземпляру каждой книги в стопку – и она будет задевать пик в центре кратера Тихо на Луне. И все они очень разные: от забавных, типа дедлайна ДеМарко, до интересных, типа Team Topologies. Поэтому я нисколько не претендую на описание всех подходов, всех видов, вообще всех.

Я сознательно упускаю влияние методологии ведения проекта (всякие водопады, аджайлы и прочие скрамы) – в контексте конкретной темы они не существенны.

Я выделю только те вещи, которые имеют дальнейшее значение в моих постах или просто интересны в контексте конкретной темы.

Сегодня начнут выходить посты про командное управление. Немного про общие принципы, немного про то, что стоит тащить к себе в команду и когда, а что нет.

Еще раз - вся информация в них очень базовая. Но не зная общего уровня подготовленности надо "проговорить" и её.

#медведьразмышляет #управление