Що найпростіше, що потрібно?

Є цитата, яку часто приписують Альберту Ейнштейну, яка мені дуже подобається (і я впевнений, що подобається більшості):

Все має бути максимально простим, але не простішим.

Є певне розслідування щодо того, сказав він це чи ні, але суть залишається незважаючи на те, хто це сказав.

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

• Я не хочу прибирати у своїй кімнаті, тому я наведу порядок.
• Я зроблю рівно стільки, щоб задовольнити клієнтів, і цього достатньо.
• Я виконаю [незалежно від відповідальності] до [найнижчого можливого ступеня], і оскільки Ейнштейн [нібито] це сказав, хто я такий, щоб сперечатися.

Незважаючи на те, що я з нею не згоден (і обговорення цього виходить за межі цієї публікації), я розглядаю цю ідею в контексті веб-розробки.

І щоб було зрозуміло, я не говорю про веб-дизайн. Я не дизайнер. Я не хочу говорити від імені того, до чого я не належу. Але щодо надання рішень для людей, які використовують програмне забезпечення або, радше, веб-розробку, я набагато більше схильний і позиціонований говорити про це.

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

Найпростіша річ, яка потрібна

Нещодавно я писав про різні аспекти зовнішньої розробки (в контексті швидкого отримання чогось із дверей) і про те, як тепер у нас є інструменти для створення виключно для цього аспекту стека веб-розробки.

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

Чи потрібна ця утиліта для ефективного та позитивного полегшення розробки рішення для когось іншого?

Наприклад, я вважаю, що Composer — це щось дуже корисне. Це дозволяє мені легко керувати бібліотеками сторонніх розробників, оновлювати їх за потреби та включати в свої проекти.

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

Однак візьмемо, наприклад, деякі інструменти інтерфейсної збірки, такі як Grunt, Gulp, Yarn, Node, Mix тощо. Щоб було зрозуміло, деякі з них виконують те саме, що й інші, тоді як інші служать іншим цілям.

Мета, над якою я працюю, така:

У який момент інструменти, які ми використовуємо для розробки, перешкоджають нашій здатності створювати щось і ефективно постачати?

Є щось у нашій галузі, що змушує нас відчувати потребу залишатися на передовій технології. Але я вважаю, що слід зробити важливу відмінність: одна справа знати про інструмент, але одна справа ним користуватися.

обізнаність

Чудова річ у знаннях про те, що щось доступно, полягає в тому, що ми маємо можливість дослідити це та визначити, чи воно для нас буде корисним.

Це не новаторська чи нова ідея, але я думаю, що це одна річ, яку деякі з нас обходять стороною. Замість того, щоб досліджувати та оцінювати, ми часто пропускаємо це та дивимося, як швидко зможемо ним скористатися.

Введення в експлуатацію

Перевага використання чогось нового полягає в тому, що ми отримуємо вигоди – або очікувані вигоди – які має надати зазначена корисність.

Небезпека в цьому полягає в тому, що інструмент може не з’явитися через шість місяців, рік або навіть два роки, а технології, які він прагне вдосконалити, можуть змінитися, хоча він не встигає за ними.

Ось чому важливо знати про цю корисність, водночас визначаючи, чи корисна вона чи ні.

Про цю простоту

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

Клієнтам буде байдуже, чи використовуєте ви той чи інший інструмент. Вони довіряють вам бути хорошим розпорядником рішення, за реалізацію якого вони вам платять, і частково зобов’язані мудро та старанно витрачати свій час.

Якщо утиліта, якою ви користуєтеся, будь-яким чином перешкоджає зазначеній відповідальності, можливо, її не варто використовувати для певного проекту.

І ось до чого, зрештою, для мене все зводиться: якщо те, що я використовую, допомагає мені створити найкраще можливе рішення, не роблячи це за рахунок клієнта, то, ймовірно, це варто використовувати. З цією метою часто все, що потрібно, — це найпростіший набір інструментів і нічого більше.

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