что именно? как исправить процессы и тебя за это не уволили?

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

у меня было 3 таких кейса с разной степенью запущенности и 1 стартап где я заложил изначально всё как вижу

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

с менеджментом и продюссерами сложнее, но в целом надо въехать в их категорию ценностей и полезностей и говорить на их языке

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

самое главное забыть фразу «давайте все перепишем» после этого умирают все проекты

нужно вводить плавные меры
условно нет общего кодостайла, то ввести его
это дешево, добиться на уровне инструментария его поддержки

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

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

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

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

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

другой вопрос надо ли оно тебе это все?

ну это ты меня догмами забросал. я в общем-то согласен с много чем из того, что ты перечислил. только я прошу не выводы, а кратко описать свой реальный опыт. "я пришел, было так-то, я сразу понял что нужно улучшить такой-то процесс, через 3 месяца было сделано то-то и начало давать такой-то результат, в итоге это привело к тому что уже через год 45% было доведено до такого-то уровня качества".

Спасибо

Если это как в typescript строки, то вполне норм.
Типа

type MyString = "fst" | "snd"

type AorB = {MyString} { "A" | "B"}

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

Там выше предлагался тайп алиас

Тайпечекеру все равно, строка там или МайСтринг

Те.
type MyType = int

let myfunc (a:MyType) = ()

let a:int = 0

myfunc a
//Compiled

Безопасности не даёт никакой

Мне часто достаточно просто семантики, правильного названия и коммента о его предназначении.

А, ну если тебе достаточно, то другим точно не надо, согласен

Точно ты выше предлагаешь никак от возможности все сломать из Сишарпа не спасает.

а сишарп из с++ можно сломать

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

Аргументы что "всё можно сломать" не являются вескими. Ну можно и можно, все знают что можно. Как это знание тебе помогает то?

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

Помогает тем, что ты не переоцениваешь что-то и после нет разочарований.

Я очень надеюсь ты найдёшь работу по душе и в хорошей команде!

Просто с виду рили звучит не как архитектурная история, а как "пошло оно всё нахуй, заебали"