Конференции Олега Бунина (Онтико) corporate blog
JavaScript
Programming
Java
TypeScript
Comments 14
+1
Ряд советов хороши, например, tmux — хорошее дело.

Есть ряд советов, которые не даны. Например, не упомянут «настройте один раз линтинг». Я бы сказал, что это вещь, которая очень сильно бесит и хочется плюнуть пока настроишь всю связку vscode с prettier для линтинга, но когда сделаешь — чувствуешь, как много ресурсов высвободилось.

И, не программистский совет: освойте слепой десятипальцевый набор.
0
Вот только сейчас понял, что для меня этот шаг казался супер очевидным, настолько, что даже не стал его упоминать. Но явно стоило :)
+5
Статья, более чем наполовину состоящая из сомнительных рецептов.

> окружение операционной системы
Всё зависит от того, как часто вы меняете систему, и какова вероятность того, что под новый проект вам будет нужно примерно такое же окружение. Если вы меняете систему раз в несколько лет (насколько часто у тебя в рабочей машине горит матплата, %юзернейм%?) — писать конфиги будет так же эффективно, как и не писать: в следующий раз вам скорее всего придётся в конфиг всё равно посмотреть, чтоб убедиться, что всё там написанное всё еще актуально и нужно.

> проектирование
Единственный навык программиста, который тут нужен — это не 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. Он не единственный, честно.
Писать бойлерплейт из-за выбранного инструмента, и жаловаться на это (и бороться с этим инструментами кодогенерации) — это, на мой взгляд, то же самое, что отстрелить себе ногу из дробовика, и, крича о том, что чё-то больно, разрабатывать механический костыль.
0

Судя по тому, как вам не нравится CLI, вы использовали только create-react-app:)

+1
Нет, тут чуть другая история — я просто уже несколько раз был тем самым «человеком, который придёт после вас». Приходил, и… видел проект, созданный через create-react-app, в котором по факту почти все фичи create-react-app не использовались, а те что использовались — были сконфигурированы с очень печальным пониманием происходящего.

Такой уровень использования CLI работе не только не помогает, но даже еще и вредит. Причем очень заметно.
0

Ну надо сказать что CRA очень не гибкий по сравнению с остальными инструментами, да и фичами не так чтоб богат. Поэтому впечатление складывается не очень.

+1
Ну как сказать… Ангуляр я совсем не уважаю, но дело с ним довольно серьезно имел, и дело с CLI ангуляра тоже — и я не вижу фундаментальных различий. Более того, CLI ангуляра — это вот как у автора статьи с редаксом, оно более богато на фичи и навороты, но эти фичи и навороты — они как раз для того, чтоб мужественно преодолеть проблемы, самим ангуляром и создаваемые (бойлерплейт, модульность, итд).

CRA куда проще и банальнее — именно потому, что сам реакт очень простой и банальный, там не надо колдовства и кодогенерации (по крайней мере пока вы редакс не притащили).
0

С другой стороны, если уж возникло желание нарисовать диаграмму — лучше рисовать её используя UML.

0
Если она хоть сколько-нибудь приличных размеров — да, пожалуй.
+1
Всё зависит от того, как часто вы меняете систему

Система может сдохнуть в самый разгар проекта, когда времени нет.
Лучше иметь под рукой способ.

Если же по вашему рецепту — то придется каждый раз полностью вспоминать с нуля. Это долго.
0
Я мучался, потратил кучу времени, и потом начал массово создавать эти компоненты просто за счет того, что использовал code snippets.
Для тех, кто работает с WebStorm, это не сильно полезно, просто потому, что в нем нет такой большой экосистемы плагинов <...>

Но позвольте, в WebStorm точно так же можно создавать свои сниппеты "из коробки" с незапамятных времен, при чем тут плагины? Более того, там есть настраиваемые шаблоны для файлов.

0
Тут просто не достаточно хорошо выразил свою мысль. Главное в этом абзаце следующее
всё включено изначально — это полноценный IDE.


Просто хотел сказать что WebStorm нет особой необходимости искать и ставить плагины.

PS: сам предпочитаю VSCode. Легче работать с большим кол-вом проектов (5-10 одновременно открытых проектов между которыми постоянно переключаюсь)
+3

Я посмотрел выступление по поводу рефакторинга и там есть слова, что "Если делаете что-то неправильно и знаете об этом, то делайте это что-то одинаково неправильно везде, чтобы потом было легче рефакторить!". Я уж думал, что я один так думаю, было приятно встретить единомышленника.

Only those users with full accounts are able to leave comments. , please.