Comments 15
Ряд советов хороши, например, tmux — хорошее дело.
Есть ряд советов, которые не даны. Например, не упомянут «настройте один раз линтинг». Я бы сказал, что это вещь, которая очень сильно бесит и хочется плюнуть пока настроишь всю связку vscode с prettier для линтинга, но когда сделаешь — чувствуешь, как много ресурсов высвободилось.
И, не программистский совет: освойте слепой десятипальцевый набор.
Есть ряд советов, которые не даны. Например, не упомянут «настройте один раз линтинг». Я бы сказал, что это вещь, которая очень сильно бесит и хочется плюнуть пока настроишь всю связку vscode с prettier для линтинга, но когда сделаешь — чувствуешь, как много ресурсов высвободилось.
И, не программистский совет: освойте слепой десятипальцевый набор.
Статья, более чем наполовину состоящая из сомнительных рецептов.
> окружение операционной системы
Всё зависит от того, как часто вы меняете систему, и какова вероятность того, что под новый проект вам будет нужно примерно такое же окружение. Если вы меняете систему раз в несколько лет (насколько часто у тебя в рабочей машине горит матплата, %юзернейм%?) — писать конфиги будет так же эффективно, как и не писать: в следующий раз вам скорее всего придётся в конфиг всё равно посмотреть, чтоб убедиться, что всё там написанное всё еще актуально и нужно.
> проектирование
Единственный навык программиста, который тут нужен — это не UML рисовать. Это сказать обычным русским (английским) языком по белому, что ты тут собрался делать. Если этого навыка нет — диаграммы в достижении взаимопонимания в команде не помогут. Если есть — то диаграммы, а тем более конкретно UML — не обязательны, потому как не в них соль.
Генерация кода из UML в одну сторону — лично для меня выглядит бессмысленным времяпровождением. Вы сразу можете запроектировать всю архитектуру хоть сколько-нибудь сложного (difficult) модуля? И она у вас потом не меняется? А если меняется, то всё это рисование достаточно бессмысленно, несколько обновлений — и картинки уже не будут соответствовать коду. Вы хотите получить из картинок начальный объем кода? А почему бы сразу не написать этот начальный объем кода в виде кода? Другие люди не поймут? Как я выше сказал, тут главное — это способность пояснить ход своих мыслей на обычном русском языке, а прочитать черновые намётки интерфейсов на питоне и java-разработчик сможет, не надо выставлять его идиотом. Структуры и интерфейсы на большинстве языков выглядят довольно схоже.
Для того, чтоб в проекте была команда билда и запуска — в проекте должна быть команда билда и запуска, а не CLI. Будет там или не будет CLI — дело десятое. Для того, чтоб в проекте можно было запускать end-to-end и юнит тесты — в проекте должны быть end-to-end и юнит тесты. А не CLI.
CLI — это не более чем стандартная обвязка, которая вам практически в 100% случаев не нужна вся, но вы её всё равно устанавливаете всю, потому что иначе нельзя. CLI не добавляет понимания, как это всё работает и что делают её отдельные составляющие, и если вы чем-то из CLI не умеете пользоваться и не пользовались — то «человек, который придёт после вас» не найдет после вас ничего. Просто потому, что находить будет нечего.
CLI — это диктатура определенного инструментария от людей, которые не у вас в команде и не решают ваши задачи. Вы можете её использовать, если вы детально понимаете, чем конкретно вы пользуетесь, и что это всё вам наилучшим образом подходит. Если не понимаете или не подходит, навязывание CLI — это просто карго-культ.
Для меня это звучит как весомый повод не использовать Redux. Он не единственный, честно.
Писать бойлерплейт из-за выбранного инструмента, и жаловаться на это (и бороться с этим инструментами кодогенерации) — это, на мой взгляд, то же самое, что отстрелить себе ногу из дробовика, и, крича о том, что чё-то больно, разрабатывать механический костыль.
> окружение операционной системы
Всё зависит от того, как часто вы меняете систему, и какова вероятность того, что под новый проект вам будет нужно примерно такое же окружение. Если вы меняете систему раз в несколько лет (насколько часто у тебя в рабочей машине горит матплата, %юзернейм%?) — писать конфиги будет так же эффективно, как и не писать: в следующий раз вам скорее всего придётся в конфиг всё равно посмотреть, чтоб убедиться, что всё там написанное всё еще актуально и нужно.
> проектирование
Единственный навык программиста, который тут нужен — это не UML рисовать. Это сказать обычным русским (английским) языком по белому, что ты тут собрался делать. Если этого навыка нет — диаграммы в достижении взаимопонимания в команде не помогут. Если есть — то диаграммы, а тем более конкретно UML — не обязательны, потому как не в них соль.
Генерация кода из UML в одну сторону — лично для меня выглядит бессмысленным времяпровождением. Вы сразу можете запроектировать всю архитектуру хоть сколько-нибудь сложного (difficult) модуля? И она у вас потом не меняется? А если меняется, то всё это рисование достаточно бессмысленно, несколько обновлений — и картинки уже не будут соответствовать коду. Вы хотите получить из картинок начальный объем кода? А почему бы сразу не написать этот начальный объем кода в виде кода? Другие люди не поймут? Как я выше сказал, тут главное — это способность пояснить ход своих мыслей на обычном русском языке, а прочитать черновые намётки интерфейсов на питоне и java-разработчик сможет, не надо выставлять его идиотом. Структуры и интерфейсы на большинстве языков выглядят довольно схоже.
Один из главных аргументов, почему стоит работать именно с CLI — это унифицированность. Если вы забудстрэппили ваш проект с помощью CLI, то уверены, что человек, который придет после вас, будет знать структуру проекта: команды, фичи, что можно запускать end-to-end и юнит тесты.
Для того, чтоб в проекте была команда билда и запуска — в проекте должна быть команда билда и запуска, а не CLI. Будет там или не будет CLI — дело десятое. Для того, чтоб в проекте можно было запускать end-to-end и юнит тесты — в проекте должны быть end-to-end и юнит тесты. А не CLI.
CLI — это не более чем стандартная обвязка, которая вам практически в 100% случаев не нужна вся, но вы её всё равно устанавливаете всю, потому что иначе нельзя. CLI не добавляет понимания, как это всё работает и что делают её отдельные составляющие, и если вы чем-то из CLI не умеете пользоваться и не пользовались — то «человек, который придёт после вас» не найдет после вас ничего. Просто потому, что находить будет нечего.
CLI — это диктатура определенного инструментария от людей, которые не у вас в команде и не решают ваши задачи. Вы можете её использовать, если вы детально понимаете, чем конкретно вы пользуетесь, и что это всё вам наилучшим образом подходит. Если не понимаете или не подходит, навязывание CLI — это просто карго-культ.
Каждый раз, когда люди создают одни и те же файлы и жалуются, что с Redux тяжело работать, надо создавать кучу всего.
Для меня это звучит как весомый повод не использовать Redux. Он не единственный, честно.
Писать бойлерплейт из-за выбранного инструмента, и жаловаться на это (и бороться с этим инструментами кодогенерации) — это, на мой взгляд, то же самое, что отстрелить себе ногу из дробовика, и, крича о том, что чё-то больно, разрабатывать механический костыль.
Судя по тому, как вам не нравится CLI, вы использовали только create-react-app:)
Нет, тут чуть другая история — я просто уже несколько раз был тем самым «человеком, который придёт после вас». Приходил, и… видел проект, созданный через create-react-app, в котором по факту почти все фичи create-react-app не использовались, а те что использовались — были сконфигурированы с очень печальным пониманием происходящего.
Такой уровень использования CLI работе не только не помогает, но даже еще и вредит. Причем очень заметно.
Такой уровень использования CLI работе не только не помогает, но даже еще и вредит. Причем очень заметно.
Ну надо сказать что CRA очень не гибкий по сравнению с остальными инструментами, да и фичами не так чтоб богат. Поэтому впечатление складывается не очень.
Ну как сказать… Ангуляр я совсем не уважаю, но дело с ним довольно серьезно имел, и дело с CLI ангуляра тоже — и я не вижу фундаментальных различий. Более того, CLI ангуляра — это вот как у автора статьи с редаксом, оно более богато на фичи и навороты, но эти фичи и навороты — они как раз для того, чтоб мужественно преодолеть проблемы, самим ангуляром и создаваемые (бойлерплейт, модульность, итд).
CRA куда проще и банальнее — именно потому, что сам реакт очень простой и банальный, там не надо колдовства и кодогенерации (по крайней мере пока вы редакс не притащили).
CRA куда проще и банальнее — именно потому, что сам реакт очень простой и банальный, там не надо колдовства и кодогенерации (по крайней мере пока вы редакс не притащили).
С другой стороны, если уж возникло желание нарисовать диаграмму — лучше рисовать её используя UML.
Всё зависит от того, как часто вы меняете систему
Система может сдохнуть в самый разгар проекта, когда времени нет.
Лучше иметь под рукой способ.
Если же по вашему рецепту — то придется каждый раз полностью вспоминать с нуля. Это долго.
Я мучался, потратил кучу времени, и потом начал массово создавать эти компоненты просто за счет того, что использовал code snippets.
Для тех, кто работает с WebStorm, это не сильно полезно, просто потому, что в нем нет такой большой экосистемы плагинов <...>
Но позвольте, в WebStorm точно так же можно создавать свои сниппеты "из коробки" с незапамятных времен, при чем тут плагины? Более того, там есть настраиваемые шаблоны для файлов.
Тут просто не достаточно хорошо выразил свою мысль. Главное в этом абзаце следующее
Просто хотел сказать что WebStorm нет особой необходимости искать и ставить плагины.
PS: сам предпочитаю VSCode. Легче работать с большим кол-вом проектов (5-10 одновременно открытых проектов между которыми постоянно переключаюсь)
всё включено изначально — это полноценный IDE.
Просто хотел сказать что WebStorm нет особой необходимости искать и ставить плагины.
PS: сам предпочитаю VSCode. Легче работать с большим кол-вом проектов (5-10 одновременно открытых проектов между которыми постоянно переключаюсь)
Я посмотрел выступление по поводу рефакторинга и там есть слова, что "Если делаете что-то неправильно и знаете об этом, то делайте это что-то одинаково неправильно везде, чтобы потом было легче рефакторить!". Я уж думал, что я один так думаю, было приятно встретить единомышленника.
>> Spy-js vs TraceGL
Похоже, оба этих инструмента уже метрвы (а жаль)
Попробовал подключить spy-js — начал ругаться на async/await синтаксис
Есть ли какие-нибудь альтернативы?
Похоже, оба этих инструмента уже метрвы (а жаль)
Попробовал подключить spy-js — начал ругаться на async/await синтаксис
Есть ли какие-нибудь альтернативы?
Sign up to leave a comment.
Лучше день потерять