Новости

Jul 11, 2023

Если вы хотите обеспечить быструю доставку, последнее слово будет за вашими тестами

Домашняя страница InfoQ Статьи, если хотите

Домашняя страница InfoQ Статьи Если вы хотите обеспечить быструю доставку, последнее слово будет за вашими тестами

6 июня 2023 г., чтение на 23 минуты

к

Хорхе Фернандес Родригес

рассмотрено

Мэтт Кэмпбелл

Я думаю, вы согласитесь, что разработка программного обеспечения особенная по сравнению с другими профессиями. Все меняется кардинально и быстро. Чтобы оставаться в курсе событий, требуется много умственных способностей.

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

Проблема в том, что мы хотим, чтобы разработка программного обеспечения вела себя как сборочная линия: как только сборочная линия построена, мы никогда к ней не прикасаемся. Мы все время действуем одинаково. Какое-то время это может работать с нашими линиями CI/CD, но, к сожалению, это не всегда хорошо работает с нашим кодом.

Легко переходите в облако и невероятно быстро внедряйте инновации с помощью Kalix! Создавайте высокопроизводительные микросервисы и API, необходимые NoOps. Узнать больше.

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

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

Одним из примеров этого является множество способов неправильного толкования Agile. Суть в некоторых случаях потеряна.

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

Мы пытаемся добиться такой оперативности с помощью практик разного характера: технических, таких как CI/CD (непрерывная интеграция/непрерывное развертывание), и стратегических, таких как итерационная разработка. Однако мы часто забываем об гибкости, когда имеем дело с ядром разработки программного обеспечения: кодированием. Представьте себе, что вы готовите любимое блюдо или десерт без основного ингредиента рецепта. Это то, что мы делаем, когда стремимся к гибкости, не учитывая код.

Это может произойти потому, что улучшение кода звучит пугающе и сложно, или может быть легко попасть в кроличью нору (все это можно легко устранить). Возможно, это просто потому, что нелегко увидеть негативное влияние некоторых решений на нашу маневренность; превращая будущие разработки в кошмар: противоположность гибкости. Вместо того, чтобы сосредоточиться на коде, слишком много внимания уделяется достижению совершенства в наших процессах (таких методологиях, как Scrum), которые менее важны и пытаются решить проблему, не затрагивая основную проблему.

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