[ARCHIVED] Методология не нужна?

[azinit]

Дискуссия закрыта, см. выводы в "motivation" доке

pr: #73, issue: #44

---

---

---

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

---

Щас с коллегой пообщался бывшим (матерый сеньор / техлид)
И он вот достаточно весомый камень вбросил аля

"Зачем ваши методологии. Есть уже принципы DRY/GRASP/SOLID/... - просто процессы и техлид должны вовремя замечать проблемы.
Все проблемы которые вы у себя хотите решить - решаются банально манагерством/процессами и принципами, которые уже давно описали
Но увы не все хотят этому следовать"

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

Т.е. я понимаю и его позицию, но и согласиться не могу до конца, что "определяется все только двумя вещами":

• процессы и то как техлид следит за проектом (и в целом за MR)
• базовые принципы (SOLID/GRASP/...) - которые нарушают, а потом жалуются

Также про "относительно легкий порог входа" - ему показалось, что это задача документации проекта и лида - чтобы каждый новый человек понимал что происходит

UPD: Он много чего еще сказал, добавил ниже

[azinit]

[GhostMayor]

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

Ну так будет всегда каждый хочет "привнести" и создаёт свой велосипед. (фото про костыли и велосипеды)

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

Ну bus factor не прямо говорит наверное подразумевает что не будет окончен в срок . (ни кто не мешает разрабам переписать аля велосипед) но это так лирика.

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

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

Всё это как и DRY это лишь инструмент, которым можно воспользоваться по разному. Кто-то назовет так, кто-то по другому, кто-то решит таким образом разделять на сущности, кто-то по другому.

И это по моему мнению самая главная проблема , скорее она конечно звучит так что "не способность объяснить свою точку зрения с помощью логики и через мерное навязывание её" и пока люди не будут думать рационально и логично то будут такие моменты . (да иногда мне кажется ещё есть языковой барьер когда одно слово интрепретируется по разному)

[ilyaagarkov]

Ну так будет всегда каждый хочет "привнести" и создаёт свой велосипед.

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

Свой велосипед начинают придумывать, когда не знают как решить проблемы общеизвестными подходами.
Если есть общеизвестное решение проблемы, а лид хочет решить все своим велосипедом, то возможно ему очень рано дали лычку "лид"

[GhostMayor]

чем дольше я занимаюсь разработкой тем больше я хочу при разработке фокусироваться именно на бизнес фичах

Во а это мой друг уже опыт )) А если чел без опыта что то создает начинается вот такие танцы с папками бубнами и архитектурами и побольшей части ему будет на любую доку пофиг ведь ему нужно здесь и сейчас (тут конечно наверное играет и заинтересованность человека * на выдержку человека / на время прочтения и понимания доки)

[sergeysova]

Если человек без опыта, то методология ему поможет решить многие проблемы.
Если он не хочет методологию, ему ничем не помочь, это out of scope

[GhostMayor]

окей, надо добавить триггер о расширении "узнаваемости" методологии. (сложна ибо как узнать о том чего не знаешь и даже не думаешь что оно где то есть)

[ilyaagarkov]

"Зачем ваши методологии. Есть уже принципы DRY/GRASP/SOLID/."

звучит как "зачем нужны ваши фреймворки React/Angular/Vue, когда уже есть JS? "=)

Это ведь просто разные уровни.

Открывая новый проект какой из принципов DRY/GRASP/SOLID/ поможет тебя понять где искать нужный тебе код?
А какой из этих принципов ответит на вопрос куда положить новый код?

Опять же зачем Мартин написал свою Чистую Архитектуру? Зачем столько книг про DDD?
Если бы DRY/GRASP/SOLID/ отвечали на все вопросы которые возникают в процессе работы над продуктом, всех этих книг бы не было. (ну может и были бы, но не были бы такими популярными)

[GhostMayor]

Опять же зачем Мартин написал свою Чистую Архитектуру? Зачем столько книг про DDD?

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

Открывая новый проект какой из принципов DRY/GRASP/SOLID/ поможет тебя понять где искать нужный тебе код?
А какой из этих принципов ответит на вопрос куда положить новый код?

холиварный ответ: а какой код код Бэкендера ? или фронта ? или который пишет игрушку в web ? (sorry)

Если мы говорим про фронт , то тут опять же вопрос о масштабности проекта , может там только фронт и serverless, а может там аполло (то есть в зависимости от стека используемых технологий)

[ilyaagarkov]

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

таким образом можно прийти к тому что все эти принципы(DRY/SOLID), которые так же создал человек, тоже просто набор велосипедов, и на самом деле они не нужны, нужно просто писать качественный код =)

холиварный ответ: а какой код код Бэкендера ? или фронта ? или который пишет игрушку в web ? (sorry)

не очень понял ответ. Мы тут обсуждаем методологию для построения именно UI. Мы тут не решаем писать где писать код , на фронте или на беке, и все вопросы касаются только фронта

Если мы говорим про фронт , то тут опять же вопрос о масштабности проекта , может там только фронт и serverless, а может там аполло (то есть в зависимости от стека используемых технологий)

