Подход к созданию сайтов

Концепция «легкого шага» предназначена для технических специалистов в стартапах.

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

Если действовать осторожно, фокус остается на продукте, и весь технологический стек становится деталью реализации.

Внедряйте инновации сейчас, не ограничивая будущих возможностей

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

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

Легкая поступь - это действительно сплав идей и опыта. Давайте нырнем!

Устойчивый веб-дизайн

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



Устойчивый веб-дизайн
Джереми Кейт resilientwebdesign.com



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

Во-первых, просто заставьте его работать; во-вторых, сделать так, чтобы он работал лучше.

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

Эволюционная архитектура

Нил Форд и Ребекка Парсонс из ThoughtWorks придумали термин эволюционная архитектура в 2016 году. При эволюционном подходе изменения становятся первоклассным гражданином. Нил и Ребекка называют микросервисы и доменно-ориентированный дизайн яркими примерами этой концепции.

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

Вы можете больше узнать об эволюционной архитектуре в подкасте ThoughtWorks, а пока вот проясняющая цитата из того эпизода, где Ребекка Парсонс говорит об адаптивности и эволюционируемости:

Когда мы думаем об адаптивности, возникает идея: о, у меня есть что-то достаточно гибкое, чтобы у меня были все нужные ручки, чтобы повернуть, и все рычаги, которые нужно тянуть, потому что каким-то образом я был достаточно умен, чтобы заранее выяснить, как все это должно было измениться. Этого просто не может произойти - может быть, это могло произойти 30 или 40 лет назад, но требования, которым соответствуют системы сейчас, - не только технологические изменения, но и ожидания пользователей, бизнеса. Продолжительность жизни фундаментальных бизнес-моделей даже сокращается. И поэтому вместо того, чтобы думать, что мы можем предсказать, как эти вещи будут меняться, чтобы я мог встроить правильные ручки и рычаги, нам нужно убедиться, что мы можем безопасно и быстро внести некоторые из этих фундаментальных изменений. Вот почему мы фокусируемся на словосочетании «эволюционируемость», а не «адаптируемость».

Постепенное усыновление

Выступление Ли Байрона «Уроки четырех лет использования GraphQL» также заслуживает почетного упоминания. Ли описывает, как GraphQL постепенно внедрялся в продукты Facebook, и этот важный урок можно применить для добавления функций в наши собственные продукты:

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

Жертвенная архитектура

Концепция жертвенной архитектуры Мартина Фаулера может показаться противоречащей идеям эволюционной архитектуры и постепенного внедрения, но мы можем найти ей какое-то применение. Мартин описывает практику частого отказа от реализации продукта, чтобы идти в ногу с меняющимися технологиями и бизнес-требованиями, заявив: Лучший код, который вы можете написать сейчас, - это код, который вы отбросите через пару лет. Он рассказывает историю о том, как eBay разрушал их кодовую базу каждые 2–4 года:

Правильная архитектура для поддержки eBay 1996 года не будет подходящей архитектурой для eBay 2006 года. Версия 1996 года не справится с нагрузкой 2006 года, но версия 2006 года слишком сложна для создания, поддержки и развития для нужд 1996 года.

Это перекликается с мантрой Resilient об использовании правильного инструмента для правильной работы и его правильном использовании. Затем Мартин делает интересную, но знакомую мысль о том, что когда вы внедряете продукт или функцию, бизнес или инженеры редко четко понимают ее требования:

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

Жертвенная архитектура также может применяться к MVP и прототипам:

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

Если вы еще не встречали 22 # основ истории Эммы Пальто, их определенно стоит прочитать всем, кто занимается творчеством. В частности, при рассмотрении достоинств жертвенной архитектуры на ум приходит следующее:

# 3 Попытка найти тему важна, но вы не поймете, о чем на самом деле идет история, пока не дойдете до конца. А теперь перепиши.

Писать. А теперь перепиши.

Чистый код

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

Будьте легким трейдером

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