когда писать код, а когда просто делать

1656577351 kogda pisat kod a kogda prosto delat

автора Рина Арстейн

1*0BIInBkbvWUbf2j1krD2Iw
Фото Оливера Рооса на Unsplash

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

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

Кодирование длинного пути (короткого)

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

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

Следует ли выполнять задачи как можно быстрее или тратить время на создание инфраструктуры, которая облегчит выполнение будущих задач?

Стоит ли выбрать короткую дорогу, которая может оказаться длинной, или длинную дорогу, которая действительно поможет вам быстрее достичь цели?

Пример (на основе реальной истории)

(Некоторые детали были изменены или опущены для простоты и, ну, для лучшего рассказа. Реальность слишком бессвязна.)

Однажды ко мне подходит мой начальник и просит быстро получить некоторые данные из БД и отправить ему в качестве таблицы Excel. Это было не очень сложно, потому я сделал это сразу.

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

Нет проблем! Вот так, какой-нибудь фронт-энд, какой-то бэк-энд, разверните. Подождите. Подождите. Подождите. Развертывание завершено, отчет появляется в режиме онлайн.

Проходит несколько дней, и меня просят предоставить еще один краткий отчет и «сделать это с помощью того хорошего интерфейса и фильтров даты, которые вы дали нам в прошлый раз». Да, конечно. Нет проблем. Front-end, back-end, развертывание, ожидание, онлайн.

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

Вот что я сделал за свои два дня:

Я определил условие для сохраненной процедуры отчета, которая ожидала получить следующие параметры:

  • С даты
  • На сегодняшний день
  • Начать с индекса (для страниц)

Каждая процедура возвращала набор результатов запроса и общее количество результатов (для просмотра страниц).

Кроме того, я добавил таблицу отчетов, содержащую:

  • Имя сохраненной процедуры (для выполнения)
  • Название (доклады)
  • Описание (отображается на странице отчета)

Я также добавил конечную точку на сервере, пользовательский интерфейс и некоторую логику к:

  • Проверьте БД на наличие отчетов и добавьте их в навигацию сайта.
  • После доступа к отчету выполните соответствующую сохраненную процедуру и верните результат в пользовательский интерфейс.
  • Отображение двух способов выбора даты для выбора с даты и даты завершения и выполнения запроса.
  • Общая таблица для отображения результатов отформатированных в соответствии с типом данных каждого столбца. (У меня уже был общий компонент пользовательского интерфейса для подкачки, ага!)

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

Единственная константа – это изменение

Все были довольны и очень в восторге от функции отчета об экономии времени, но… А как насчет сортировки? И можем ли мы иметь ссылку на первый столбец на профиль клиента? И можем ли мы добавить фильтрацию торговым представителем, ответственным за клиента?

Да! Конечно. Это имеет большой смысл. Поэтому я добавил:

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

Счастливый счастлив, радость радость. Но… Как насчет группировки результатов? А когда вы щелкните строку, можете ли вы отправить электронное письмо группе предварительно определенных пользователей? А когда торговый представитель входит в отчет, могли бы вы отразить отчет его любимым цветом? (Хорошо, я придумал это последнее)

Не спешите

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

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

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

Требование по группированию было более сложным: группирование является распространенным и очень полезным сценарием. Добавлять его в свою инфраструктуру или нет?

Ну а что нужно для группирования результатов?

  • Добавление флага Group By к записи БД отчета, чтобы логика знала, что ожидает два разных набора результатов – заголовок группы и детали группы.
  • Логика также должна знать, как согласовать группу с деталями, и это нужно было бы делать по условию. Чрезвычайно рискованное дело.
  • Выяснение того, как общая сортировка результатов с помощью заголовка группы. Я даже не могу.
  • И, возможно, еще какие-то проблемы, о которых я не думал.

Код не написан

Я не прибавил группировки.

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

Но на самом деле мне не следовало писать ни строчки кода. Мне следовало рассмотреть инструмент отчетности.

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

Что теперь?

Итак, как вы должны решить, писать какую-нибудь инфраструктуру или просто делать это? Вот как я решу:

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

Нравится то, что вы прочли? Поделитесь любовью, хлопая. Есть вопросы или комментарий? Дайте мне знать в разделе комментариев.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *