Отправляй или умри (с качеством или без?)
Одна из идей, которая меня заинтриговала, — это менталитет «отправляй или умри». Что касается того, как это называется, существуют его вариации, но идея, лежащая в основе этой фразы, проста:
Если у вас есть идея, доведите ее от концепции до продукта как можно быстрее.
Конечно, идея перехода от концепции к продукту также может называться «от идеи к деньгам», но никогда нет гарантии, что вы собираетесь получать деньги, верно? Однако есть гарантия, что вы сможете воплотить его в осязаемый продукт.
А в кругах разработчиков программного обеспечения всегда есть много аргументов за или против идеи. На ум сразу приходят два плюса и минуса:
- Про. Быстро сделать что-то, что работает и [потенциально] приносит доход.
- Кон. Слабая архитектура, обслуживание, масштабируемость, тестируемость и так далее.
Короче говоря, может быть компромисс между тем, как быстро вы можете отправить что-то на рынок, и архитектурой проекта. Иногда есть, иногда нет. В целом, однако, я думаю, что можно с уверенностью предположить первое.
Кроме того, некоторые могут рассматривать первое как легкий выход, другие могут рассматривать второе как упражнение в ЯГНИ или, что еще проще, проблему можно решить, когда бы она ни возникла.
Но какое это имеет отношение к чему-либо в данный момент?
Отправить или умереть?
Вся причина, по которой я трачу время на то, чтобы написать об этом, заключается в том, что это то, о чем я и, как я подозреваю, другие в нашей области, по крайней мере, немного думаю. Все это хорошо, если говорить об этом в абстрактном смысле, но позвольте мне попытаться связать это с чем-то более реалистичным.
Давным-давно…
Несколько лет назад фронтенд-разработка заключалась в заключении контента во встроенные или блочные элементы и их стилизации с помощью базового CSS?
У нас были продвинутые инструменты для работы с нашим внутренним кодом, но внешний интерфейс был относительно простым, за исключением, возможно, стандартов кодирования, установленных компанией или командой, с которой мы работали.
Но потом…
Наши устройства продвинуты (что, между прочим, я считаю хорошей и даже естественной вещью в технологии). Наряду с указанным улучшением, теперь у нас есть инструменты сборки специально для фронтенд-разработки, которые в некоторых отношениях так же продвинуты, как и те, которые мы используем для серверного программного обеспечения.
Конечно, у нас есть «разработчики полного стека», но я рад признать, что мне гораздо удобнее работать на стороне сервера, чем на интерфейсе. Если я работаю на внешнем интерфейсе, я склонен придерживаться инструментов, с которыми я знаком, и стараюсь оставаться в пределах ограничений, определяемых полосой, в которой я работаю.
Это помогает поддерживать целенаправленность, скорость и согласованность разработки в разных проектах.
Хорошо, так в чем смысл?
Сам по себе этот раздел может быть длинным постом, но я не заинтересован в том, чтобы заходить так далеко. Вместо этого я возьму один кусочек того, как работает фронтенд-разработка прямо сейчас, и посмотрю, смогу ли я использовать его, чтобы прояснить свою точку зрения.
Нахальный
Возьмем, к примеру, то, во что превратился CSS. У нас есть языки поверх языков (например, Sass, который находится поверх базового CSS или дополняет его).
И у нас есть процессоры, которые компилируют, минифицируют, анализируют и не дают нам увидеть нашу работу до тех пор, пока не будут исправлены определенные ошибки и предупреждения ради качества. (Я не считаю это чем-то плохим, но это показывает растущий уровень сложности — или, возможно, зрелости — наших интерфейсных инструментов).
Фронтенд-разработка слишком проста, давайте сделаем ее более сложной, чтобы мы могли чувствовать себя умнее среди наших коллег, которые, по-видимому, имеют дело с более «критическими» аспектами бизнеса. Помните, что это соревнование.
Эта статья имеет юмористический взгляд на все это.
Разумная степень качества
Чтобы было ясно, я не говорю, что это плохо, но я говорю, что вещи, которые когда-то относились к серверной стороне или компилируемым языкам, теперь распространяются на весь стек разработки веб-приложения.
Чтобы быть предельно ясным, насколько это возможно: я за качество. Отправка вещей без какой-либо степени может рассматриваться как проявление безответственности.
Но я также считаю, что необходимо найти баланс между написанием наиболее оптимального, функционального и производительного кода, возможного в условиях ограниченного времени и бюджета.
Я не верю, как бы мы ни старались навязать это себе, что мы живем в утопии разработчиков, где мы можем оптимизировать, проектировать и внедрять первоначальные системы в каждом отдельном проекте.
Однако кажется, что мы изо всех сил старались создать его, не так ли?
Но в какой-то момент, не стоит ли задаться вопросом, удаляют ли все инструменты, которые мы создаем, и все вещи, которые мы добавляем в наши проекты, то самое, что привело нас в отрасль в первую очередь? Конечно, для некоторых из нас это, вероятно, другое. Справедливо ли спрашивать, что наличие идеи, написание кода для ее воплощения в жизнь и наблюдение за тем, как он решает проблему, привели нас к успеху?
Однако на данный момент мы представили так много инструментов, что создание и запуск среды разработки для веб-приложения, работающего от базы данных до браузера, становится пугающей задачей.
Так много всего должно произойти, прежде чем мы действительно будем готовы начать писать код, что может стать утомительным и даже немного утомительным, если только делать начальные шаги.
Личное, окончательное мнение
Я стремлюсь к внедрению сильных объектно-ориентированных практик и инструментов во многих проектах, над которыми я работаю со своей командой и которые я отправляю другим, потому что я знаю из опыта, что время, доллары и данные, которые могут быть потеряны из-за чего-то т обращено со всех сторон.
Это не означает, что быстрая отправка чего-либо сводит на нет все это. Но процесс и организация кода, лежащего в основе проекта, — это то, что мне очень трудно игнорировать настолько, что я чувствую себя почти парализованным, чтобы отправить что-то, что не было протестировано и проверено в максимально возможной степени (и даже тогда, есть проблемы).
С другой стороны, однако, есть часть меня, которая хочет поэкспериментировать с одной или двумя идеями, лежащими в основе менталитета «отправьте это или умрите», просто посмотреть, как быстро что-то может быть построено, отправлено и принесет любой тип дохода, независимо от того, насколько первозданный. кодовая база есть.
И, возможно, я попробую это с некоторыми предстоящими проектами.