никто и не предлагает серебряной пули, у любого подхода есть границы применимости. Считаю что достаточно важным пунктом feature-sliced будет в том числе, описание этих границ.

Я вот не вижу как feature-sliced может быть применен при построении каких-нибудь редакторов(аля фигма) или игр. Хотя и опыта у меня подобного нет.

[sergeysova]

Я вот не вижу как feature-sliced может быть применен при построении каких-нибудь редакторов(аля фигма) или игр. Хотя и опыта у меня подобного нет.

С этим прям сложно, там есть экраны и панели, которых может быть несколько инстансов каждого. Поэтому я бы предложил не втаскивать feature-sliced в desktop-интерфейсы

[GhostMayor]

не очень понял ответ. Мы тут обсуждаем методологию для построения именно UI. Мы тут не решаем писать где писать код , на фронте или на беке, и все вопросы касаются только фронта

хороший пример next\gatsby там серверный + фронт код

Я вот не вижу как feature-sliced может быть применен при построении каких-нибудь редакторов(аля фигма) или игр. Хотя и опыта у меня подобного нет.

Конечно это звучит глуповато но создать новую абстракцию (на основе папок) для того чтобы положить туда код относящийся к этим интерфейсам (я не говорю о 100% игр) , пример вставка 3d сцены на бэкраунд сайта )

[ilyaagarkov]

хороший пример next\gatsby там серверный + фронт код

тут проблема терминологий. Для меня серверный код !== бекенд
Next(как и все решения для SSR) для меня это фронт, хоть и часть кода выполняется на сервере.
Но это уже оффтоп)

создать новую абстракцию (на основе папок)

папки лишь инструмент. Главное это деления по типам сущностей. В целом дальше можно хоть все файлы класть в рут с префиксами или суффиксами feature / entity и тд. Суть не сильно поменяется

[azinit]

Я сам соглашусь со всеми выше отписавшими авторами, Климов здесь тоже хорошо развернул примерно такую же мысль

TL;DR: У нас в проекте есть три типа знаний: фундаментальные, стек и чисто проектные знания (специфичные именно для него)

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

[azinit]

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

[azinit]

Я его пригласил к дискуссии самого, но где могу, стараюсь сам изложить "его точку зрения"))

[azinit]

Также вот еще ряд его аргументов, которые тоже стоит учесть, как мне кажется:

UPD: Постараюсь попозж основные тезисы выделить - но посути - они уже описаны в основном посте выше

Почти про то же самое, просто с других граней (лонгрид)

Внимание, здесь есть триггеры для холивара

1. Обычно проект начинается небольшой командой (или одним человеком), прототипируется идея

   А затем уже этот человек должен обучить следующих, кто придет (вопрос скорее манагерский)

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

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

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

   Вопрос еще в том - кто приходит (джун / мидл)

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

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

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

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

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

6. На мой вопрос

   "Окей, я тебя понял. Но разве плохо, что мы идем к сбору лучших практик и стандартизации подходов, в виде методологии - которая по итогу бы удешевляла разработку?"

   С точки зрения бизнеса - "Любой продукт требует свою аудиторию, т.е. нужно найти людей, которым это будет близко и пригодится"

   • У каждого свое понятие простоты и доверия к новому
   • Даже если ты напишешь 100 методологий, вряд ли кто "даст по рукам" и примет на веру твое решение
   • Сам понимаешь, очень часто сложно принять работу другого человека, потому многим приходится (и хочется) пройти самим по граблям

7. В проекте регулярно должны быть вопросы "А правильно ли там все сделано?"
   Если таких вопросов нет, значим проблемы в построении бизнеса, а точнее - у техлида (если он сам не видит проблем своевременно)

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

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

   Просто каждый не должен забывать про тех.долг

8. Иногда кажется "Почему столько проблем в проекте?"
   А речь все про нарушение старых добрых принципов: DRY, low-coupling, Преждевременная оптимизация, SOLID и т.д.
   Кто-то придумывает свои костыли, не замечая - что они нарушают один из этих принципов

   Т.е. принципы проектирования - уже давно есть, просто почему-то начинают жаловаться, когда перестают им следовать

   • На вопрос "какие нужны абстракции и связи" - обычно прерогатива в том числе архитектора, т.к. обычно эти принципы мало кто понимает на словах

9. Я бы даже сказал "Чаще все решается процессами, а не методологиями/новыми принципами"

   • "Проблемы, которые ты описываешь - это проблемы из-за того, что кто-то пренебрег базовыми вещами аля SOLID, KISS, DRY, ..." - т.е. это проблема людей
   • Ты можешь сказать "Пишите архитектуру как дерево" - но как это поможет разрабам?
   • Обычно под каждый проект поэтому подбирается свое решение, исходя из изначальных требований

