Best-Practices

Я начну с признания: ваш технологический стек, скорее всего, неправильный. Не может быть неправильным, а именно неправильным. И знаете что? Мой тоже был неправильным. На самом деле, я готов поспорить, что если вы можете назвать весь свой технологический стек, не заглядывая в документацию, есть хорошие шансы, что вы что-то чрезмерно усложнили. Позвольте мне объяснить, почему это происходит, и, что более важно, что с этим делать. Соблазнительный танец «лучшего в классе» Вот где большинство проектов идут не так....

Мост, который нам не нужен Представьте: вы сидите на встрече стартапа. Три инженера. Осталось две недели работы. Продукт ещё не проверен на востребованность. И кто-то — всегда найдётся кто-то — говорит: «Нам, наверное, стоит настроить архитектуру микросервисов с оркестрацией Kubernetes, реализовать очередь сообщений, добавить сервисную сетку и спроектировать её для 100 миллионов одновременных пользователей». Ваше чутье подсказывает, что что-то не так. Вы правы. Это эпидемия избыточной инженерии, и она убивает больше продуктов, чем спасает....

Помните, когда все думали, что добавление !important к каждому правилу CSS — это правильный подход? Или когда мы все искренне верили, что document.write() — это пик JavaScript? Ну, друзья, я думаю, мы коллективно нашли нашу следующую священную корову для поклонения: минификация кода. И я здесь, чтобы аккуратно столкнуть её с пьедестала. Не поймите меня неправильно — минификация имеет своё место в наборе инструментов для оптимизации производительности. Но где-то между «полностью игнорировать» и «относиться как к святыне веб-производительности» мы коллективно решили, что минификация заслуживает нашего навязчивого внимания....

Вы знаете это чувство, когда вы приходите на buffet и наполняете свою тарелку всем, что доступно, а потом понимаете, что вам стоило ограничиться только пиццей? Примерно то же самое происходит, когда разработчики обнаруживают шаблоны проектирования. Не поймите меня неправильно — я люблю шаблоны проектирования. Они как хорошо организованный набор инструментов для решения повторяющихся проблем. Но есть неудобная правда, которую никто не хочет признавать на технических конференциях: шаблоны проектирования стали изолентой современной разработки программного обеспечения....

Посмотрите, я понимаю. NoSQL в тренде. Это круто. Он горизонтально масштабируется как настоящий профи, и где-то около 2015 года мы все решили, что реляционные базы данных устарели, как раскладушки. Но вот неудобная правда, о которой никто не хочет говорить на технических конференциях: для большинства приложений вам, вероятно, не нужен NoSQL, и настаивать на его использовании — это всё равно что принести огнемёт на церемонию зажигания свечей. Я видел слишком много команд, которые загоняли себя в тупик, выбирая MongoDB или Cassandra для проектов, которые были бы вполне довольны старой доброй PostgreSQL....