Программирование, ориентированное на лень

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

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

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

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

Мы ленивы?

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

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

Хорошо, технологии — это хорошо, но как профессионалы в области программного обеспечения мы ленивы? Я говорю, что мы.

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

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

Но давайте копнем глубже: вы когда-нибудь разрабатывали механизм, потому что были ленивы? У меня есть.

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

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

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

Что теперь?

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

Не открывайте шампанское, лень открывает возможности для великих идей, но вы должны быть осторожны-

Не каждая проблема нуждается в универсальном решении
Это не лицензия на игнорирование тестов или безопасности.

Не каждая проблема нуждается в универсальном решении

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

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

Он служит вашим потребностям
Накладные расходы стоят усилий, которые они экономят

Если вам нужно разработать решение, вам нужно быть гораздо более осторожным.

Тщательно оцените усилия
Убедитесь, что это экономит достаточно усилий
Если существуют конкурирующие решения, есть веская причина написать новое («мое лучше», это не причина)

Не игнорируйте необходимость тестов и безопасности

Нас часто вынуждают просто зафиксировать + отправить код без автоматических тестов. Я могу понять давление со стороны разработчиков, тем более что сделать хорошие автоматические тесты в CI сложно.

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

В основном, игнорируя тесты автоматизации, мы верим в удачу или молимся за нее. Хотя я считаю, что всегда есть элемент удачи, потому что не все стоит автоматизировать, я предлагаю стремиться к автоматизации.

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

Причина в том, что синтезировать или имитировать данные и ключи утомительно. Я призываю вас удалить все конфиденциальные данные из ваших репозиториев, использовать секреты, моки, синтезировать или очищать ваши данные.

Это навык, который я призываю вас продолжать развивать, учиться.

Написание издевательств
Использование секретов
Безопасное программирование

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

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

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