![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
"С быстрым компилятором workflow намного более гладкий"
У меня на тему популярности Delphi и Firebird на постсоветском пространстве была такая мысль: простота языка и среды и большая скорость компиляции в дельфях, а так же удобство использования Firebird при разработке привели к тому, что одного среднего программиста было достаточно для реализации достаточно приличного размера проектов (ну там 150-200 kloc - это вот типичное, во что можно уместить неплохую опердень).
И это сыграло злую шутку - без работы в команде (за отсутствием оной) и контактов с внешним миром в стиле "опять не пойми чего наделали в 100501-й библиотеке на Ц++/рубигеме/надо новый буст" люди окукливались и начинали варится в собственном соку, не использовать контроль версий и игнорировать регресс разработки и продажи софта до состояния "надо бежать, чтобы оставаться на месте". А потом херак - и восьмые винды, вижуалстудии, корявые линуксы с корявыми методиками деплоймента и пакетными менеджерами, жабы с мавенами, гит, андроиды с корявыми SDK и прочее разложение, а мозг то привык к удобству работы.
И это сыграло злую шутку - без работы в команде (за отсутствием оной) и контактов с внешним миром в стиле "опять не пойми чего наделали в 100501-й библиотеке на Ц++/рубигеме/надо новый буст" люди окукливались и начинали варится в собственном соку, не использовать контроль версий и игнорировать регресс разработки и продажи софта до состояния "надо бежать, чтобы оставаться на месте". А потом херак - и восьмые винды, вижуалстудии, корявые линуксы с корявыми методиками деплоймента и пакетными менеджерами, жабы с мавенами, гит, андроиды с корявыми SDK и прочее разложение, а мозг то привык к удобству работы.
no subject
Если это поле используется для вычислений и наличие его значения обязательно - да, статик типы сразу становятся лучше - проблемы детектируются на этапе компиляции. Для этого я использую кодогенерацию из моделей и БД и ORM и классов.
Если значение поля используется для вычислений, но наличие значения не обязательно и есть разумное значение "по умолчанию" - то лучше его сразу использовать в стиле fieldValue = resultset.GetField("name", defaultValue) + опциональный warn в логи на отсутствие поля. Т.е. динамические типы (== ассоциативные массивы, хэш-мапы и самодельные dynamic в дотнете). И прочие null/Option/Maybe и fromMaybe.
Если же все назначение поля - это протащить его от запроса до сериализации в JSON или показа в гриде - то можно вообще изменения игнорировать, а проблемы если и будут на стороне фронт-енда, то они не критичны. Если делать аккуратно - любые проблемы фронтенда не должны приводить к повреждению состояния БД и бизнес-логики на бэк-енде. Пользователи сами сообщат, что поля не видят, или что вместо поля видят надпись "field 'Worm' not found".
А делать софт, который всерьез сломается от мелочей вида "пользователь увидел корявое сообщение" или "от пользователя не пришло значение поля" - паук не велит. Т.к. от сторонних инфраструктурных косяков статик типы не защищают и проблемы с внешней по отношению к нашему софту дурью всегда будут, от этого надо защищаться или уметь переживать.
А чтобы защитится от проблем вида "изменили поле" с помощью статик типов полноценно - это нужен вывод типов в рантайме, т.е. подключаемся к БД - загружаем метаданные всех запросов, выводим типы и ругаемся юзеру, в логи и разработчику в мониторинг, если что не так. Ни один современный язык этого не умеет, поэтому можно не дергаться :)