Декомпозиция проекта для frontend'a

image

Поговорим о том, что вы и так уже знаете.

Это моя первая статья на Хабре и я не писатель. Но взглянув на Фронтенд-2018: итоги года, руки потянулись в sublime и начали писать.

Любая сложная задача состоит из простых. Умение правильно делать декомпозицию — необходимость.

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

Уверен, вы скажете "А у нас не так и вообще react это быстро, логично и читабельно, генерировать стили при помощи js — не какая-то там надстройка, это модно, а фронтендщики не нужны, ибо наш бэкендщик Феофан сделал отличную форму на php", но все же.

Обозначение
Г1. Гении, которые это могут, являются исключениями, частным великолепный случаем.
М*. Мысль
Это можно не читать

Итак, начнем!

М1. Дубляж кода это плохо.

М2. Всегда надо думать на 100 шагов вперед.

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

Очевидно, запуская социальную сеть сразу можем сказать, что помимо веб версии будут мобильные приложения, десктоптные приложения. Отсюда…

М3. Серверная часть должна писаться только один раз. (М1)

А так как у нас есть веб версия, мобильная, десктопная, то…

М4. Серверная часть занимается данными.

Серверная часть не должна решать, какую кнопку нарисовать и какого цвета она должна быть.
Шаблон письма или html файл, который [может] подгружается при загрузке страницы для индексации поисковиком — это тоже работа с данными. Увы там приходится манипулировать html (из-за требований к индексации, например), но это уже другая проблема.

Фактически можно было бы передавать первоначальный набор файлов (html, js, css) и данные. Т.е. и тут бэк не занимается версткой.
Вот тут произошло первое разбиение проекта: откололась серверная часть. Я не буду рассуждать на каком языке написана, как устроена архитектура (добрым словом поминаю MVC). Это не мое дело ибо…

М5. Каждый должен заниматься своим делом
Фуллстеки покрывают какую-то часть проектов и тут с этим пунктом вы можете и будете конечно спорить, но обращаясь к (М2) моя позиция тут сформирована: дешевле иметь двух профессионалов своего дела, чем переписывать проект через год. Разумеется есть гении (Г1), которые поспевают везде, но таких единицы, а значит нельзя их брать в рассуждениях «Как должно быть».
Я так же отколю от этого пирога ветку Дизайнера, Юзабилиста и ко.

Поймите правильно, нормальный фронтендщик может самостоятельно накидать макет «верстая», ориентируясь на миллион аналогов и свою фантазию, но мы же по (М2) говорим о серьезных проектах, так что не льстите себе :) (Г1)

Отлично, у нас есть данные (api, все нужные методы итд итп.), у нас есть макеты — и начнем.
В виду современных реалий — я ввел бы еще одно разветвление. Увы и ах, но огромная доля современных фронтендщиков либо не умеют работать с версткой, либо не знают js. Я провел огромное количество собеседований и это странно наблюдать. По этому фронтов можно разделить на «верстальщиков» и «неверстальщиков??».
М6. Разработка должна вестись больше чем в одном файле

Скажете очевидно? Да, очевидно!

М7. Фронт делится на 2 части: та, что работает с данными, и та что их отображает.

У нас может отсутствовать та или иная часть. Например: быть только отображение (статическая страница) или быть только данные (скрипт в консоли и т.д.).

Тут предлагаю абстрагироваться и представить: вы человек-пиццерия. Принимаете звонки, раскладываете красиво сыр и отвозите покупателю. Логика подсказывает, что вы не особо эффективны (М1). Но если с вами работало бы еще 2 человек то было бы куда круче! Один принимает звонки (работает с данными), второй отвозит (представление), третий раскладывает сыр красиво :) (стилизация представления)

Уже слышу «КЭП» из 2012, «очевидно», но давайте еще раз…

М8. JS — это работа с данными.

Звонит бэкенду, принимает заказ и ему абсолютно все равно, как там уложен сыр. Может пиццы и вовсе не существует, может он просто делает опрос пиццы года?

М9. HTML — представление

Показывает пиццу клиенту, а так же принимает фидбэк (деньги, отзывы) и передает их администратору (JS).

М10. CSS — стилизация представления

Делает нужные отступы между двумя кусочками сыра.
Заметьте, администратор на телефоне не говорит как правильно укладывать сыр, а пицца не содержит чьего то разговора по телефону. Любая попытка манипулирования стилями при помощи js, или манипулирование js при помощи html — это изначально надстройка, это изначально плохо. Классы и обработка событий придумали не просто так.

Вы можете проставить класс: пепперони, салями, но не в вашей компетенции решать, как лежать сыру пепперони.

Вы можете проставить bind: если тебя пнули, не заплатили, скажи администратору. Но никак не стоит пихать администратора в пиццу. Он один, а пицц много! Если у вас пицц столько же сколько операторов, то М1.
И так, за что отвечают js, css, html — мы разобрались.

Теперь можно задавать целые ветки вопросов: как правильно готовить пиццу, как быстрее и удобнее доставить ее и как разговаривать в клиентов по телефону.

Мне хочется как то определить модное нынче слово "Компонент". По факту даже обычная кнопка это уже «Компонент», но я переопределю это на очевидных примерах. Кнопка это кнопка, а компонент:

1. Превью поста
2. Комментарий
3. Превью файла
4. Голосовалка на хабре
5. Блок «вакансии»
6. Html текст поста, рецензии, вебинара
итд

М11. Компонент везде должен выглядеть одинаково.

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