10. "Люди плохо понимают как это делать? Берешь примеры и показываешь - "Если будешь пренебрегать тем-то тем-то - то будет так и так""

    • Очень часто говорят "о хорошем и красивом будущем", но оно все никак не наступает
    • Т.е. есть паттерны, а есть анти-паттерны
    • Поэтому лучше привести явные анти-паттерны и сказать "как лучше"
    • Не знаешь как лучше? Сделай как-нибудь, а потом улучшай (очень плохо, когда ты не можешь откатиться и тебе надо принять единственное решение, которое потом нельзя дополнить)

11. Неявные сайд-эффекты? Опять проблемы манагерства и принципа Single Responsibility

    Всегда должен быть компромисс, иначе будет боль. И всегда надо понимать, какие принципы/парадигмы юзать (не всегда чистый ООП, не всегда чистый ФП)

    Через боль ты должен показать человеку, что у него говно и объяснить по принципам (тем они и хороши, пока не идут больно для самого тебя)

    • Все познается через боль, через обратную связь от кода, т.е. когда ты получаешь обратный удар от кода

12. "Все придумано уже до вас, вы просто не можете этим пользоваться"*

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

[azinit]

10.03.2021: По итогам обсуждения @sergeysova, @GhostMayor , @martis-git, @ilyaagarkov

feature-sliced - про разрезание сложного проекта по частям

[azinit]

О целевой аудитории

Для кого методология?

• Целевая аудитория - те кто готов выбрать готовую хорошую методологию
• Однако ясно, что методология - это в целом про набор best-practices, статьи от методологии, рассматривающих определенные проблемы и кейсы при разработке
  Поэтому - польза от методологии может затронуть и всех остальных, кто так или иначе сталкивается с проблемами при разработке и проектировании

О разработчиках

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

  А если уже и его разработчик не удосужится прочесть до конца - проблема уже разраба

• У нас разрабы с разным опытом, не у всех есть доверие к чужим наработкам - но это не наша Ц.А.

  Как написал выше - если захотят ознакомиться с нашим опытом, им помогут статьи / решения / доклады

  Но наша целевая аудитория - все же разработчики, нацеленные на проверенное опытом проектирование бизнес-решений

[azinit]

О планах

• В любом случае, стоит понимать что сейчас у нас всех "исследовательский интерес", в том числе с упором на практическое применение

  Это означает, что да - мы можем получить Angular 3.0, но гораздо интересней и важней - исследовать сами проблемы проектирования архитектуры

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

• Если все сложится хорошо - то методология не будет ограничиваться только спецификацией и линтером

• Если проект написан по методологии, то в том числе он помогает перейти и на другие фреймворки постепенно, даже в старых проектах, не только для новых

  Можно будет сделать и CODE_MODE для миграций

• Само собой - будет так или иначе описана интеграция методологии в проекты с имеющейся архитектурой

• В ИДЕАЛЕ 😄 - может даже дойдем до мейнтейнеров реакта

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

[azinit]

О бизнесе

1. Бизнес мало влияет на разработку, но хочет использовать такой стек и архитектуру, чтобы:

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

   Очень часто (особенно на аутсорсе), половина клиентов отказывается работать с командами, которые не работают на Ангуляре - т.к. Angular решает все перечисленные выше проблемы, хоть оверхеден, т.е. бизнес ему доверяет, он стандартизированный
   

2. "Бизнес все устраивает, потому методология не нужна?"

   Стоит понимать, что - бизнес толком не влияет на разработку, т.к. он ничего не знает про нее

   • Проблемы видит только команда и техлид

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

     Яркие примеры: Гугл и Яндекс

3. "Но ведь на этапе MVP важны не архитектура, а фичи!"

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

4. "Про умирающий бизнес"

   Стоит понимать - что рефакторинг, это приостановка в той или иной мере деливеринга фич

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

   Каждый из нас сталкивался/слышал про такие случаи

   Т.е. увольняют одного, кто говорит "что нужно срочно все исправить ,иначе архитектура все подорвет", потом нанимают следующего - и увольняют со временем и его...

   Но если бизнес не поменяет своей стратегии поведения, то в конечном счете скорее всего он загнется

   И очевидно - это тоже не наша целевая аудитория...
   

5. Думаю, что при текущих реалиях, мы скорее ориентируемся на размеры бизнеса от малый+ до пре-большой

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

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

[azinit]

Про простоту и новые идеи

1. Про простоту и конкретику

   Почему Go взлетел?

   • 🟩 Он простой для ревью от лидов, плюс поддержка Google - решает много проблем
   • 🟥 Но в то же время - новой большой волны хороших разрабов - от этого не прибавилось

   Принципы SOLID/DRY/GRASP/... не говорят о том "как все приложение в целом должно быть построено" так, чтобы во время ревью можно было оценить

   Методология же - помогает это оценить по +- четким критериям и понять - "к тому ли мы идем или нет"

2. SOLID/DRY/KISS/... - старые принципы, но каждый их понимает (если понимает) - по своему, благодаря чему "каждый проект - уникальная снежинка"

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

[azinit]

Наброшу еще на вентилятор

https://habr.com/ru/company/yandex_praktikum/blog/533702/