Comments 115
Про банальности тоже надо писать, с опытом разработки не рождаются.
почему то же появляются «сеньёры», пишущие стили и html в js
Если эти люди делают что-то полезное для бизнеса — то ничего принципиально страшного в этом нет.
Пример: мой CTO, когда добирается до непосредственно программирования, что иногда случается — пишет код, который бы на пуллреквесте разнёс бы в пепел даже программист средней въедливости.
Вот только код, который он пишет — это обычно базис для вещей, в дальнейшем приносящих компании многомиллионный доход. А прибрать в его коде приберут и другие.
А прибрать в его коде приберут и другие.
Или не приберут и будет висеть технический долг.
А что мешает писать сразу нормально?
А что мешает писать сразу нормально?
Эм. Быстро, качественно, дешево, pick two? Когда некий «дива»-программист набрасывает концепт чего-то прибыльного (и обычно сложного) — это может быть «быстро, дешево», либо «качественно, дешево». Ну и мы все помним историю про программиста Васю, который пилил свой качественный продукт, вот только он уже был никому не нужен ко времени релиза.
Вот поэтому.
Это просто многословное оправдание неприглядной строны.
Это просто реальность. Вы, впрочем, можете с ней не соглашаться, ваше право.
Лучше потратить лишнее время на планирование чем на доработки.
Если лишнее время на планирование оборачивается потерей рыночной доли, а доработки потом неспешно делаются силами мелкой команды не особо звёздных программистов — нет, не лучше. Как бы вам такой ответ не нравился.
Для того чтобы избегать таких концепций и нужно заранее планировать, пользуясь опытом уметь предсказывать.
Заранее планировать с хорошим соответствием можно обычно либо несложное, либо уже известное. А вот планировать то, чего еще никто не делал — обычно выходит так себе даже у матёрых профессионалов.
доработки потом неспешно делаются силами мелкой команды не особо звёздных программистов
То есть «звезда» пишет настолько сложный код, который даже она не в состоянии писать нормально. Потом этот write-only код должны править люди с еще более низкой квалификацией. Всё верно?
который даже она не в состоянии писать нормально
Вы зря мешаете в кучу «нормальность» и «сложность». Код может быть как архитектурно кривой, но при этом чистый в мелочах (работает, проходит пуллреквесты у любого, кто не задумывался об высокоуровневой концепции, но к дальнейшему развитию абсолютно не пригоден), так и наоборот (работает, вызовет миллиарды претензий при проверке кода, но архитектурно спланирован нормально и в дальнейшем спокойно расширяется).
Хорошие программисты, быстро пишущие сложный код — обычно пишут ближе к второму, а не к первому.
Потом этот write-only код должны править люди с еще более низкой квалификацией.
Моя мысль была о том, что концепцию, скажем, map reduce (не сейчас, а тогда, когда еще про это никто не написал) способен родить только хороший программист, в то время как красивое логирование к ней потом припишет и джун-стажёр.
Хорошие программисты, быстро пишущие сложный код — обычно пишут ближе к второму, а не к первому.
Вроде вы все верно говорите, но начинали мы как раз с архитектурных извращений, которую потом достаточно трудоёмко выпиливать, на что вы ответили, что деньги не пахнут, хотя тут еще оказались нюансы.
но начинали мы как раз с архитектурных извращений
Это вы с них начинали. Я же писал именно про
код, который бы на пуллреквесте разнёс бы в пепел даже программист средней въедливости
то, что вы в этом прочитали «архитектурные извращения» — не моя проблема. Я этого не писал.
это работает и на этом пишутся очень сложные коммерчески успешные продукты
Подобные рассуждения — это систематическая ошибка выжившего. Никто не знает, какое количество потенциально успешных проектов из-за этого завалилось. Но субъективный опыт подсказывает, что шаткая база очень скоро чревата расплатой и любые крупные, даже «коммерчески успешные проекты», это сборники отборного треша, который безумно дорого поддерживать. FB — это отличный пример того, да.
Подобные рассуждения — это систематическая ошибка выжившего.
Согласен. Однако они во многие разы более объективные, чем
Реакт — самое отвратительное по читабельности, что я видел!
вот такие вот рассуждения. Вы не забывайте, что вы пытаетесь защищать не просто теоретизирование на ровном месте, но еще и субъективное теоретизирование.
любые крупные, даже «коммерчески успешные проекты», это сборники отборного треша, который безумно дорого поддерживать
Только контраргументом к этим проектам будет не «смотрите на меня, я знаю как надо!», а «смотрите на меня, у меня есть крупный коммерчески успешный продукт, который к тому же восхитительно дешев в поддержке!».
вы пытаетесь защищать не просто теоретизирование на ровном месте, но еще и субъективное теоретизирование
Вы притащили чужое высказывание из соседнего треда и утверждаете, что я его разделяю и даже защищаю. Просто прекрасно.
контраргументом к этим проектам будет не «смотрите на меня, я знаю как надо!», а «смотрите на меня, у меня есть крупный коммерчески успешный продукт, который к тому же восхитительно дешев в поддержке!».
"Сперва добейся"?
Вы притащили чужое высказывание из соседнего треда
Это вообще-то из статьи. Но довольно показательно, что вы не поняли, откуда оно.
«Сперва добейся»?
В критике — нет. В заявлениях — «нужно делать вот так» — таки да. Видоизменяя классику, «если ты знаешь, как нужно делать, то чего ж ты такой бедный?».
При достижении определенного уровня, программист уже не думает «Как писать», он просто «переносит мыли о задаче на бумагу».
Это всё красивая теория, разбивающаяся о переменчивость технологического стека, которая потихоньку идёт даже в весьма стабильных языках и инструментах. А если мы всё еще про фронтэнд говорим — так и вовсе смешно, потому что техстек у нас в пределах нескольких месяцев уже может «плыть».
А вот чтоб знать проблемы и ограничения фреймворка, узкие места по быстродействию, модульности, версионности — вот на это может уйти примерно дофига времени. А те, кто этого всего не знают — уж точно не находятся на уровне «просто переношу мысль на бумагу», ибо без прочных знаний лимитов как раз проще всего «закрасить себя в угол», и придти к такому состоянию продукта, когда расширяться без тотальной переделки уже нельзя.
Проблема здоровья кодобазы сложных проектов зачастую в ошибках архитектурного планирования, когда требования меняются в процессе. Но если код — говно еще до пуша, то дело исключительно в кривых руках отдельных дарований.
мы все помним историю про программиста Васю, который пилил свой качественный продукт, вот только он уже был никому не нужен ко времени релиза.
Не все работают в стартапах. Зрелые компании часто готовы вкладываться в качество кода. Плохокод — это не только страдания на поддержке, это еще фракталы багов и низкое качество продукта. Вроде очевидно, но
Не все работают в стартапах.
Стартап как компания — тут совершенно не причём. Это стартап как фаза жизненного цикла программного продукта, который случается у всех контор, делающих какие-либо новые программные продукты, от гугла до фейсбука (да, они тоже новое делают).
Зрелые компании часто готовы вкладываться в качество кода.
Да, конечно. Только это обычно происходит уже потом, когда все кривоватые и быстро слепленные proof of concept уже выкачены, иногда прямо до конечных юзеров выкачены.
Только это обычно происходит уже потом, когда все кривоватые и быстро слепленные proof of concept уже выкачены, иногда прямо до конечных юзеров выкачены.
Мне нутром не нравится, что вы говорите, прямо кипит справедливое негодование, но умом чувствую, где-то тут есть правда. У вас есть убедительные примеры, может, из личного опыта, или ссылки?
Но если взять «в общем» — за 15 лет разработки на 2 работы, 4 конторы (расхождение в цифрах долго объяснять), и десяток проектов разного калибра — я ни разу не встречался с тем, чтоб оплачивающие музыку сказали: окей, нам надо в первую очередь качество, а сроки и цену — во вторую.
Абстрактное качество в вакууме не волнует вообще почти никого, кроме нас самих (тех, кому код потом читать, развивать, и поддерживать), да тех немногих людей-управленцев, которые понимают кухню разработки и работают с горизонтом планирования в много лет. Конкретное качество выраженное тезисами вида «бизнес-логика не бажит» — бизнес иногда волнует (в зависимости от области применения продукта), но такое конкретное качество достигается конкретными же инструментами QA, а не красивым кодом; и бизнесу опять же глубоко положить, насколько кривой код внутри, до тех пор пока он вписывается в заявленные требования и проходит согласованные тесты.
я работал на игроделов (и игродвиглоделов). Постоянно в разработке были проекты, которые делались со словами «народ, у нас вот такие планы на Х (вставить вариант), нужно сейчас сделать тестовый пример, чтобы было что показать потенциальному заказчику».
В четверти случаев просто не успевали по срокам. Если там было что-то полезное — то оно после смерти «удобряло» другие проекты (например так было с поддержкой emscripten как целевой платформы). То, что дошло до глаз заказчика — в половине случаев тоже «пролетало мимо».
И только, если прототип был принят — у него были шансы, что его перед продакшеном отрефакторят, а не тупо допилят функциональность до «выполняет задачи дизайнеров на целевой платформе» и все, дальше саппорт пускай страдает.
Я сейчас работаю в корпоративном энтерпрайзе, там другие слезы, но даже там я видел в многолетнем продакшене копипасту, спагетти кода, нарушения всех 5 СОЛИД и т.д. Потому что этот код писали не программисты, а бизнес аналитики (или даже электрики) — и они учились программировать, решая свои сугубо практические задачи. Теперь их код поддерживают программисты (и я в том числе), которых фирма наняла на те деньги, которые они этим софтом заработали. Да, как программист я плююсь, ругаюсь и костерю на чем свет это гуано, но я понимаю, что именно он своей работой дает нам всем хлеб с маслом и большую айтишную миску супа.
вся статья ужимается в одну фразу — separation of concerns.
Separation of concerns бывает разная
С одной стороны, автор выступает за компонентный подход (картинка справа), но в М19 почему-то внезапно требует разделять HTML/CSS/JS. При этом почему именно так надо, не объясняется.
Я вижу в этих пунктах не обяснение, а наставление: "собирать в одном месте HTML/CSS/JS — плохо, понятненько?"
Не хватает раскрытия темы, что именно пойдет не так, если вашим правилам не следовать. Я, например, использую styled-components, и мои проекты успешно развиваются, фичи делаются, а зарплата растет. И, наблюдая за своими коллегами, вижу что не я один такой. Чем нам могут быть ваши правила полезны?
Почитайте вот эту статью например, там расписано подробнее habr.com/post/417707
То, что ваши проекты развиваются не означает, что они не развивались бы, если вы писали код иначе.
После всего этого опыта подход styled-components мне кажется наиболее практичным на данный момент. В будущем, нам завезут веб-компоненты и ShadowDOM, и ситуация может поменяться снова, но пока работаем с чем можем.
Ну давайте честно, больно на это смотреть.
«Больно» слишком субъективное понятие, кому-то вон не больно. Может все-таки развернете свою мысль и расскажете о конкретных проблемах?
Вот чисто эксперимент: вы считаете это нормально?
Не то, чтоб я сильно болел за JSX, но вы высасываете проблему из пальца.
Идея Реакта, как я вижу – перенести трудности разработки с разработчика на процессор пользователя. Да, мы теряем в 2-3 раза в производительности, зато теперь даже верстальщик может написать огромный SPA. При этом, если он не будет нарушать гайдлайны типа «не меняйте this.state напрямую», то оно даже тормозить не будет.
Иногда нужно пересмотреть свои личные предпочтения, потому что бывает, что они обманывают.
Тут даже профессионалы не могут на Реакте сделать простой сайт, чтобы не тормозило, а вы про верстальщиков..
Реакт хорош для своих задач, как и HTML без CSS, HTML с CSS, HTML+CSS+JS. Прежде всего реакт предлагает инструменты для упрощения массовых операций с DOM. Простыми словами: это инструмент для патчинга DOM (массовых точечных изменений DOM-нод), который накладывает собственные ограничения в виде синтаксиса JSX. Предлагаю задать себе вопрос: как мне сделать 20 тысяч изменений элементов в DOM, но которые заставят обновиться только textContent в нужных DOM-нодах, без обновления всего (уже построенного) дерева DOM?
Обычный HTML+DOM не могут ответить на этот вопрос, поэтому и существует реакт, которые дает разработчику абстракцию, которая позволяет не думать (или думать меньше и предсказуемей) о вопросах производительности. Разработчики сознательно принимают синтаксис JSX, потому что видят профит в другом. И вообще, синтаксис часто — это вкусовщина и в реальности значимым является: может ли технология/подход "X" делать тоже самое, но: быстрее/безопасней/предсказуемей. Не фокусируйтесь на длинне ручки, а фокусируйтесь на том как она пишет.
И вспоминаете не даром, ведь jsx изначально был сделан для php, а сам реакт — фреймворк, предназначенный для упрощения портирования существующего php-кода на js (примерно такого, как вы выше написали). С-но, перед фейсбуком стояла задача сделать фреймворк такой, чтобы архитектура на фронтенде максимально повторяла архитектуру существующего бека на пыхе, ее они и решили. Оттуда и все родовые травмы — что можно ожидать от фреймворка, созданного по принципу "пишем на js будто на пыхе"?
А есть какой-нибудь источник, подтверждающий это?
В первом публичном анонсе React о PHP вообще ни слова, все больше про декларативные компоненты, и однонаправленные потоки данных.
А есть какой-нибудь источник, подтверждающий это?
https://www.facebook.com/notes/facebook-engineering/xhp-a-new-way-to-write-php/294003943919/
Естественно, никто в контексте реакта про пехепе не вспоминает, это же зашквар.
Вы представьте себе, выходит хипстор из фейсбука на сцену и говорит другим хипсторам в зале: "мы тут вам фреймворк для портировния говнокода с пыха на js подвезли".
Конец немного предсказуем.
все больше про декларативные компоненты, и однонаправленные потоки данных.
Ну вот в XHP как видите были эти компоненты, а однонаправленный поток данных — он от того однонаправленный, что двунаправленного на беке не бывает. Бек получает отклик пользователя и ререндерит страницу целиком.
В реакте полный ререндер по той же причине — повторяется логика работы бекенда. Вдом потом прикрутили, чтобы он не тормозил.
Неумеющие писать азы будут творить хаос на любом стеке.
Это не так. Одной из мотиваций разработки view.tree было как-раз не позволить "не умеющим писать азы" сотворить хаос. Именно поэтому там, не смотря на всю гибкость идиом, семантические отступы, жёсткий исключительно декларативный синтаксис и статическая типизация.
Правильную архитектуру можно и на Брейнфаке написать.
Куда важнее на чём нельзя написать неправильную.
Конечно же, есть, иначе размер исходного кода будет линейно зависеть от максимального размера выводимых данных. Если размер выводимых данных не ограничен (список произвольного размера) — у вас была бы бесконечная программа.
Еще раз, математический факт — если на уровне языка нет рекурсии и других подобных вещей, то существует некая константа c такая, что ф-я с кодом длины N не может вернуть результат по длине превышающий cN.
На вашем языке можно вывести список произвольной длины? Можно. Значит, там есть циклы. Та конструкция, которая выводит данный список — и есть цикл.
С чего бы вдруг? Вполне является, ведь она делает то же самое, что делает цикл.
То есть, циклы у вас все-таки есть, и все соответствующие проблемы — тоже есть.
Например — вполне же можно вывести список внутри списка и получить O(n^2)?
O(n^2) получить нельзя, так как объём вывода пропорционален размеру экрана, который является константой. Но даже в пределах экрана это будет лишь O(n) так как опять же, нет синтаксиса для организации квадратичной сложности.
Давайте не выдумывать свои определения. Цикл — это синтаксическая конструкция.
Вы софистикой занимаетесь. Все, что эквивалентно такой конструкции — это тоже цикл. Рекурсии разного вида, гото и т.д.
O(n^2) получить нельзя, так как объём вывода пропорционален размеру экрана, который является константой.
А что, вывести целиком ваш фреймворк в принципе не позволяет? И поиск не работает, значит?
так как опять же, нет синтаксиса для организации квадратичной сложности.
Ну как нет? Еще раз — вывел список внутри списка. Все, O(n^2).
Да и это даже не обязательно. Можно просто вывести один список длины O(n^2).
Или можно вывести таблицу. Тоже сложность будет квадратичной.
Все, что эквивалентно такой конструкции — это тоже цикл.
Это не так. Хвостовая рекурсия может быть преобразована в цикл, но сама по себе циклом не является. И тем более, если она не хвостовая.
Рекурсии разного вида, гото и т.д.
Этого всего тоже нет.
А что, вывести целиком ваш фреймворк в принципе не позволяет?
Пока что позволяет, но для этого надо специально приложить усилия.
И поиск не работает, значит?
Браузерный поиск по всем текстам на странице? Разумеется.
Еще раз — вывел список внутри списка.
Вы не сможете вывести один список в более чем одно место.
Можно просто вывести один список длины O(n^2).
Вы не сможете создать такой список средствами языка.
Или можно вывести таблицу. Тоже сложность будет квадратичной.
Двумерность отображения таблицы не делает её квадратичной.
Это не так. Хвостовая рекурсия может быть преобразована в цикл, но сама по себе циклом не является.
Она эквивалентна циклу, с-но, в рамках контекста обсуждения — это то же самое, что и цикл. Т.к. с ее помощью можно сделать все, что можно сделать при помощи цикла ака "хаос". А вы занимаетесь глупой софистикой.
Пока что позволяет, но для этого надо специально приложить усилия.
Так и написание рекурсии/цикла требует приложить усилия.
Браузерный поиск по всем текстам на странице? Разумеется.
И как он работает, если страница не загружена?
Вы не сможете вывести один список в более чем одно место.
Зачем один? n списков.
Вы не сможете создать такой список средствами языка.
Вы имеете ввиду, что не смогу сделать данные? Так это не важно.
Двумерность отображения таблицы не делает её квадратичной.
Если у вас количество строк равно количество столбец — делает.
Так и написание рекурсии/цикла требует приложить усилия.
Речь о дополнительных усилиях сверх необходимого для решения задачи. Условный джун не станет тратить дополнительное время, чтобы сделать хуже, чем у него получилось изначально.
И как он работает, если страница не загружена?
Разумеется не работает. Он такой никому не нужен. А добавить фильтрацию — плёвое дело.
Зачем один? n списков.
Их не от куда взять опять же.
Вы имеете ввиду, что не смогу сделать данные?
Не важно какой список. Вы можете получить список, передать список. А средств изменения его размерности нет.
Если у вас количество строк равно количество столбец — делает.
Опять же не сможете сделать это средствами языка.
Речь о дополнительных усилиях сверх необходимого для решения задачи.
Если задача решается без цикла, то соответствующие усилия и будут сверх необходимого.
Разумеется не работает.
Зачем же вы выше соврали, что работает?
Не важно какой список. Вы можете получить список, передать список. А средств изменения его размерности нет.
Так кто мешает передать список длины O(n^2)? Или список списков?
Опять же не сможете сделать это средствами языка.
Не смогу вывести такую таблицу (данные полагаем готовыми)?
Давайте заканчивать этот бессмысленный спор. Я вижу вы и сами уже не особо следите за тем, что спрашиваете, и что вам отвечают. Упомянутый язык — не язык общего назначения, а весьма ограниченный DSL, позволяющий любому верстальщику, не умеющему в циклы и условия, собрать приложение любой сложности
Вы либо крестик снимите, либо трусы наденьте.
Ограниченный дсл — он ограниченный, и никаких приложений любой сложности вы на нем никогда не напишете.
Если ваш дсл запрещает "творить хаос", то вместе с творением хаоса он запрещает еще много чего. То есть возвращаемся, вобщем-то, к тому, с чего начали — или ваш язык вам разрешает творить хаос, или его потенциальная полезность очень резко падает.
Ну как бы HTMLLabelElement.htmlFor, Element.className. Стандарт.
М1. Дубляж кода это плохо.
Не всегда, если необходимость в скорости создаваемого решения, то можно пренебречь этим правилом. И любые оптимизации лучше всгда делать после активной фазы разработки. Дословно: сделал на черновую с дублированием кода, со сломанной архитектурой — работает, и это уже хорошо. Если необходима следующая итерация разработки, перед этой итерацией или в процессе — плохой код должен быть реструктуризирован. Делать заблаговременные оптимизации — плохо, потому что ты никогда не можешь сказать о жизненном цикле фичи наверняка и о ее ценности. Цена ее разработки может привышать КПД на выходе, тогда зачем мы тратили время на ее архитектуру, если фича имеет минимальную ценность?
По поводу разделения Html, js, css, мне всё равно импонирует подход vue, то что весь компонент, конкретно его стили, и внутрений скриптинг, типо замороченых анимаций по клику, пишутся в одном файле, и если я захочу переписать полностью один вид кнопок, не затрагивая остальные, мне нужно ходить в общий css, я это могу сделать в одном файле, а в глобальный css вынести те самые переменные (css custom properties) цветов, шрифтов, отступов, теней и всего остального. Я пока только изучаю vue, но насколько я понимаю проблем с тем что бы забрать значения этих переменных из глобального css не будет. Именно по этой причине я начал учить Vue вместо реакта или господи помилуй Angular
Именно по этой причине я начал учить Vue вместо реакта
В реакте никто не мешает реализовывать такой же подход.
Ну акцент на "можно реализовать" а во vue это есть из коробки, это не делает реакт хуже, и не означает что я не стану его учить в будущем)
М2. Всегда надо думать на 100 шагов вперед.
Никогда не надо, потому что в 10 случаях из 10 спустя неделю то что вы там понапридумывали уже после шага эдак пятого не будет иметь ничего общего с реальностью. И вообще — YAGNI.
Пока вы продумываете 100 шагов, ваш конкурент выводит на рынок свой продукт.
Вы же не думаете, что языки/платформы/экосистемы родились сразу такими, какие сейчас есть? Ими же кто-то вначале пользовался и говорил, что тут неудобно, а там нужно все переделать. А попользоваться невозможно, пока код не написан.
Те, кто разрабатывают язык/платформу/экосистему/фреймворк, вынуждены думать и на 100 и на 1000 шагов вперёд.
И даже в этом случае ни на 100, ни на 1000 думать не надо, т.к. процесс разработки будет долгий и пока вы дойдете до 50 шага, все что вы придумали — надо будет выкинуть на помойку.
Безусловно, такие задачи, когда ТЗ есть и не меняется — существуют, но это исключения, признаем честно.
Продумывать — это учитывать возможные изменения в том числе. Если вам пришлось всё выкинуть — значит вы плохо продумали. В заказной разработке ТЗ вообще практически не меняется. А даже там, где оно меняется, происходит это не столь кардинально, чтобы инженер с опытом и варящим котелком не смог это предусмотреть.
Вы никогда не пройдёте лабиринт, смотря лишь на одну итерацию вперед.
Продумывать — это учитывать возможные изменения в том числе.
Почти наверняка те изменения, которые вы предполагали, делать не придется, а придется делать те, что вы не предполагали.
В заказной разработке ТЗ вообще практически не меняется.
Ну это редкое исключение. Если ТЗ не меняется — разработка, вообще говоря, тривиальна и тут обсуждать просто нечего. Берешь ТЗ и работаешь.
чтобы инженер с опытом и варящим котелком не смог это предусмотреть.
Так скорее всего то, что вы предусмотрели, просто не нужно будет. То есть вы потратите время зря.
Проект на пол года. Необходимый объём функциональности известен. Детализированного ТЗ, разумеется, нет. Разботаем по скраму. Я реализовал функциональность А (которая в спринте) и В (которая ещё не в спринте), на основе обобщённого кода С. По результатам нескольких дней бодания на код-ревью: выпиливаем В, так как он не в спринте; выпиливаем С, так как вынос части кода из А — переусложнение; соответственно перепиливаем А, чтобы он не зависел от С. Через пару итераций потребовалась функциональность В, которую не долго думая сделали копипастой А.
И делалось всё это под эгидой «мы же не знаем что там будет через месяц, всё может поменяться, надо писать минимально необходимый код, без какого-либо задела на будущее».
И вновь у нас с вами разный бэкграунд и, как следствие, разное представление о «скорее всего».
Так я вроде сразу сказал что в некоторых областях, действительно, бывает иначе. Но в среднем по индустрии — это все на гране стат. погрешности.
Давайте я вам лучше расскажу об одном маразматичном случае…
Так в итоге беспричинно YAGNI нарушили, оттуда и маразм. По YAGNI следовало реализовать А на основе С, и В (раз уж он уже был сделан) не выпиливать ни в коем случае. То есть, фактически, сделать так, как вы сделали изначально.
Ну и вопрос, почему в итоге нельзя было откатиться на ваш оригинальный коммит — опять же, это было наиболее простое решение, которое и следовало предпочесть при прочих равных.
Но в среднем по индустрии
И соответственно у нас с вами разное представление о средней индустрии. Вообще, мерить среднюю температую по больнице — неблагодарное занятие.
беспричинно YAGNI нарушили
Это всё не важно. Я проиллюстрировал до чего доводит отсутствие стратегического планирования. Эджайл в современном представлении многих — это не "менять планы по мере поступления данных", а "не строить планов вообще". Жить "здесь и сейчас", безусловно проще. А если это ещё и доктрина индустрии/компании/команды, то вообще снимает с тебя какую-либо ответственность. Но стратегия эта всё же так себе.
почему в итоге нельзя было откатиться на ваш оригинальный коммит
Интерфейсы разные. Пришлось бы перепиливать "не относящуюся к задаче функциональность". Да и делал уже не я.
И соответственно у нас с вами разное представление о средней индустрии.
А при чем тут представление?
Просто программирование сейчас, когда все более важны нефункциональные требования — это в первую очередь управление проектами, даже если вы джун.
Если у вас "все хорошо" — тут и управлять нечем, с-но и работы по сути нет. А если работы нет — то что тут обсуждать? С-но, обсуждаем те случаи, где есть содержание.
Это всё не важно. Я проиллюстрировал до чего доводит отсутствие стратегического планирования.
Нет, это как раз важно. Никакое стратегическое планирование не помогло бы вам избежать описанной ситуации, если вы сперва запланировали, что В и С — ненужно, а потом — что оно нужно. А вот следование YAGNI — помогло бы.
Эджайл в современном представлении многих — это не "менять планы по мере поступления данных", а "не строить планов вообще".
При чем тут "не строить планы вообще"? Речь о том, чтобы не делать то, что делать не нужно.
Важно понимать, что для данного конкретного проекта является требованиями, а что — просто фантазии.
Это у вас спросить надо, вы ж спорить кинулись. Я только отметил, что в современных реалиях "думать на 1000 шагов вперед" — глупость.
При чем тут какие-то проповеди — непонятно.
И я поправил, что ваше категоричное заявление является слишком однобоким взглядом на вещи.
Опять же, с моей стороны никаких категоричных заявлений не было, то, что исключения бывают — было сразу понятно из контекста, и далее я это сразу явно пояснил.
Это уже вы начали воевать с ветряными мельницами.
Во-вторых — я у себя увидел, что KISS & DRY — это не 100% правила, это переходы между состояниями: когда я пишу новую функциональность (обычно на уровне класса\файла), то я пишу «как пишется», без оглядки на повторяемость и даже копипасту. Происходит как бы «распухание кода». После того, как функциональность написана и «вроде работает» — просматриваю код (и написанный только что, и старый, похожий на этот) еще раз, на предмет рефакторинга — убирания повторов, переименования функций\параметров, порядка их передачи и вычисления, вынос в утилиты и прочая «выжимка и отсушка».
А когда у вас это уже 5-20ый проект, то у вас уже накопился запас классов в папке «utils», и можно его оформлять в виде либы или фреймворка (но это согласитесь, уже другой уровень).
YAGNI хорошо соблюдать для реализаций, но он не «серебряная пуля». Например — лучше сразу и наперед продумать и написать все интерфейсы — чтобы понять архитектуру (происходит ли «стыковка» проекта, или в ТЗ есть пробелы или конфликты) и разделить ее для разделения работы команды.
Так YAGNI применяется тогда, когда нет причин не применять. Если вы можете в данной конкретной точке назвать ясную и понятную причину, почему надо сделать Х — делайте.
Если же вы причину назвать не можете, а вместо нее у вас получаются только пространные рассуждения из разряда: "а вдруг когда-нибудь блаблабла" — Х вам не нужен. По крайней мере не нужен в данный момент.
С-но, это верно для любого принципа — если вы можете объяснить, почему в данный конкретный момент будет правильно нарушить KISS или DRY — смело нарушайте.
Декомпозиция проекта для frontend'a