Поговорим о том, что вы и так уже знаете.
Это моя первая статья на Хабре и я не писатель. Но взглянув на Фронтенд-2018: итоги года, руки потянулись в sublime и начали писать.
Любая сложная задача состоит из простых. Умение правильно делать декомпозицию — необходимость.
Буду вести рассуждение на примере большинства проектов из личного опыта.
Уверен, вы скажете "А у нас не так и вообще react это быстро, логично и читабельно, генерировать стили при помощи js — не какая-то там надстройка, это модно, а фронтендщики не нужны, ибо наш бэкендщик Феофан сделал отличную форму на php", но все же.
Обозначение
Г1. Гении, которые это могут, являются исключениями, частным великолепный случаем.
М*. Мысль
Это можно не читать
Итак, начнем!
М1. Дубляж кода это плохо.
М2. Всегда надо думать на 100 шагов вперед.
Например, на старте проекта берем в расчет его состояние лет через 5.
Очевидно, запуская социальную сеть сразу можем сказать, что помимо веб версии будут мобильные приложения, десктоптные приложения. Отсюда…
М3. Серверная часть должна писаться только один раз. (М1)
А так как у нас есть веб версия, мобильная, десктопная, то…
М4. Серверная часть занимается данными.
Серверная часть не должна решать, какую кнопку нарисовать и какого цвета она должна быть.
Шаблон письма или html файл, который [может] подгружается при загрузке страницы для индексации поисковиком — это тоже работа с данными. Увы там приходится манипулировать html (из-за требований к индексации, например), но это уже другая проблема.Вот тут произошло первое разбиение проекта: откололась серверная часть. Я не буду рассуждать на каком языке написана, как устроена архитектура (добрым словом поминаю MVC). Это не мое дело ибо…
Фактически можно было бы передавать первоначальный набор файлов (html, js, css) и данные. Т.е. и тут бэк не занимается версткой.
М5. Каждый должен заниматься своим делом
Фуллстеки покрывают какую-то часть проектов и тут с этим пунктом вы можете и будете конечно спорить, но обращаясь к (М2) моя позиция тут сформирована: дешевле иметь двух профессионалов своего дела, чем переписывать проект через год. Разумеется есть гении (Г1), которые поспевают везде, но таких единицы, а значит нельзя их брать в рассуждениях «Как должно быть».
Я так же отколю от этого пирога ветку Дизайнера, Юзабилиста и ко.
Поймите правильно, нормальный фронтендщик может самостоятельно накидать макет «верстая», ориентируясь на миллион аналогов и свою фантазию, но мы же по (М2) говорим о серьезных проектах, так что не льстите себе :) (Г1)
Отлично, у нас есть данные (api, все нужные методы итд итп.), у нас есть макеты — и начнем.
В виду современных реалий — я ввел бы еще одно разветвление. Увы и ах, но огромная доля современных фронтендщиков либо не умеют работать с версткой, либо не знают js. Я провел огромное количество собеседований и это странно наблюдать. По этому фронтов можно разделить на «верстальщиков» и «неверстальщиков??».М6. Разработка должна вестись больше чем в одном файле
Скажете очевидно? Да, очевидно!
М7. Фронт делится на 2 части: та, что работает с данными, и та что их отображает.
У нас может отсутствовать та или иная часть. Например: быть только отображение (статическая страница) или быть только данные (скрипт в консоли и т.д.).
Тут предлагаю абстрагироваться и представить: вы человек-пиццерия. Принимаете звонки, раскладываете красиво сыр и отвозите покупателю. Логика подсказывает, что вы не особо эффективны (М1). Но если с вами работало бы еще 2 человек то было бы куда круче! Один принимает звонки (работает с данными), второй отвозит (представление), третий раскладывает сыр красиво :) (стилизация представления)
Уже слышу «КЭП» из 2012, «очевидно», но давайте еще раз…
М8. JS — это работа с данными.
Звонит бэкенду, принимает заказ и ему абсолютно все равно, как там уложен сыр. Может пиццы и вовсе не существует, может он просто делает опрос пиццы года?
М9. HTML — представление
Показывает пиццу клиенту, а так же принимает фидбэк (деньги, отзывы) и передает их администратору (JS).
М10. CSS — стилизация представления
Делает нужные отступы между двумя кусочками сыра.
Заметьте, администратор на телефоне не говорит как правильно укладывать сыр, а пицца не содержит чьего то разговора по телефону. Любая попытка манипулирования стилями при помощи js, или манипулирование js при помощи html — это изначально надстройка, это изначально плохо. Классы и обработка событий придумали не просто так.И так, за что отвечают js, css, html — мы разобрались.
Вы можете проставить класс: пепперони, салями, но не в вашей компетенции решать, как лежать сыру пепперони.
Вы можете проставить bind: если тебя пнули, не заплатили, скажи администратору. Но никак не стоит пихать администратора в пиццу. Он один, а пицц много! Если у вас пицц столько же сколько операторов, то М1.
Теперь можно задавать целые ветки вопросов: как правильно готовить пиццу, как быстрее и удобнее доставить ее и как разговаривать в клиентов по телефону.
Мне хочется как то определить модное нынче слово "Компонент". По факту даже обычная кнопка это уже «Компонент», но я переопределю это на очевидных примерах. Кнопка это кнопка, а компонент:
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 и то, чего нельзя называть.
Всем хорошего дня!
Комментарии (63)
dark_ruby
19.12.2018 12:54вся статья ужимается в одну фразу — separation of concerns.
JustDont
19.12.2018 12:55Тут недавно пробегал товарищ со статьей про css-in-js, так вот он тоже SOLID поминать любит. Что не мешает ему пихать стили в код и считать это очень хорошим.
justboris
19.12.2018 14:27Separation of concerns бывает разная
С одной стороны, автор выступает за компонентный подход (картинка справа), но в М19 почему-то внезапно требует разделять HTML/CSS/JS. При этом почему именно так надо, не объясняется.
amiKonst Автор
19.12.2018 14:53За обе картинки, ибо они друг другу не противоречат. О объяснение в М22 М17 М13 М8 М1 М18. На самом деле вся статья написана именно с этим посылом: хватит их смешивать
justboris
19.12.2018 15:01Я вижу в этих пунктах не обяснение, а наставление: "собирать в одном месте HTML/CSS/JS — плохо, понятненько?"
Не хватает раскрытия темы, что именно пойдет не так, если вашим правилам не следовать. Я, например, использую styled-components, и мои проекты успешно развиваются, фичи делаются, а зарплата растет. И, наблюдая за своими коллегами, вижу что не я один такой. Чем нам могут быть ваши правила полезны?
amiKonst Автор
19.12.2018 15:11Мне кажется в статье написано несколько иначе, чем «Понятненько», видимо сквозь строки читалось.
Почитайте вот эту статью например, там расписано подробнее habr.com/post/417707
То, что ваши проекты развиваются не означает, что они не развивались бы, если вы писали код иначе.justboris
19.12.2018 15:27Я занимаюсь фронтендом с 2011 года (чуть дольше чем зарегистрирован на Хабре), и успел поработать с разными стеками, начиная от jQuery и GWT, и заканчивая современными, типа Angular и React. CSS и JS мы тоже отдельно держали, потому что так было принято в то время.
После всего этого опыта подход styled-components мне кажется наиболее практичным на данный момент. В будущем, нам завезут веб-компоненты и ShadowDOM, и ситуация может поменяться снова, но пока работаем с чем можем.
Aingis
19.12.2018 14:25+2
А Реакт — это вообще не про HTML. И даже JSX, который, видимо, имеется в виду.Реакт — самое отвратительное по читабельности, что я видел!
Во-первых, Реакт можно писать и без JSX (хотя не очень понятно зачем). Во-вторых, JSX – это вообще-то про компоненты. Это код, HTML генерирующий, и — что важно — связывающий с данными. Просто его синтаксис настолько декларативен, что его максимально приблизили к XML, а связанность с данными делает бессмысленным какое-либо отделение.
Это добавляет удобства и снижает порог вхождения, но это ни разу не HTML. Даже атрибуты имеют синтаксис из DOM. Например,classNameвместоclassилиhtmlForвместоfor. А тот же HTML-шаблон приложения, например, как правило добавляется отдельно.amiKonst Автор
19.12.2018 14:58Очередная прослойка, генерирующий html код, с надуманными новыми правилами и болью в глазах. Ну давайте честно, больно на это смотреть. И главное «зачем» я до сих пор не понял. Правильная архитектура кода дедовскими методами дает абсолютно понятный и предсказуемый проект. А в реакте неумеющие писать азы фронты творят вообще нечитаемый хаос. Да, хаос подходящее слово.
nexus478
19.12.2018 15:08Ну давайте честно, больно на это смотреть.
«Больно» слишком субъективное понятие, кому-то вон не больно. Может все-таки развернете свою мысль и расскажете о конкретных проблемах?amiKonst Автор
19.12.2018 15:21
Вот чисто эксперимент: вы считаете это нормально?JustDont
19.12.2018 15:59Так вы подсветку в редакторе настройте нормально, и сразу станет читабельнее.
Не то, чтоб я сильно болел за JSX, но вы высасываете проблему из пальца.amiKonst Автор
19.12.2018 16:10А вопрос даже не только в подсветке, это будто сварить пельмени в чайнике: да, так можно, да так делают студенты, но есть кастрюля предназначенная для этого, а в чайнике я чай сделаю.
caffeinum
22.12.2018 10:11То, что вы не понимаете, зачем это сделано, не меняет того, что кому-то удобно так работать.
Идея Реакта, как я вижу – перенести трудности разработки с разработчика на процессор пользователя. Да, мы теряем в 2-3 раза в производительности, зато теперь даже верстальщик может написать огромный SPA. При этом, если он не будет нарушать гайдлайны типа «не меняйте this.state напрямую», то оно даже тормозить не будет.
Иногда нужно пересмотреть свои личные предпочтения, потому что бывает, что они обманывают.
jMas
20.12.2018 23:18Реакт хорош для своих задач, как и HTML без CSS, HTML с CSS, HTML+CSS+JS. Прежде всего реакт предлагает инструменты для упрощения массовых операций с DOM. Простыми словами: это инструмент для патчинга DOM (массовых точечных изменений DOM-нод), который накладывает собственные ограничения в виде синтаксиса JSX. Предлагаю задать себе вопрос: как мне сделать 20 тысяч обновлений в DOM, но которые заставят обновиться только
textContentв нужных DOM-нодах, без обновления всего (уже построенного) дерева DOM?
Обычный HTML+DOM не могут ответить на этот вопрос, поэтому и существует реакт, которые дает разработчику абстракцию, которая позволяет не думать (или думать меньше и предсказуемей) о вопросах производительности. Разработчики сознательно принимают синтаксис JSX, потому что видят профит в другом. И вообще, синтаксис часто — это вкусовщина и в реальности значимым является: может ли технология/подход "X" делать тоже самое, но: быстрее/безопасней/предсказуемей. Не фокусируйтесь на длинне ручки, а фокусируйтесь на том как она пишет.
amiKonst Автор
19.12.2018 15:23Лично я, например, сразу вспоминаю вот это
Druu
22.12.2018 04:49И вспоминаете не даром, ведь jsx изначально был сделан для php, а сам реакт — фреймворк, предназначенный для упрощения портирования существующего php-кода на js (примерно такого, как вы выше написали). С-но, перед фейсбуком стояла задача сделать фреймворк такой, чтобы архитектура на фронтенде максимально повторяла архитектуру существующего бека на пыхе, ее они и решили. Оттуда и все родовые травмы — что можно ожидать от фреймворка, созданного по принципу "пишем на js будто на пыхе"?
Aingis
19.12.2018 16:00Неумеющие писать азы будут творить хаос на любом стеке. Это не проблемы технологии или фреймворка, они другие задачи решают.
Правильную архитектуру можно и на Брейнфаке написать. Только это займёт много времени, и больше никто не захочет поддерживать.
Современные фреймворки помогают упрощать и тем самым ускорять разработку. Они никак не отменяют и не мешают правильной архитектуре, даже немного помогают, благодаря разделению по компонентам из коробки.vintage
21.12.2018 20:31Неумеющие писать азы будут творить хаос на любом стеке.
Это не так. Одной из мотиваций разработки view.tree было как-раз не позволить "не умеющим писать азы" сотворить хаос. Именно поэтому там, не смотря на всю гибкость идиом, семантические отступы, жёсткий исключительно декларативный синтаксис и статическая типизация.
Правильную архитектуру можно и на Брейнфаке написать.
Куда важнее на чём нельзя написать неправильную.
Aingis
21.12.2018 11:10+1Кстати, если вам не нравится такое смешение JS-кода с XML, то вот есть проект HTM (Hyperscript Tagged Markup), который использует для этой цели теговые шаблоны, что делает его полностью корректным скриптом. Компиляция не требуется. Можно использовать с Преактом.
amiKonst Автор
19.12.2018 15:03JSX className htmlFor — больше названий, надо определенно больше названий и усложнений! Программисты ведь так любят создавать свои названия, писать свои фреймворки. Настолько любят давать все новые названия, что джуны бьются головой об стену, не зная что учить :)
PaulMaly
19.12.2018 20:35Вопрос к автору, вы сколько лет фронтендом занимаетесь, что успели так «закостенеть»? Неужели это ждёт нас всех…
jMas
19.12.2018 23:34+1М1. Дубляж кода это плохо.
Не всегда, если необходимость в скорости создаваемого решения, то можно пренебречь этим правилом. И любые оптимизации лучше всгда делать после активной фазы разработки. Дословно: сделал на черновую с дублированием кода, со сломанной архитектурой — работает, и это уже хорошо. Если необходима следующая итерация разработки, перед этой итерацией или в процессе — плохой код должен быть реструктуризирован. Делать заблаговременные оптимизации — плохо, потому что ты никогда не можешь сказать о жизненном цикле фичи наверняка и о ее ценности. Цена ее разработки может привышать КПД на выходе, тогда зачем мы тратили время на ее архитектуру, если фича имеет минимальную ценность?
neko911
21.12.2018 13:00По поводу разделения Html, js, css, мне всё равно импонирует подход vue, то что весь компонент, конкретно его стили, и внутрений скриптинг, типо замороченых анимаций по клику, пишутся в одном файле, и если я захочу переписать полностью один вид кнопок, не затрагивая остальные, мне нужно ходить в общий css, я это могу сделать в одном файле, а в глобальный css вынести те самые переменные (css custom properties) цветов, шрифтов, отступов, теней и всего остального. Я пока только изучаю vue, но насколько я понимаю проблем с тем что бы забрать значения этих переменных из глобального css не будет. Именно по этой причине я начал учить Vue вместо реакта или господи помилуй
AngularFree_ze
21.12.2018 13:14Именно по этой причине я начал учить Vue вместо реакта
В реакте никто не мешает реализовывать такой же подход.neko911
21.12.2018 13:21Ну акцент на "можно реализовать" а во vue это есть из коробки, это не делает реакт хуже, и не означает что я не стану его учить в будущем)
Free_ze
21.12.2018 13:30Описываемая проблематика мне кажется фичей CSS, нежели генерации разметки.
Возможно, что я заблуждаюсь и если вы мне укажите направление поиска информации о том, что это позволяет делать некая супер-фича Vue, то я буду признателен (=
Druu
22.12.2018 04:43М2. Всегда надо думать на 100 шагов вперед.
Никогда не надо, потому что в 10 случаях из 10 спустя неделю то что вы там понапридумывали уже после шага эдак пятого не будет иметь ничего общего с реальностью. И вообще — YAGNI.
Пока вы продумываете 100 шагов, ваш конкурент выводит на рынок свой продукт.vintage
22.12.2018 09:29Разработка софта не ограничивается стартапами-однодневками. Те, кто разрабатывают язык/платформу/экосистему/фреймворк, вынуждены думать и на 100 и на 1000 шагов вперёд. Так как шанс взлететь есть только один.
caffeinum
22.12.2018 10:18Есть альтернативный способ, которым много кто успешно достигает успеха: думать на 100 шагов вперед, а код писать вперед только на два шага, и выкидывать продуманные 100 шагов.
Вы же не думаете, что языки/платформы/экосистемы родились сразу такими, какие сейчас есть? Ими же кто-то вначале пользовался и говорил, что тут неудобно, а там нужно все переделать. А попользоваться невозможно, пока код не написан.
vasja0441
не всё что хочется написать следует публиковать (С) Я.
JustDont
Вполне полезная статья, пусть и для фронтэндщиков с опытом это будет набором банальностей.
Про банальности тоже надо писать, с опытом разработки не рождаются.
amiKonst Автор
Это набор банальностей, очевидных и понятный вещей, но почему то же появляются «сеньёры», пишущие стили и html в js. Иногда нужно просто остановиться и сказать: ребят, посмотрите что вы наделали! Кто за этим убирать будет?
JustDont
Если эти люди делают что-то полезное для бизнеса — то ничего принципиально страшного в этом нет.
Пример: мой CTO, когда добирается до непосредственно программирования, что иногда случается — пишет код, который бы на пуллреквесте разнёс бы в пепел даже программист средней въедливости.
Вот только код, который он пишет — это обычно базис для вещей, в дальнейшем приносящих компании многомиллионный доход. А прибрать в его коде приберут и другие.
amiKonst Автор
Только вот молодое поколение учится на этих примерах и потом доказывает, что css-in-js это правильно и быстро, а от реакта не болят глаза. Нет претензий к курицам, несущие золотые яйца. Там и правда можно нанять целую команду пофигистов, прибирающей за ней. Только выносить это все на публику не правильно.
parmactep
React и React, который видели вы, это сильно разные вещи. Никто не заставляет использовать в React css-in-js.
Free_ze
Из того, что программист пишет полезный плохокод не следует, что именно такой стиль приносит выгоду. Напротив, можно привести гораздо больше примеров, как из-за кривого «базиса» попадают на деньги или даже заваливаются довольно крупные проекты.
Или не приберут и будет висеть технический долг.
А что мешает писать сразу нормально?
JustDont
Эм. Быстро, качественно, дешево, pick two? Когда некий «дива»-программист набрасывает концепт чего-то прибыльного (и обычно сложного) — это может быть «быстро, дешево», либо «качественно, дешево». Ну и мы все помним историю про программиста Васю, который пилил свой качественный продукт, вот только он уже был никому не нужен ко времени релиза.
Вот поэтому.
sergof
Это просто многословное оправдание неприглядной строны. По гамбургскому счету код либо говно либо не говно. В концепции «да мой код — говно, я знаю, но тогда по-другому было нельзя, а сейчас я уже привык, на этом говне напилено много всего и без него теперь никак нельзя» нет ничего привлекательного. Для того чтобы избегать таких концепций и нужно заранее планировать, пользуясь опытом уметь предсказывать. Лучше потратить лишнее время на планирование чем на доработки.
JustDont
Это просто реальность. Вы, впрочем, можете с ней не соглашаться, ваше право.
Если лишнее время на планирование оборачивается потерей рыночной доли, а доработки потом неспешно делаются силами мелкой команды не особо звёздных программистов — нет, не лучше. Как бы вам такой ответ не нравился.
Заранее планировать с хорошим соответствием можно обычно либо несложное, либо уже известное. А вот планировать то, чего еще никто не делал — обычно выходит так себе даже у матёрых профессионалов.
Free_ze
То есть «звезда» пишет настолько сложный код, который даже она не в состоянии писать нормально. Потом этот write-only код должны править люди с еще более низкой квалификацией. Всё верно?
JustDont
Вы зря мешаете в кучу «нормальность» и «сложность». Код может быть как архитектурно кривой, но при этом чистый в мелочах (работает, проходит пуллреквесты у любого, кто не задумывался об высокоуровневой концепции, но к дальнейшему развитию абсолютно не пригоден), так и наоборот (работает, вызовет миллиарды претензий при проверке кода, но архитектурно спланирован нормально и в дальнейшем спокойно расширяется).
Хорошие программисты, быстро пишущие сложный код — обычно пишут ближе к второму, а не к первому.
Моя мысль была о том, что концепцию, скажем, map reduce (не сейчас, а тогда, когда еще про это никто не написал) способен родить только хороший программист, в то время как красивое логирование к ней потом припишет и джун-стажёр.
Free_ze
Вроде вы все верно говорите, но начинали мы как раз с архитектурных извращений, которую потом достаточно трудоёмко выпиливать, на что вы ответили, что деньги не пахнут, хотя тут еще оказались нюансы.
JustDont
Это вы с них начинали. Я же писал именно про
то, что вы в этом прочитали «архитектурные извращения» — не моя проблема. Я этого не писал.
Free_ze
Вы ответили на комментарий про css/html в js. Проблемы подразумевались вполне конкретные.
JustDont
Ну так «конкретная проблема» css/html в js проблемой непреодолимых архитектурных извращений не является. Мне самому многое не нравится в css-in-js и инлайн-шаблонах «чего-то, напоминающего html» прямо в коде, но это работает и на этом пишутся очень сложные коммерчески успешные продукты (фейсбук ручкой машет, ага).
Free_ze
Я говорил о трудоёмкости, а не непреодолимости. Деньгами можно затыкать любые дыры, если они есть. Но они могут не успеть появиться, в отличие от проблем.
Подобные рассуждения — это систематическая ошибка выжившего. Никто не знает, какое количество потенциально успешных проектов из-за этого завалилось. Но субъективный опыт подсказывает, что шаткая база очень скоро чревата расплатой и любые крупные, даже «коммерчески успешные проекты», это сборники отборного треша, который безумно дорого поддерживать. FB — это отличный пример того, да.
JustDont
Согласен. Однако они во многие разы более объективные, чем
вот такие вот рассуждения. Вы не забывайте, что вы пытаетесь защищать не просто теоретизирование на ровном месте, но еще и субъективное теоретизирование.
Только контраргументом к этим проектам будет не «смотрите на меня, я знаю как надо!», а «смотрите на меня, у меня есть крупный коммерчески успешный продукт, который к тому же восхитительно дешев в поддержке!».
Free_ze
Вы притащили чужое высказывание из соседнего треда и утверждаете, что я его разделяю и даже защищаю. Просто прекрасно.
"Сперва добейся"?
JustDont
Это вообще-то из статьи. Но довольно показательно, что вы не поняли, откуда оно.
В критике — нет. В заявлениях — «нужно делать вот так» — таки да. Видоизменяя классику, «если ты знаешь, как нужно делать, то чего ж ты такой бедный?».
Free_ze
Да, почему-то запомнилось упоминание именно из комментариев. Хотя сути дела это не меняет — фраза не моя.
amiKonst Автор
При достижении определенного уровня, программист уже не думает «Как писать», он просто «переносит мыли о задаче на бумагу». Т.е. писать правильно не значит дольше. Как раз наоборот, правильно заложенный фундамент экономит кучу бабла
JustDont
Это всё красивая теория, разбивающаяся о переменчивость технологического стека, которая потихоньку идёт даже в весьма стабильных языках и инструментах. А если мы всё еще про фронтэнд говорим — так и вовсе смешно, потому что техстек у нас в пределах нескольких месяцев уже может «плыть».
amiKonst Автор
Да ладно Вам, любой новый фреймворк можно освоить ну максимум недели за две. Логическое решение задачи не шипко зависит от способа его записывания
JustDont
Освоить на уровне «могу слабать to do» — да. Освоить на том самом уровне, когда полностью исчезают мысли «как писать» — ну щас.
amiKonst Автор
knockoutjs, kendo ui, angular, vue etc — сколько нужно по вашему мнению времени, чтобы перейти от одного mvvm к другому?
JustDont
Ну давайте еще раз: «перейти» на уровне «могу сделать что-то простое и известное» и на уровне «могу сделать примерно всё оптимальным и не заводящим в тупик образом» — две очень разные вещи.
amiKonst Автор
ну я считаю что двух недель вполне хватит, чтобы покрыть >90% проектов. Сколько по вашему должен идти переход? Сколько нужно времени, чтобы выучить синтаксис?
JustDont
Чтоб «выучить» что-то из фронтэнд фреймворков и начать писать — это до пары недель в худшем случае, да. А если программист хороший, то и пары дней хватит.
А вот чтоб знать проблемы и ограничения фреймворка, узкие места по быстродействию, модульности, версионности — вот на это может уйти примерно дофига времени. А те, кто этого всего не знают — уж точно не находятся на уровне «просто переношу мысль на бумагу», ибо без прочных знаний лимитов как раз проще всего «закрасить себя в угол», и придти к такому состоянию продукта, когда расширяться без тотальной переделки уже нельзя.
Free_ze
Если программист не в состоянии писать качественный код быстро, какой он, к черту, сеньёр? Чем он отличается от миддла, который может фигачить костыли от недостатка опыта и эрудиции?
Проблема здоровья кодобазы сложных проектов зачастую в ошибках архитектурного планирования, когда требования меняются в процессе. Но если код — говно еще до пуша, то дело исключительно в кривых руках отдельных дарований.
Не все работают в стартапах. Зрелые компании часто готовы вкладываться в качество кода. Плохокод — это не только страдания на поддержке, это еще фракталы багов и низкое качество продукта. Вроде очевидно, но
JustDont
Стартап как компания — тут совершенно не причём. Это стартап как фаза жизненного цикла программного продукта, который случается у всех контор, делающих какие-либо новые программные продукты, от гугла до фейсбука (да, они тоже новое делают).
Да, конечно. Только это обычно происходит уже потом, когда все кривоватые и быстро слепленные proof of concept уже выкачены, иногда прямо до конечных юзеров выкачены.
caffeinum
Мне нутром не нравится, что вы говорите, прямо кипит справедливое негодование, но умом чувствую, где-то тут есть правда. У вас есть убедительные примеры, может, из личного опыта, или ссылки?