Модификации — вынужденные изменения, при необходимости. Делаются при помощи css.

Либо это другой компонент

(Например превью поста в правой колонке могут отличатся от превью поста внизу страницы).

М12. Компонент состоит из [html], [js], [css].

Каждая из частей опциональна.

М13. Вне зависимости от количества экземпляров одного и того же компонента, его стили должны быть прописаны только один раз

Например, превью поста справа, превью поста снизу, превью поста в уведомлении, а стили прописаны только один раз.

М14. В js компонента должны быть прописана только база

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

М15. Компонент может состоять из компонентов

Например, список постов.

М16. Стили выноситься в отдельный файл

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

М17. Стили компонента должны привязываться через классы родителей и только

Страница любого сайта, это как множество коробок разного размера, которые подобно матрешке вложены друг в друга.

Коробка — это компонент.

У вас есть коробка с коробками и элементами. Вам никогда не надо думать как описывать внутренности вложенной коробки. Описываете только эту.

Тут понапридумывали кучу велосипедов, но господа, никаких проблем с наименованиями не будет, как только для себя определите набор компонентов. Если вы откроете вконтакте и посчитаете там количество компонентов, ну штук 30 вы насчитаете. (В facebook не считайте, там только боль).

Не можете придумать 30 имен классов? И правильно, нечего придумывать:

М18. Ваш код будут читать другие люди.

А значит естественное название — лучшее название

Например

1. posts-list
2. comments-list
3. news-list
4. post-preview
5. comment-preview
6. news-preview
7. post-detail
8. comment-detail
9. news-detail

Невероятно сложно, да? А главное непонятно и поддерживать сложно

А про «читать другие люди» тоже отпишусь:

М19. Html, js, css должны храниться отдельно!

Если вам надо соединить их вместе, придумайте другое решение, чем писать их в одном файле. Реакт — самое отвратительное по читабельности, что я видел!

Страницу на «Коробки» поделили, как хранить файлы — обговорили. Что еще?

М20. Частных случаев почти не бывает

А если и бывает, то завтра придут ваши менеджеры на работе и скажут, что «надо модифицировать реализацию по просьбе заказчика». Решайте задачи максимально в общем виде.

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

М21. Написание стилей требует своей декомпозиции

Мир не просто так дал нам чудные LESS, SASS.

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

М22. Если вы захотите изменить цвет шрифта (итд), то вы должны внести правку только в одном месте

В заключении хотел бы отметить одну важную проблему.

М23. Правильная формулировка проблемы приводит к правильному решению

Возможно тогда бы не было css-in-js, facebook и то, чего нельзя называть.

Всем хорошего дня!

