Идея: willDefineItLater

“Отложить на позже “

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

Зачем это нужно? При разработке любой задачи вам нужно принять кучу решений (design choice) насчет того, как должен вести себя код. Очень много таких решений относятся к сквозной функциональности. Т.е к коду, который по большему счету не несёт действительно ощутимой нагрузки.

20% кода обеспечивает 80% работоспособности. Но оставшиеся 80% очень нужны. Они отличают нормальный продукт от курсовой работы птушника.

Прим.: прошу прощения за притягивание принципа Парето.

Примеры

К сквозной функциональности относятся всякие угрюмые правила:

  • как обрабатывать ошибки и восстанавливаться после них?
  • какие права должен иметь пользователь?
  • в каком виде хранить данные в бд?
  • какие колонки и фильтры должны быть доступны для OData/GraphQL?
  • как должен инвалидироваться кеш?
  • какие колонки должны быть показаны в таблице на UI?
  • какие аргументы являются корректными (контракты)?
  • нужно ли писать в лог и что нужно писать?
  • какие методы доступны всем, а какие только классу?
  • какой тип будет возвращать метод?

Часть этих выборов в 90% случаев будут иметь один и тот же ответ. "Обработка ошибок? - Залогировать, упасть". А в некоторых случаях нужна ручная и сложная обработка ошибок. Хуже того, в любом проекте найдется место, где типичное поведение не подходит.

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

Как уступки делают все хуже

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

К примеру, в C++ вы обязаны указать в лямдах как захватываются переменые. А в остальных языках лямбды текут.

В Rust вы обязаны указать время жизни переменной/поля. А в других языках мы имеем эпические накладные расходы на управление памятью.

Трудно заметить

И получается весьма печальная ситуация: решение выбранное в начале является обычно неадекватным! Или полностью упущеным, принятым на отъебись.

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

А ведь нужно всего лишь дать возможность сказать "я подумаю об этом позже". И кидаться ошибками компиляции в режиме релиза. В идеале компилятор должен давать опускать это указание. Но в релизе все равно ругаться.


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

В итоге получается весьма порочный круг рождения и смерти технологий в зависимости от желания рынка: быстро или качественно. Забавно.

Like what you read? Give Viktor Love a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.