Comments 15
Этот компонент является монолитом, потому что он был спроектирован и написан для использования в одном месте в одном приложении только один раз.
И чё в этом плохого конкретно для этого компонента?
Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.
Чем больше возможностей для повторного использования ваших компонентов и функций, тем вы быстрее.
Ну давайте тогда все компоненты делать переиспользуемыми, с десятками пропсов и сотнями if else внутри, чтобы потом красноглазить по вечерам и фиксить там баги.
Тут идет речь про то, что ты можешь вынести определенный функционал и использовать его в других местах или проектах чтобы не тратить время на написание однотипного кода.
Монолит = медленное написание кода.
Многоразовые строительные блоки = быстрое написание кода
Вы удвоите скорость написания кода, если отрефакторите код в повторно используемые строительные блоки.
Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.
Тут речь о том, что надо писать ВСЕ компоненты так, чтобы их можно было переиспользовать много раз в коде, с чем я искренне не согласен. Если ваше приложение чуть сложнее чем каталог продукции или личный блог, этот путь развития никуда вас не приведёт.
Огромная статья про пользу переиспользования, и ни единого упоминания DRY, ну как так? А еще этот стиль "Ух ты, какой всплеск сложности! Не бойтесь, я научу вас.", как будто автор с малолетними дебилами разговаривает.
Я наверно огребу минусов, но, вне зависимости от языка, скорость написания кода не является проблемой разработки.
Не осилил статью, но расскажу немного про преждевременную оптимизацию. На практике очень часто бывает так что требования меняются по ходу разработки и жизни проекта. Вы много часов потратите на "переиспользуемые" блоки, а потом требования изменятся. Напишите сначала монолит, который возможно и некрасивый, но работает. После того как проект устаканится или вам выделят время на рефакторинг занимайтесь им. Позже с опытом у вас само собой появятся эти "перписпользуемые" практики написания кода.
Как по мне TS незаменим на бекенде, для компонентов если они "правильно" написаны (pure function) TS оверхед, который усложняет и замедляет разработку. ИМХО.
Если вас действительно интересует качество вашего кода, читайте книжки: "совершенный код", "чистый код". "Рефакторинг" Фаулера кстати очень занятная книга по теме.
После того как проект устаканится или вам выделят время на рефакторинг занимайтесь им.
Это — везение. Может быть и по другому: монолитный лапшекод так и будет тянуться и душить разработчика. Становясь всё более громоздким и запутанным.
Понятно, что с первого и со второго раза не получится декомпозировать по красоте, даже когда ТЗ хорошо проработано. Однако стремиться и прикидывать в общих чертах следует. Ну и просто соблюдать те же принципы SOLID, к примеру, — тогда первая версия кода не будет совсем грустной.
для компонентов если они "правильно" написаны (pure function) TS оверхед, который усложняет и замедляет разработку. ИМХО.
Смотря какой фронт. Если сложный одностраничник, то TS совсем не оверхед. А уж если используется WebStorm или VSCode, то машинопись реально тащит, о чем много раз говорилось.
Если рефакторинг занимает больше времени чем выполнение текущих задач — его стоит отложить на тот самый специальный спринт (если он есть).
С развитием навыков и знаний (про SOLID про DRY, TDD, BDD, DDD и тд) у тебя уже изначально не будет получаться «лапшекод», но нужно понимать грань между временем решения задачи и времени на проектирование этого решения. В случае если ты обычный разработчик а не архитектор, если время проектирования решения занимает больше чем время решения — лучше выбрать монолит, грубо говоря если сходу не можешь прикинуть как что должно быть правильно — накидай монолит, который в этот же день начни раскидывать по «правильному», главное что бы он заработал и решал поставленную задачу :)
Сколько раз было, когда «отрефакторишь» кусок чтобы все было DRY, аж прямо суше некуда, и тут, внезапно кода стало больше и понимать его стало сложнее…
Советы из статьи только замедляют разработку, потому что добавляется бесконечное снование по файлам, чтобы отредактировать связанную функциональность.
Можно здорово сократить код и упростить свою работу, если заменить вот этот код:
<BrowserItem
fullname={item.fullname}
image={item.image}
linkToBrowser={item.linkToBrowser}
minMemory={item.minMemory}
// и так далее
changeDescription={() => changeDescription(item.description)}
/>Вот таким кодом
<BrowserItem
browser={item}
changeDescription={() => changeDescription(item.description)}
/>Вот эта оптимизация реально повысит скорость разработки.
Как было правильно замечено в комментариях выше, все хорошо в меру, преждевременно оптимизировать не стоит.
<BrowserItem
{...item}
changeDescription={() => changeDescription(item.description)}
/>
Вот таким кодом
Справедливости ради, это прям отличный вариант при использовании TS, потому что структура объекта описана типом. Передавая объект в JS вы рано или поздно столкнётесь с тем, что там что-то лишнее или чего-то не хватает, а у чего-то вместо строки передан номер (передавая отдельными пропсами типы можно кое-как порешать PropTypes). В статье это не очень явно, но указано.
Если лимитирующий фактор скорость написания — нужно менять работу, вы из нее выросли
Удвойте скорость написания кода на React с помощью этих простых трюков