Комментарии 115

    +9
    не всё что хочется написать следует публиковать (С) Я.
      +1
      Вполне полезная статья, пусть и для фронтэндщиков с опытом это будет набором банальностей.
      Про банальности тоже надо писать, с опытом разработки не рождаются.
        –4
        Это набор банальностей, очевидных и понятный вещей, но почему то же появляются «сеньёры», пишущие стили и html в js. Иногда нужно просто остановиться и сказать: ребят, посмотрите что вы наделали! Кто за этим убирать будет?
          +2
          почему то же появляются «сеньёры», пишущие стили и html в js

          Если эти люди делают что-то полезное для бизнеса — то ничего принципиально страшного в этом нет.
          Пример: мой CTO, когда добирается до непосредственно программирования, что иногда случается — пишет код, который бы на пуллреквесте разнёс бы в пепел даже программист средней въедливости.
          Вот только код, который он пишет — это обычно базис для вещей, в дальнейшем приносящих компании многомиллионный доход. А прибрать в его коде приберут и другие.
            +1
            Только вот молодое поколение учится на этих примерах и потом доказывает, что css-in-js это правильно и быстро, а от реакта не болят глаза. Нет претензий к курицам, несущие золотые яйца. Там и правда можно нанять целую команду пофигистов, прибирающей за ней. Только выносить это все на публику не правильно.
              +2

              React и React, который видели вы, это сильно разные вещи. Никто не заставляет использовать в React css-in-js.

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

              А прибрать в его коде приберут и другие.

              Или не приберут и будет висеть технический долг.

              А что мешает писать сразу нормально?
                +1
                А что мешает писать сразу нормально?

                Эм. Быстро, качественно, дешево, pick two? Когда некий «дива»-программист набрасывает концепт чего-то прибыльного (и обычно сложного) — это может быть «быстро, дешево», либо «качественно, дешево». Ну и мы все помним историю про программиста Васю, который пилил свой качественный продукт, вот только он уже был никому не нужен ко времени релиза.

                Вот поэтому.
                  –1
                  Это просто многословное оправдание неприглядной строны. По гамбургскому счету код либо говно либо не говно. В концепции «да мой код — говно, я знаю, но тогда по-другому было нельзя, а сейчас я уже привык, на этом говне напилено много всего и без него теперь никак нельзя» нет ничего привлекательного. Для того чтобы избегать таких концепций и нужно заранее планировать, пользуясь опытом уметь предсказывать. Лучше потратить лишнее время на планирование чем на доработки.
                    +1
                    Это просто многословное оправдание неприглядной строны.

                    Это просто реальность. Вы, впрочем, можете с ней не соглашаться, ваше право.

                    Лучше потратить лишнее время на планирование чем на доработки.

                    Если лишнее время на планирование оборачивается потерей рыночной доли, а доработки потом неспешно делаются силами мелкой команды не особо звёздных программистов — нет, не лучше. Как бы вам такой ответ не нравился.

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

                    Заранее планировать с хорошим соответствием можно обычно либо несложное, либо уже известное. А вот планировать то, чего еще никто не делал — обычно выходит так себе даже у матёрых профессионалов.
                      +1
                      доработки потом неспешно делаются силами мелкой команды не особо звёздных программистов

                      То есть «звезда» пишет настолько сложный код, который даже она не в состоянии писать нормально. Потом этот write-only код должны править люди с еще более низкой квалификацией. Всё верно?
                        0
                        который даже она не в состоянии писать нормально

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

                        Потом этот write-only код должны править люди с еще более низкой квалификацией.

                        Моя мысль была о том, что концепцию, скажем, map reduce (не сейчас, а тогда, когда еще про это никто не написал) способен родить только хороший программист, в то время как красивое логирование к ней потом припишет и джун-стажёр.
                          0
                          Хорошие программисты, быстро пишущие сложный код — обычно пишут ближе к второму, а не к первому.

                          Вроде вы все верно говорите, но начинали мы как раз с архитектурных извращений, которую потом достаточно трудоёмко выпиливать, на что вы ответили, что деньги не пахнут, хотя тут еще оказались нюансы.
                            0
                            но начинали мы как раз с архитектурных извращений

                            Это вы с них начинали. Я же писал именно про
                            код, который бы на пуллреквесте разнёс бы в пепел даже программист средней въедливости

                            то, что вы в этом прочитали «архитектурные извращения» — не моя проблема. Я этого не писал.
                              0
                              Вы ответили на комментарий про css/html в js. Проблемы подразумевались вполне конкретные.
                                0
                                Ну так «конкретная проблема» css/html в js проблемой непреодолимых архитектурных извращений не является. Мне самому многое не нравится в css-in-js и инлайн-шаблонах «чего-то, напоминающего html» прямо в коде, но это работает и на этом пишутся очень сложные коммерчески успешные продукты (фейсбук ручкой машет, ага).
                                  0
                                  Я говорил о трудоёмкости, а не непреодолимости. Деньгами можно затыкать любые дыры, если они есть. Но они могут не успеть появиться, в отличие от проблем.

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

                                  Подобные рассуждения — это систематическая ошибка выжившего. Никто не знает, какое количество потенциально успешных проектов из-за этого завалилось. Но субъективный опыт подсказывает, что шаткая база очень скоро чревата расплатой и любые крупные, даже «коммерчески успешные проекты», это сборники отборного треша, который безумно дорого поддерживать. FB — это отличный пример того, да.
                                    0
                                    Подобные рассуждения — это систематическая ошибка выжившего.

                                    Согласен. Однако они во многие разы более объективные, чем
                                    Реакт — самое отвратительное по читабельности, что я видел!

                                    вот такие вот рассуждения. Вы не забывайте, что вы пытаетесь защищать не просто теоретизирование на ровном месте, но еще и субъективное теоретизирование.

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

                                    Только контраргументом к этим проектам будет не «смотрите на меня, я знаю как надо!», а «смотрите на меня, у меня есть крупный коммерчески успешный продукт, который к тому же восхитительно дешев в поддержке!».
                                      0
                                      вы пытаетесь защищать не просто теоретизирование на ровном месте, но еще и субъективное теоретизирование

                                      Вы притащили чужое высказывание из соседнего треда и утверждаете, что я его разделяю и даже защищаю. Просто прекрасно.

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

                                      "Сперва добейся"?
                                        0
                                        Вы притащили чужое высказывание из соседнего треда

                                        Это вообще-то из статьи. Но довольно показательно, что вы не поняли, откуда оно.

                                        «Сперва добейся»?

                                        В критике — нет. В заявлениях — «нужно делать вот так» — таки да. Видоизменяя классику, «если ты знаешь, как нужно делать, то чего ж ты такой бедный?».
                                          0
                                          Это вообще-то из статьи.

                                          Да, почему-то запомнилось упоминание именно из комментариев. Хотя сути дела это не меняет — фраза не моя.
                    +1
                    При достижении определенного уровня, программист уже не думает «Как писать», он просто «переносит мыли о задаче на бумагу». Т.е. писать правильно не значит дольше. Как раз наоборот, правильно заложенный фундамент экономит кучу бабла
                      0
                      При достижении определенного уровня, программист уже не думает «Как писать», он просто «переносит мыли о задаче на бумагу».

                      Это всё красивая теория, разбивающаяся о переменчивость технологического стека, которая потихоньку идёт даже в весьма стабильных языках и инструментах. А если мы всё еще про фронтэнд говорим — так и вовсе смешно, потому что техстек у нас в пределах нескольких месяцев уже может «плыть».
                        0
                        Да ладно Вам, любой новый фреймворк можно освоить ну максимум недели за две. Логическое решение задачи не шипко зависит от способа его записывания
                          0
                          Освоить на уровне «могу слабать to do» — да. Освоить на том самом уровне, когда полностью исчезают мысли «как писать» — ну щас.
                            –1
                            knockoutjs, kendo ui, angular, vue etc — сколько нужно по вашему мнению времени, чтобы перейти от одного mvvm к другому?
                              0
                              Ну давайте еще раз: «перейти» на уровне «могу сделать что-то простое и известное» и на уровне «могу сделать примерно всё оптимальным и не заводящим в тупик образом» — две очень разные вещи.
                                0
                                ну я считаю что двух недель вполне хватит, чтобы покрыть >90% проектов. Сколько по вашему должен идти переход? Сколько нужно времени, чтобы выучить синтаксис?
                                  0
                                  Чтоб «выучить» что-то из фронтэнд фреймворков и начать писать — это до пары недель в худшем случае, да. А если программист хороший, то и пары дней хватит.

                                  А вот чтоб знать проблемы и ограничения фреймворка, узкие места по быстродействию, модульности, версионности — вот на это может уйти примерно дофига времени. А те, кто этого всего не знают — уж точно не находятся на уровне «просто переношу мысль на бумагу», ибо без прочных знаний лимитов как раз проще всего «закрасить себя в угол», и придти к такому состоянию продукта, когда расширяться без тотальной переделки уже нельзя.
                      +2
                      Если программист не в состоянии писать качественный код быстро, какой он, к черту, сеньёр? Чем он отличается от миддла, который может фигачить костыли от недостатка опыта и эрудиции?
                      Проблема здоровья кодобазы сложных проектов зачастую в ошибках архитектурного планирования, когда требования меняются в процессе. Но если код — говно еще до пуша, то дело исключительно в кривых руках отдельных дарований.

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

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

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

                        Зрелые компании часто готовы вкладываться в качество кода.

                        Да, конечно. Только это обычно происходит уже потом, когда все кривоватые и быстро слепленные proof of concept уже выкачены, иногда прямо до конечных юзеров выкачены.
                          0
                          Только это обычно происходит уже потом, когда все кривоватые и быстро слепленные proof of concept уже выкачены, иногда прямо до конечных юзеров выкачены.

                          Мне нутром не нравится, что вы говорите, прямо кипит справедливое негодование, но умом чувствую, где-то тут есть правда. У вас есть убедительные примеры, может, из личного опыта, или ссылки?
                            +1
                            Про личный опыт детально я говорить, увы, не могу, ибо NDA и всё такое.
                            Но если взять «в общем» — за 15 лет разработки на 2 работы, 4 конторы (расхождение в цифрах долго объяснять), и десяток проектов разного калибра — я ни разу не встречался с тем, чтоб оплачивающие музыку сказали: окей, нам надо в первую очередь качество, а сроки и цену — во вторую.

                            Абстрактное качество в вакууме не волнует вообще почти никого, кроме нас самих (тех, кому код потом читать, развивать, и поддерживать), да тех немногих людей-управленцев, которые понимают кухню разработки и работают с горизонтом планирования в много лет. Конкретное качество выраженное тезисами вида «бизнес-логика не бажит» — бизнес иногда волнует (в зависимости от области применения продукта), но такое конкретное качество достигается конкретными же инструментами QA, а не красивым кодом; и бизнесу опять же глубоко положить, насколько кривой код внутри, до тех пор пока он вписывается в заявленные требования и проходит согласованные тесты.
                              0
                              у меня есть куча личного опыта.
                              я работал на игроделов (и игродвиглоделов). Постоянно в разработке были проекты, которые делались со словами «народ, у нас вот такие планы на Х (вставить вариант), нужно сейчас сделать тестовый пример, чтобы было что показать потенциальному заказчику».
                              В четверти случаев просто не успевали по срокам. Если там было что-то полезное — то оно после смерти «удобряло» другие проекты (например так было с поддержкой emscripten как целевой платформы). То, что дошло до глаз заказчика — в половине случаев тоже «пролетало мимо».
                              И только, если прототип был принят — у него были шансы, что его перед продакшеном отрефакторят, а не тупо допилят функциональность до «выполняет задачи дизайнеров на целевой платформе» и все, дальше саппорт пускай страдает.

                              Я сейчас работаю в корпоративном энтерпрайзе, там другие слезы, но даже там я видел в многолетнем продакшене копипасту, спагетти кода, нарушения всех 5 СОЛИД и т.д. Потому что этот код писали не программисты, а бизнес аналитики (или даже электрики) — и они учились программировать, решая свои сугубо практические задачи. Теперь их код поддерживают программисты (и я в том числе), которых фирма наняла на те деньги, которые они этим софтом заработали. Да, как программист я плююсь, ругаюсь и костерю на чем свет это гуано, но я понимаю, что именно он своей работой дает нам всем хлеб с маслом и большую айтишную миску супа.
              0

              вся статья ужимается в одну фразу — separation of concerns.

                +2
                Тут недавно пробегал товарищ со статьей про css-in-js, так вот он тоже SOLID поминать любит. Что не мешает ему пихать стили в код и считать это очень хорошим.
                  +4

                  Separation of concerns бывает разная



                  С одной стороны, автор выступает за компонентный подход (картинка справа), но в М19 почему-то внезапно требует разделять HTML/CSS/JS. При этом почему именно так надо, не объясняется.

                    –1
                    За обе картинки, ибо они друг другу не противоречат. О объяснение в М22 М17 М13 М8 М1 М18. На самом деле вся статья написана именно с этим посылом: хватит их смешивать
                      0

                      Я вижу в этих пунктах не обяснение, а наставление: "собирать в одном месте HTML/CSS/JS — плохо, понятненько?"


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

                        –1
                        Мне кажется в статье написано несколько иначе, чем «Понятненько», видимо сквозь строки читалось.
                        Почитайте вот эту статью например, там расписано подробнее habr.com/post/417707
                        То, что ваши проекты развиваются не означает, что они не развивались бы, если вы писали код иначе.
                          +2
                          Я занимаюсь фронтендом с 2011 года (чуть дольше чем зарегистрирован на Хабре), и успел поработать с разными стеками, начиная от jQuery и GWT, и заканчивая современными, типа Angular и React. CSS и JS мы тоже отдельно держали, потому что так было принято в то время.

                          После всего этого опыта подход styled-components мне кажется наиболее практичным на данный момент. В будущем, нам завезут веб-компоненты и ShadowDOM, и ситуация может поменяться снова, но пока работаем с чем можем.
                • НЛО прилетело и опубликовало эту надпись здесь
                    –2
                    Очередная прослойка, генерирующий html код, с надуманными новыми правилами и болью в глазах. Ну давайте честно, больно на это смотреть. И главное «зачем» я до сих пор не понял. Правильная архитектура кода дедовскими методами дает абсолютно понятный и предсказуемый проект. А в реакте неумеющие писать азы фронты творят вообще нечитаемый хаос. Да, хаос подходящее слово.
                      0
                      Ну давайте честно, больно на это смотреть.

                      «Больно» слишком субъективное понятие, кому-то вон не больно. Может все-таки развернете свою мысль и расскажете о конкретных проблемах?
                        0
                        image
                        Вот чисто эксперимент: вы считаете это нормально?
                          0
                          Так вы подсветку в редакторе настройте нормально, и сразу станет читабельнее.

                          Не то, чтоб я сильно болел за JSX, но вы высасываете проблему из пальца.
                            –3
                            А вопрос даже не только в подсветке, это будто сварить пельмени в чайнике: да, так можно, да так делают студенты, но есть кастрюля предназначенная для этого, а в чайнике я чай сделаю.
                              +1
                              То, что вы не понимаете, зачем это сделано, не меняет того, что кому-то удобно так работать.

                              Идея Реакта, как я вижу – перенести трудности разработки с разработчика на процессор пользователя. Да, мы теряем в 2-3 раза в производительности, зато теперь даже верстальщик может написать огромный SPA. При этом, если он не будет нарушать гайдлайны типа «не меняйте this.state напрямую», то оно даже тормозить не будет.

                              Иногда нужно пересмотреть свои личные предпочтения, потому что бывает, что они обманывают.
                          0

                          Реакт хорош для своих задач, как и HTML без CSS, HTML с CSS, HTML+CSS+JS. Прежде всего реакт предлагает инструменты для упрощения массовых операций с DOM. Простыми словами: это инструмент для патчинга DOM (массовых точечных изменений DOM-нод), который накладывает собственные ограничения в виде синтаксиса JSX. Предлагаю задать себе вопрос: как мне сделать 20 тысяч изменений элементов в DOM, но которые заставят обновиться только textContent в нужных DOM-нодах, без обновления всего (уже построенного) дерева DOM?
                          Обычный HTML+DOM не могут ответить на этот вопрос, поэтому и существует реакт, которые дает разработчику абстракцию, которая позволяет не думать (или думать меньше и предсказуемей) о вопросах производительности. Разработчики сознательно принимают синтаксис JSX, потому что видят профит в другом. И вообще, синтаксис часто — это вкусовщина и в реальности значимым является: может ли технология/подход "X" делать тоже самое, но: быстрее/безопасней/предсказуемей. Не фокусируйтесь на длинне ручки, а фокусируйтесь на том как она пишет.

                          +1
                          Лично я, например, сразу вспоминаю вот это
                          image
                            +1

                            И вспоминаете не даром, ведь jsx изначально был сделан для php, а сам реакт — фреймворк, предназначенный для упрощения портирования существующего php-кода на js (примерно такого, как вы выше написали). С-но, перед фейсбуком стояла задача сделать фреймворк такой, чтобы архитектура на фронтенде максимально повторяла архитектуру существующего бека на пыхе, ее они и решили. Оттуда и все родовые травмы — что можно ожидать от фреймворка, созданного по принципу "пишем на js будто на пыхе"?

                              0

                              А есть какой-нибудь источник, подтверждающий это?


                              В первом публичном анонсе React о PHP вообще ни слова, все больше про декларативные компоненты, и однонаправленные потоки данных.

                                +2
                                А есть какой-нибудь источник, подтверждающий это?

                                https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/


                                Естественно, никто в контексте реакта про пехепе не вспоминает, это же зашквар.
                                Вы представьте себе, выходит хипстор из фейсбука на сцену и говорит другим хипсторам в зале: "мы тут вам фреймворк для портировния говнокода с пыха на js подвезли".
                                Конец немного предсказуем.


                                все больше про декларативные компоненты, и однонаправленные потоки данных.

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

                                  0
                                  Полностью с вами согласен! Сам постоянно об этом говорю, не понимаю почему это не все понимают и знают.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Неумеющие писать азы будут творить хаос на любом стеке.

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


                            Правильную архитектуру можно и на Брейнфаке написать.

                            Куда важнее на чём нельзя написать неправильную.

                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Вы делаете довольно громкие заявления, не подкрепляя их аргументацией. Не надо так.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    0
                                    И я вам привёл пример технологии, которая реально их решает. Вы голословно утверждаете, что это невозможно. Что забавно, ссылаясь на «общеизвестный опыт», который как раз таки показывает, что, даже гуру программирования легко допускают утечки и переполнение стека в одних языках, а в других подобных проблем либо нет как класса, либо их существенно сложнее добиться.
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                        0
                                        Очень просто — там нет ни циклов, ни рекурсий.
                                          0

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

                                            0
                                            На уровне языка — нет.
                                              0

                                              Еще раз, математический факт — если на уровне языка нет рекурсии и других подобных вещей, то существует некая константа c такая, что ф-я с кодом длины N не может вернуть результат по длине превышающий cN.

                                                0
                                                Мы уже выяснили, что вы очень узко смотрите на вещи. Функций в том языке тоже нет. Только классы, свойства и связи.
                                                  0

                                                  На вашем языке можно вывести список произвольной длины? Можно. Значит, там есть циклы. Та конструкция, которая выводит данный список — и есть цикл.

                                                    0
                                                    Конструкция «выведи этот список вот сюда» не является циклом.
                                                      0

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


                                                      Например — вполне же можно вывести список внутри списка и получить O(n^2)?

                                                        0
                                                        Давайте не выдумывать свои определения. Цикл — это синтаксическая конструкция. Подобного синтаксиса в упомянутом языке нет.

                                                        O(n^2) получить нельзя, так как объём вывода пропорционален размеру экрана, который является константой. Но даже в пределах экрана это будет лишь O(n) так как опять же, нет синтаксиса для организации квадратичной сложности.

                                                          0
                                                          Давайте не выдумывать свои определения. Цикл — это синтаксическая конструкция.

                                                          Вы софистикой занимаетесь. Все, что эквивалентно такой конструкции — это тоже цикл. Рекурсии разного вида, гото и т.д.


                                                          O(n^2) получить нельзя, так как объём вывода пропорционален размеру экрана, который является константой.

                                                          А что, вывести целиком ваш фреймворк в принципе не позволяет? И поиск не работает, значит?


                                                          так как опять же, нет синтаксиса для организации квадратичной сложности.

                                                          Ну как нет? Еще раз — вывел список внутри списка. Все, O(n^2).
                                                          Да и это даже не обязательно. Можно просто вывести один список длины O(n^2).
                                                          Или можно вывести таблицу. Тоже сложность будет квадратичной.

                                                            0
                                                            Все, что эквивалентно такой конструкции — это тоже цикл.

                                                            Это не так. Хвостовая рекурсия может быть преобразована в цикл, но сама по себе циклом не является. И тем более, если она не хвостовая.


                                                            Рекурсии разного вида, гото и т.д.

                                                            Этого всего тоже нет.


                                                            А что, вывести целиком ваш фреймворк в принципе не позволяет?

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


                                                            И поиск не работает, значит?

                                                            Браузерный поиск по всем текстам на странице? Разумеется.


                                                            Еще раз — вывел список внутри списка.

                                                            Вы не сможете вывести один список в более чем одно место.


                                                            Можно просто вывести один список длины O(n^2).

                                                            Вы не сможете создать такой список средствами языка.


                                                            Или можно вывести таблицу. Тоже сложность будет квадратичной.

                                                            Двумерность отображения таблицы не делает её квадратичной.

                                                              0
                                                              Это не так. Хвостовая рекурсия может быть преобразована в цикл, но сама по себе циклом не является.

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


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

                                                              Так и написание рекурсии/цикла требует приложить усилия.


                                                              Браузерный поиск по всем текстам на странице? Разумеется.

                                                              И как он работает, если страница не загружена?


                                                              Вы не сможете вывести один список в более чем одно место.

                                                              Зачем один? n списков.


                                                              Вы не сможете создать такой список средствами языка.

                                                              Вы имеете ввиду, что не смогу сделать данные? Так это не важно.


                                                              Двумерность отображения таблицы не делает её квадратичной.

                                                              Если у вас количество строк равно количество столбец — делает.

                                                                0
                                                                Так и написание рекурсии/цикла требует приложить усилия.

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


                                                                И как он работает, если страница не загружена?

                                                                Разумеется не работает. Он такой никому не нужен. А добавить фильтрацию — плёвое дело.


                                                                Зачем один? n списков.

                                                                Их не от куда взять опять же.


                                                                Вы имеете ввиду, что не смогу сделать данные?

                                                                Не важно какой список. Вы можете получить список, передать список. А средств изменения его размерности нет.


                                                                Если у вас количество строк равно количество столбец — делает.

                                                                Опять же не сможете сделать это средствами языка.

                                                                  0
                                                                  Речь о дополнительных усилиях сверх необходимого для решения задачи.

                                                                  Если задача решается без цикла, то соответствующие усилия и будут сверх необходимого.


                                                                  Разумеется не работает.

                                                                  Зачем же вы выше соврали, что работает?


                                                                  Не важно какой список. Вы можете получить список, передать список. А средств изменения его размерности нет.

                                                                  Так кто мешает передать список длины O(n^2)? Или список списков?


                                                                  Опять же не сможете сделать это средствами языка.

                                                                  Не смогу вывести такую таблицу (данные полагаем готовыми)?

                                                                    –1

                                                                    Druu, решение задач с использованием циклов во много раз трудоемнее чем с рекурсиями. Хотя бы потому, что где-то надо хранить стеки. А стеки бывают многомерные. Или вы предлагаете их глобализировать. Это прямой и поэтому самый короткий путь к краху программы. goto это вообще про смену контекста больше. Вы ПТУ заканчивали? Нет? fortran style?

                                                                      +1
                                                                      Druu, решение задач с использованием циклов во много раз трудоемнее чем с рекурсиями. Хотя бы потому, что где-то надо хранить стеки.

                                                                      В случае хвостовой рекурсии стеки хранить не надо.

                                                                      0
                                                                      Давайте заканчивать этот бессмысленный спор. Я вижу вы и сами уже не особо следите за тем, что спрашиваете, и что вам отвечают. Упомянутый язык — не язык общего назначения, а весьма ограниченный DSL, позволяющий любому верстальщику, не умеющему в циклы и условия, собрать приложение любой сложности, и полностью задать его визуал, без возможности сотворить хаос, ввиду отсутствия механизмов этого хаоса создания. Вы можете сколько угодно фантазировать о списках длинной O(n^2), что бы это ни значило, но пока не ознакомитесь с этим языком, так и не поймёте, что он позволяет, а что нет.
                                                                        0
                                                                        Давайте заканчивать этот бессмысленный спор. Я вижу вы и сами уже не особо следите за тем, что спрашиваете, и что вам отвечают. Упомянутый язык — не язык общего назначения, а весьма ограниченный DSL, позволяющий любому верстальщику, не умеющему в циклы и условия, собрать приложение любой сложности

                                                                        Вы либо крестик снимите, либо трусы наденьте.


                                                                        Ограниченный дсл — он ограниченный, и никаких приложений любой сложности вы на нем никогда не напишете.


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

                                                                          0
                                                                          Я вам по секрету скажу: бизнес-логику пишет не верстальщик.
                            • НЛО прилетело и опубликовало эту надпись здесь
                          –5
                          JSX className htmlFor — больше названий, надо определенно больше названий и усложнений! Программисты ведь так любят создавать свои названия, писать свои фреймворки. Настолько любят давать все новые названия, что джуны бьются головой об стену, не зная что учить :)
                          +1
                          Вопрос к автору, вы сколько лет фронтендом занимаетесь, что успели так «закостенеть»? Неужели это ждёт нас всех…
                            +3
                            М1. Дубляж кода это плохо.

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

                              0

                              По поводу разделения Html, js, css, мне всё равно импонирует подход vue, то что весь компонент, конкретно его стили, и внутрений скриптинг, типо замороченых анимаций по клику, пишутся в одном файле, и если я захочу переписать полностью один вид кнопок, не затрагивая остальные, мне нужно ходить в общий css, я это могу сделать в одном файле, а в глобальный css вынести те самые переменные (css custom properties) цветов, шрифтов, отступов, теней и всего остального. Я пока только изучаю vue, но насколько я понимаю проблем с тем что бы забрать значения этих переменных из глобального css не будет. Именно по этой причине я начал учить Vue вместо реакта или господи помилуй Angular

                                0
                                Именно по этой причине я начал учить Vue вместо реакта

                                В реакте никто не мешает реализовывать такой же подход.
                                  0

                                  Ну акцент на "можно реализовать" а во vue это есть из коробки, это не делает реакт хуже, и не означает что я не стану его учить в будущем)

                                    0
                                    Описываемая проблематика мне кажется фичей CSS, нежели генерации разметки.

                                    Возможно, что я заблуждаюсь и если вы мне укажите направление поиска информации о том, что это позволяет делать некая супер-фича Vue, то я буду признателен (=
                                    0
                                    В реакте была предпринята некоторая попытка реализации Single File компонентов, но по факту их там нет (костыли типа css-in-js не в счет). Реализации этой идеи Vue или Svelte более полные и удобные.
                                  +2
                                  М2. Всегда надо думать на 100 шагов вперед.

                                  Никогда не надо, потому что в 10 случаях из 10 спустя неделю то что вы там понапридумывали уже после шага эдак пятого не будет иметь ничего общего с реальностью. И вообще — YAGNI.
                                  Пока вы продумываете 100 шагов, ваш конкурент выводит на рынок свой продукт.

                                    0
                                    Разработка софта не ограничивается стартапами-однодневками. Те, кто разрабатывают язык/платформу/экосистему/фреймворк, вынуждены думать и на 100 и на 1000 шагов вперёд. Так как шанс взлететь есть только один.
                                      0
                                      Есть альтернативный способ, которым много кто успешно достигает успеха: думать на 100 шагов вперед, а код писать вперед только на два шага, и выкидывать продуманные 100 шагов.

                                      Вы же не думаете, что языки/платформы/экосистемы родились сразу такими, какие сейчас есть? Ими же кто-то вначале пользовался и говорил, что тут неудобно, а там нужно все переделать. А попользоваться невозможно, пока код не написан.
                                        0

                                        Спасибо, что развернули мою мысль.

                                          0
                                          думать на 100 шагов вперед, а код писать вперед только на два шага, и выкидывать продуманные 100 шагов.

                                          Зачем бессмысленно тратить время и ресурсы на продумывание 98 последующих шагов, если результат этой работы будет выброшен?

                                          0
                                          Те, кто разрабатывают язык/платформу/экосистему/фреймворк, вынуждены думать и на 100 и на 1000 шагов вперёд.

                                          И даже в этом случае ни на 100, ни на 1000 думать не надо, т.к. процесс разработки будет долгий и пока вы дойдете до 50 шага, все что вы придумали — надо будет выкинуть на помойку.
                                          Безусловно, такие задачи, когда ТЗ есть и не меняется — существуют, но это исключения, признаем честно.

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

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

                                              Почти наверняка те изменения, которые вы предполагали, делать не придется, а придется делать те, что вы не предполагали.


                                              В заказной разработке ТЗ вообще практически не меняется.

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


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

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

                                                0
                                                И вновь у нас с вами разный бэкграунд и, как следствие, разное представление о «скорее всего». Давайте я вам лучше расскажу об одном маразматичном случае…

                                                Проект на пол года. Необходимый объём функциональности известен. Детализированного ТЗ, разумеется, нет. Разботаем по скраму. Я реализовал функциональность А (которая в спринте) и В (которая ещё не в спринте), на основе обобщённого кода С. По результатам нескольких дней бодания на код-ревью: выпиливаем В, так как он не в спринте; выпиливаем С, так как вынос части кода из А — переусложнение; соответственно перепиливаем А, чтобы он не зависел от С. Через пару итераций потребовалась функциональность В, которую не долго думая сделали копипастой А.

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

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


                                                  Давайте я вам лучше расскажу об одном маразматичном случае…

                                                  Так в итоге беспричинно YAGNI нарушили, оттуда и маразм. По YAGNI следовало реализовать А на основе С, и В (раз уж он уже был сделан) не выпиливать ни в коем случае. То есть, фактически, сделать так, как вы сделали изначально.


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

                                                    0
                                                    Но в среднем по индустрии

                                                    И соответственно у нас с вами разное представление о средней индустрии. Вообще, мерить среднюю температую по больнице — неблагодарное занятие.


                                                    беспричинно YAGNI нарушили

                                                    Это всё не важно. Я проиллюстрировал до чего доводит отсутствие стратегического планирования. Эджайл в современном представлении многих — это не "менять планы по мере поступления данных", а "не строить планов вообще". Жить "здесь и сейчас", безусловно проще. А если это ещё и доктрина индустрии/компании/команды, то вообще снимает с тебя какую-либо ответственность. Но стратегия эта всё же так себе.


                                                    почему в итоге нельзя было откатиться на ваш оригинальный коммит

                                                    Интерфейсы разные. Пришлось бы перепиливать "не относящуюся к задаче функциональность". Да и делал уже не я.

                                                      0
                                                      И соответственно у нас с вами разное представление о средней индустрии.

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


                                                      Это всё не важно. Я проиллюстрировал до чего доводит отсутствие стратегического планирования.

                                                      Нет, это как раз важно. Никакое стратегическое планирование не помогло бы вам избежать описанной ситуации, если вы сперва запланировали, что В и С — ненужно, а потом — что оно нужно. А вот следование YAGNI — помогло бы.


                                                      Эджайл в современном представлении многих — это не "менять планы по мере поступления данных", а "не строить планов вообще".

                                                      При чем тут "не строить планы вообще"? Речь о том, чтобы не делать то, что делать не нужно.
                                                      Важно понимать, что для данного конкретного проекта является требованиями, а что — просто фантазии.

                                                        0
                                                        Вы опять скатились в проповеди. Что вы пытаетесь доказать? И главное — зачем?
                                                          0

                                                          Это у вас спросить надо, вы ж спорить кинулись. Я только отметил, что в современных реалиях "думать на 1000 шагов вперед" — глупость.
                                                          При чем тут какие-то проповеди — непонятно.

                                                            0
                                                            И я поправил, что ваше категоричное заявление является слишком однобоким взглядом на вещи.
                                                              0
                                                              И я поправил, что ваше категоричное заявление является слишком однобоким взглядом на вещи.

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

                                                                0
                                                                Речь не об исключениях, а о тех областях разработки ПО, с которыми вы не работали.
                                                                  0

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

                                                                    0
                                                                    Пруфлинки на статистику в студию.
                                            –1

                                            Думать на 100 шагов вперёд это высший пилотаж. Иногда даже третий шаг не виден за вторым. Иногда лучше ходить по кругу чтобы ничего не пропустить. То что было плохим на 2-м шаге может быть наилучшим на 4-м.

                                            0
                                            YAGNI хорошо соблюдать для реализаций, но он не «серебряная пуля». Например — лучше сразу и наперед продумать и написать все интерфейсы — чтобы понять архитектуру (происходит ли «стыковка» проекта, или в ТЗ есть пробелы или конфликты) и разделить ее для разделения работы команды.
                                            Во-вторых — я у себя увидел, что KISS & DRY — это не 100% правила, это переходы между состояниями: когда я пишу новую функциональность (обычно на уровне класса\файла), то я пишу «как пишется», без оглядки на повторяемость и даже копипасту. Происходит как бы «распухание кода». После того, как функциональность написана и «вроде работает» — просматриваю код (и написанный только что, и старый, похожий на этот) еще раз, на предмет рефакторинга — убирания повторов, переименования функций\параметров, порядка их передачи и вычисления, вынос в утилиты и прочая «выжимка и отсушка».

                                            А когда у вас это уже 5-20ый проект, то у вас уже накопился запас классов в папке «utils», и можно его оформлять в виде либы или фреймворка (но это согласитесь, уже другой уровень).
                                              0
                                              YAGNI хорошо соблюдать для реализаций, но он не «серебряная пуля». Например — лучше сразу и наперед продумать и написать все интерфейсы — чтобы понять архитектуру (происходит ли «стыковка» проекта, или в ТЗ есть пробелы или конфликты) и разделить ее для разделения работы команды.

                                              Так YAGNI применяется тогда, когда нет причин не применять. Если вы можете в данной конкретной точке назвать ясную и понятную причину, почему надо сделать Х — делайте.


                                              Если же вы причину назвать не можете, а вместо нее у вас получаются только пространные рассуждения из разряда: "а вдруг когда-нибудь блаблабла" — Х вам не нужен. По крайней мере не нужен в данный момент.


                                              С-но, это верно для любого принципа — если вы можете объяснить, почему в данный конкретный момент будет правильно нарушить KISS или DRY — смело нарушайте.

                                                0
                                                Довольно толковый комментарий, спасибо! Отмечал примерно тоже самое и в своей работе.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое