Псевдоархитектурные запреты

Вот тут http://morfizm.livejournal.com/785439.html имеет место некоторая дискуссия по поводу запретов на использование каких-то приёмов, распространяемых на целую архитектуру.

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

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

1. Некомпетентность выносящего запреты. В большой системе нередко просто не существует человека, знающего всю систему в деталях. Поэтому даже располагая ворохом метрик вынести unbiased суждение о необходимости бесповоротных похорон какой-то большой фичи практически невозможно. Люди не делают осознанный выбор, нобелевка по экономике, 2002. И как раз наиболее неадекватные низкого уровня запреты обычно выносятся под трескучие рассуждения об архитектуре и других высоких материях.

2. Вместо запрета чаще всего достаточно разумного ограничения. Скажем, к рассматриваемому случаю очевидно подойдёт ограничение “таймаут сетевой операции в потоке ui не более 500мс”, например. Если мы не успели, выводим крутилку и повторяем запрос в другом потоке (асинхронно). Этот приём – не выдумка, так раньше вёл себя фотошоп.

3. Запреты долго распростряняются. И плохо контролируются. А уж если прижились – очень долго отмирают. В противовес – ограничения принимаются легче и снимаются тоже легче.

Тут есть ещё следствие – недальновидный запрет обязательно попробуют обойти, и это даже может стать систематической практикой. Просто начните набирать в гугле “как обойти запрет”.

4. Обрисовать систему нефрагментарно, используя запреты на технические приёмы как описательный аппарат, весьма сложно. Если по-русски – хрен к какой системе напишешь техзадание, описывая что система делать не должна вместо описания того, что и в каких рамках должна.

Это всё вышесказанное совершенно не отменяет необходимости хорошо проработанных архитектурного и инфраструктурного плана ограничений, “склоняющих писать правильно”. Но полное изгнание фичи из соображений абы чего не случилось – это крутовато.

Ещё на сопредельную тему – Соглашения vs конфигурации.