Что самое простое, что нужно?

Есть цитата, которую часто приписывают Альберту Эйнштейну, которая мне очень нравится (и я уверен, что большинству):

Все должно быть сделано максимально просто, но не проще.

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

Легко взять эту идею и применить ее к тому, что мы делаем в повседневной жизни, но не хотим делать, верно?

• Я не хочу убирать свою комнату, так что я приберусь достаточно.
• Я сделаю ровно столько работы, чтобы удовлетворить клиентов, и этого достаточно.
• Я выполню [любую ответственность] до [самой низкой возможной степени], и поскольку Эйнштейн [якобы] сказал это, кто я такой, чтобы спорить.

Несмотря на то, что я не согласен с этим (и обсуждение этого вопроса выходит за рамки этого поста), я рассматриваю эту идею в контексте веб-разработки.

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

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

Самое простое, что нужно

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

Когда дело доходит до таких инструментов, независимо от того, на каком уровне стека мы работаем, я задаюсь вопросом:

Нужна ли эта утилита для эффективного и положительного облегчения разработки решения для кого-то другого?

Например, я считаю, что Composer очень полезен. Это позволяет мне легко управлять сторонними библиотеками, обновлять их по мере необходимости и включать в свои проекты.

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

Возьмем, к примеру, некоторые инструменты сборки интерфейса, такие как Grunt, Gulp, Yarn, Node, Mix и так далее. Чтобы было ясно, некоторые из них делают то же самое, что и другие, в то время как другие служат другой цели.

Суть, над которой я работаю, такова:

В какой момент инструменты, которые мы используем для разработки, мешают нам создавать что-то и эффективно что-то выпускать?

Есть что-то в нашей области, что заставляет нас чувствовать необходимость оставаться на переднем крае технологий. Но я думаю, что есть важное различие: одно дело знать об инструменте, а другое — использовать его.

Осведомленность

Самое замечательное в знании того, что что-то доступно, — это возможность исследовать это и определить, полезно ли это для нас.

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

Использование

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

Опасность заключается в том, что инструмент может исчезнуть через шесть месяцев, год или даже два года, а технологии, которые он призван улучшить, могут измениться, пока он не поспевает за ним.

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

Об этой простоте

Тем не менее, возвращаясь к моей первоначальной точке зрения, она такова: если количество времени, которое требуется вам для настройки, изучения, разработки, внедрения и использования нового инструмента в вашем рабочем процессе, я думаю, стоит подумать, действительно ли оно того стоит. время в вашем наборе инструментов.

Клиентов не будет заботить, используете ли вы какой-либо инструмент, который вы можете использовать. Они доверяют вам быть хорошим распорядителем решения, за реализацию которого они платят вам, и часть этой ответственности заключается в том, чтобы быть мудрым и усердным со своим временем.

Если используемая вами утилита каким-либо образом препятствует указанной ответственности, возможно, ее не стоит использовать для данного проекта.

И в конечном итоге для меня это сводится к следующему: если то, что я использую, помогает мне создать наилучшее возможное решение, не делая это за счет клиента, то, вероятно, его стоит использовать. Для этого зачастую достаточно простейшего набора инструментов и ничего более.

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