Каждому инструменту своё место

Одна из главных проблем современного программирования (и фронтенда в частности) — это отсутствие у программистов здравого смысла при выборе инструментов.

Интернеты пестрят статьями о том, как можно и нужно использовать тот или иной инструмент для решения какой-то задачи. И при чтении подобных статей многие почему-то теряют голову. Использовать для сборки фронтенда Makefile? Конечно! Заинлайнить огромные команды в npm scripts? Обязательно! Сделать SPA для лэндинга? Всенепременно! Подтянуть в проект все пакеты, название которых начинается на “Re”? Да-да-да!

Нет.

Так уж получилось, что в нашей сфере огромное разнообразие инструментов, каждый из которых можно применить не только к той области, для которой он разрабатывался, но и к сотне других. Однако, следует разделять работу и фан. Хороший механик не будет на работе вкручивать шуруп ножом. Он может это сделать будучи пьяным у себя на даче (у нас это называется хакатонами, ага), но никак не на работе. Так же и в программировании. Если ты знаешь, что после тебя кто-то ещё будет этим пользоваться, то ты должен нести ответственность за то, что ты делаешь, и принимать решения основываясь не только на своём «хочу-хочу» и «блин, ну круто же!».

Это всё, конечно, не значит, что нельзя собирать фронтенд с помощью make или использовать ещё какие-то дикие решения. Иногда бывают такие задачи, в которых это необходимо. Например, если при деплое сборка происходит на сервере с ограниченными ресурсами, и там не получится подтянуть большое количество пакетов из npm, да ещё и собрать их, то одним из решений, конечно, будет написание тасков на чём-то, что точно заработает. Это оправдано, потому что мы точно знаем, на какой машине будет всё собираться, а потому можем не заморачиваться по поводу кроссплатформенности. И скорее всего это вообще будет временным решением.

Во всех же остальных случаях, использование инструментов, которые не подходят под задачу, это чаще всего оверинжиниринг. Всегда будет оверхед в каких-либо ресурсах, будь то время разработки, размер или же эффективность работы конечного результата.

Хорошо подумать при выборе инструмента для решения проблемы — значит уже наполовину её решить.

2017
Популярное