Не в момент выполнения, а в момент проектирования

Давным-давно мудрый старый разработчик дал мне совет, который до недавнего времени я не очень ценил.

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

Итак, появился молодой преуспевающий программист. (Хорошо, это был я.) Я решил, что вместо хардкода массива всех букв будет проще написать цикл for, который проходит от 65 до 90, а затем генерировал буквы по полученному коду символа.

В варианте JavaScript это будет выглядеть примерно так:

for (let i = 65; i <= 90; i++) {
 letters.push(String.fromCharCode(i))
}

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

Я был в ужасе. «Как вы можете ожидать того, что я буду печатать каждую букву, как какой-то ребенок. Я профессиональный разработчик программного обеспечения! У меня есть алгоритмы и структуры данных, и математический сопроцессор, ради всего святого!»

«Хорошо», сказал он. «Просто используйте этот функционал во время разработки, чтобы сгенерировать массив, а затем скопируйте и вставьте его в рабочий код».

А затем он сказал это:

«Избегайте во время выполнения программ то, что вы можете делать во время разработки»

Теперь давайте будем честными. Мой маленький цикл for не собирался замедлять приложение. И современные машины будут так быстро разбираться в этом коде, что никто даже не заметит. Но, как правило, это мудрый совет.

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

Вот почему я думаю, что в ближайшие годы такие известные игроки, как WordPress, Drupal и т. п., столкнутся с серьезной проблемой со стороны таких генераторов статических сайтов, как Gatsby ^[1], Hugo ^[2] или Jekyll ^[3], в сочетании с плавным процессом сборки, headless CMS ^[4], дешевыми CDN и быстрым непрерывным процессом интеграции.

Этот паттерн был назван JAMstack ^[5], что означает «JavaScript, API и стек разметки». И результаты весьма впечатляющие ^[6].

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

Недавно я читал замечательную книгу Рэя Далио «Принципы: работа и жизнь» ^[7]. Центральная тема книги заключается в том, что типов проблем гораздо меньше, чем реальных проблем. Поэтому, если вы поработаете над этим заранее и выясните, как вы будете подходить к конкретному типу проблемы, с которой вы, вероятно, столкнетесь, то, когда она придет, вы будете гораздо лучше подготовлены, чтобы справиться с ней.

По сути, вы можете быстрее принимать лучшие решения, сортируя свой подход к различным типам проблем во время “разработки”, когда вы спокойно размышляете о жизни, а не во время “выполнения”, когда вы сталкиваетесь с актуальной проблемой в данный момент и паникуете.

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

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

• Я поделился своими собственными советами и извлеченными уроками в недавнем интервью на подкасте Developer On Fire, которое вы можете прослушать здесь ^[8].
• Вы можете познакомится с JAMstack на Jamstack.org
• В блоге Netlify ^[9] также есть хороший обзор генераторов статических сайтов.
• А вот статья о конкретном стеке ^[10], который я недавно рассмотрел и рекомендовал, который использует комбинацию Gatsby, Contentful, Netlify и Algolia в качестве альтернативы традиционной CMS для сайта документации.

Автор: rishat_edison

Источник ^[11]