Вы когда-нибудь начинали использовать библиотеку, фреймворк или даже новый язык программирования только потому, что это было что-то новенькое? Конечно, вы это сделали, внутренний ребенок каждого разработчика программного обеспечения пристрастился к блестящим вещам. Пополнение нашего набора инструментов новым инструментом всегда кажется хорошей идеей, и, по общему признанию, это весело.
Однако в то же время вы когда-нибудь чувствовали, что эти новые инструменты ржавеют немного быстрее, чем некоторые другие, а через несколько месяцев вас осуждают за их использование? И что еще хуже, даже несмотря на то, что вы приложили огромные усилия, чтобы освоить их использование, вы согласны с тем, что «это быстроразвивающаяся отрасль, и ни один инструмент не может использоваться вечно»?
Я считаю, что подавляющее большинство из нас ответило бы на эти вопросы утвердительно. И это большой красный флаг. Огромный красный флаг: пора остановить гипертрейн и задуматься о состоянии отрасли.
Ад фреймворков
Чтобы проиллюстрировать свою точку зрения, я приведу общий (и отчасти верный) аргумент против JavaScript и его экосистемы. Каждый месяц у нас появляется новая лучшая в своем классе современная среда или библиотека, которая меняет правила игры, которая перевернет всю отрасль с ног на голову и изменит способ разработки программного обеспечения. Эта новая блестящая технология получила несколько тысяч звезд на GitHub и по мере того, как прошел месяц ее славы, переключает внимание на следующую. И этот цикл продолжается и продолжается ...
То же самое можно сказать о библиотеках, инструментах сборки, менеджерах пакетов и даже языках программирования. Мы тонем в море программных компонентов. Возможно, в зависимости от вашей точки зрения, это можно рассматривать как хороший знак. Составление программного обеспечения из небольших частей многократного использования никогда не было таким простым. Это здорово, я совсем не против. Использование готовых программных компонентов позволяет нам сосредоточиться на текущей проблеме, а не решать более мелкие, слабо связанные задачи для достижения наших целей.
Тем не менее, мы потеряли фокус. Мы обратили это оружие против самих себя. То, что было разработано, чтобы скрыть сложность, вызванную нашими проблемами, стало сложностью и самим монстром.
Вместо решения проблем мы делаем упор на используемую технологию. Вместо того, чтобы предлагать решения, мы продолжаем прославлять используемые нами компоненты и применяемые нами процессы. Энергию и усилие, которые можно было бы использовать, чтобы подтолкнуть нас вперед, высасывают вампиры гипетрейна.
Простота и ценность
ИТ-индустрия и программирование в частности уникальны по ряду аспектов. На мой взгляд, наиболее важным аспектом является то, что написание кода - это искусство. Код - это средство самовыражения. Мы увлечены нашим энтузиазмом по поводу новых вещей, новых способов, всего нового из-за такой природы кода. Каждый художник стремится найти правильный способ выразить свои мысли через эту среду.
Но давайте будем предельно честными. Основная цель кода - решать проблемы. В конце концов, важно то, решили ли мы нашу проблему или нет. Технология, которую мы используем, парадигма, которой мы руководствуемся, количество классов, глубина дерева наследования, абстрактная природа наших классов типов - все это не имеет значения.
Я не призываю нас перестать писать хорошо продуманный, чистый и производительный код. Я не против новых фреймворков. Я пытаюсь указать на то, что вместо того, чтобы использовать их в личных целях, мы должны использовать их для достижения простоты и повышения ценности.
Вам не нужно придумывать умные решения. Вам нужно придумать самый простой, который правильно решит поставленную задачу.
Простота идет рука об руку с ценностью. Если фрагмент кода не имеет ценности и ничего не способствует решению вашей проблемы - это просто ненужно.
Войдите в программирование, ориентированное на опыт
Но где встречаются эти идеи? Какая связь между динамичным характером индустрии, адом фреймворков и идеей простоты и ценности?
Я считаю, что наша отрасль основана на решениях. У нас появляется все больше и больше проблем, требующих решения. Параллельно с этим постоянно возрастает сложность этих проблем. Мы пытаемся справиться с этой ситуацией, придумывая новые инструменты и быстро отказываясь от старых. И в пылу этой битвы мы отвернулись от простоты, полагая, что решения сложных проблем сами по себе сложны по своей природе.
И вот здесь свое место занимает программирование, ориентированное на опыт. Мы должны расширить нашу точку зрения на разработчиков и смотреть на разрабатываемое программное обеспечение так, как это делает заказчик. Опыт работы с клиентом в основном определяется ценностью кода. Их не волнует, будет ли вы использовали Angular или React. Им просто нужен производительный интерфейс. Им все равно, нравится ли вам Bootstrap и ненавидите Semantic. Все, что им нужно, - это красивый интерфейс. То же самое и в других сферах.
Конечно, мы не должны полностью отказываться от нашей точки зрения разработчиков. Хороший код можно легко читать, изменять и поддерживать. И этот хороший опыт на стороне разработчика - результат простоты. Этот новичок в вашем проекте по достоинству оценит простой и понятный код.
Все ваши технологические решения и дизайнерские решения должны указывать на одну цель: максимальное удобство для клиентов и разработчиков. Если вы думаете, что новейший фреймворк обеспечивает лучший опыт, тогда продолжайте и используйте его. С другой стороны, если вам удалось добиться приятных впечатлений с помощью более старого или менее популярного инструмента, у вас нет причин менять его, потому что он служит своей цели.
Вместо того, чтобы быть крутым парнем, который едет по гипертрену, будьте надежным, который обеспечивает постоянный опыт благодаря простоте и ценности.
