Search
Write a publication
Pull to refresh

Comments 22

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

Да, вы правы, описался. Под фреймворком я имел ввиду React в связке с другими библиотеками

Ну, вообще-то с разницей между библиотекой и фреймворком давно разобрались. :) Библиотека — расширяет возможности разработчика. А фреймворк — ограничивает. Так что дело не в дефолтной поставке, а в том, предписывает ли React определённые методы решения задач, вместо любых альтернатив или нет.

Поскольку сам я далёк от web-программирования (по крайней мере от фронтенда), то сами ответьте на этот вопрос и узнаете фреймворк он или нет.
Интересное разделение. Я всегда различал по направлению потока вызовов:
— библиотеки ты вызываешь из своего кода
— фреймворки вызывают твой код
Как говорит моя девушка-врач: «Избыток сахара вызывает сахарный диабет»…

И вот такие врачи нас лечат… Сахар не вызывает сахарный диабет. Но сахар в крови является признаком сахарного диабета. Перепутана причина-следствие. Как, в общем, и в статье…
О, это же лучшая разновидность постов о том как всё плохо в javascript и что делать никто не знает, а за сим всё

Причем описанное в посте к JS особого отношения-то не имеет.
По сути описаны проблемы в команде: не смогли договориться о style guide, не могут найти время на написание тестов и т.п.

Хотел добавить сюда варианты решения проблем, которые используются у нас в компании, но посчитал, что статья получится слишком объемлющей. В следующей своей статье я планирую написать про инструменты, помогающие поддерживать код в чистоте
UFO landed and left these words here
UFO landed and left these words here
> чему вы хотите научить остальных?
Не писать подобные «статьи» на Хабр.

А на самом деле то, что язык (и платформа) позволяет делать многое и разными способами — это же прекрасно, свобода воли, и только сила воли нужна, чтобы остановить себя (и команду) на едином стиле.
Что еще лучше — язык развивается, развиваются инструменты.

Знаете, даже обилие хейтеров, таких, как ТС, свидетельствует, что все идет очень хорошо, ибо не критикуют только то, что никому не нужно…

По-моему проблема разработчика на windows не должна касаться остальных. И если у него не выполняются хуки, то это лишь повод подумать и настроить все по-человечески. Ну и как сказали выше: что за команда, если 7 человек не смогли прийти к единому стилю?
И опять же кодревью при мердже. Можно ведь на этом этапе отсекать.

В какой степени среды разработки, тестирования и исполнения должны поддерживать разные версии разных ОС — проектное решение, в некоторых случаях — корпстандарт.
Можно еще добавить pre-commit hooks, которые обязательно у какого-нибудь разработчика на Windows не будут корректно работать из-за особенностей path

Всё ок. Пользуюсь разными хуками, проблем пока не встречал. Правда пришлось малость пофиксить либу, которую использовал для установки хуков, но там буквально одна строчка для windows потребовалась.
Критика — это хорошо, но конструктивное предложение решения проблемы — еще лучше.
Ну ладно вам? Какой проблемы? Она явно надумана.
Да, у JS есть 1000+1 способ организовать разработку, нет четкого свода правил и т. п. Ну так в этом и прелесть, не находите?
Скорее это объективный факт, у которого могут быть разные субъективные оценки.
Возможно, это классно, когда цель стоит просто поиграться в «песочнице», но когда у вас стоит задача разработать продукт, то такое положение вещей только усугубляет ситуацию
В этом посте описана стандартная картина. Сталкиваюсь с подобным уже пару лет. Это происходит когда в команде 7 джуниоров и ни одного сеньора. Через пол года ускоренной разработки новых фич при отсутствии стайлгайдов и линтинга код превращается в долговое болото.

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

Самое печальное что эти 7 джуниоров к этому моменту разбегаются кто куда, и для продолжения разработки приходится собирать новую команду.

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

Первым тревожным звоночком является замедление разработки новых фич до 50% и жуткие тормоза производительности, анимации и UX.

Как только ответственные за проект люди ( если таковые вообще присутствуют в проекте ) понимают в какой попе находятся, они находят кого-нибудь типа меня. Я окунаюсь на месяц или два месяца с головой в говнокод, и на выходе выдаю конфетку.

В лучшем случае в дальнейшем собирается новая команда, которая работает по стайлгайдам и с линтингом и тестами.

В худшем — все сроки сорваны, бюджеты освоены, команда разбежалась, менеджеры уволены.

Эта история стара как мир, была, есть и будет повторяться снова и снова.

Если вы как менеджер проекта экономите на опытных разработчиках, то технический долг говнокода потопит вашу утлую лодочку 100%.
Зачастую, если в команде больше, чем один человек, код превращается в нечитаемую лапшу, так как у каждого разработчика есть свое уникальное видение “правильной” структуры и синтаксиса.

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

Sign up to leave a comment.

Articles