MaratMS, сначала вкидываешь предложение на совещании добавить тс, вкинув пару плюсов от этого решения. Решение, скорее всего, отвергнут, с чем ты согласишь.
Далее в некоторых тасках, которые выполнялись долго, вскользь упоминаешь, что с тсом это было быстрее, а если ещё и какая-то глупая ошибка где-то вылезла, то ещё и намекаешь, что при тсе такого не было бы.
Так глядишь и появится шанс внедрить его.)
А пока жсдоком пользуйся, у него неплохие возможности по типизации.
Вот самый хороший пример, на который я натыкался: https://github.com/developit/redaxios
Единственное там ошибка, create должен возвращать тип самого redaxios, но это мелочь, тот же тс с ним нормально работает.
Aetae, согласен, тем не менее это никоим образом не отменяет уязвимость данного решения. Даже добавление ещё одного интерфеса несёт за собой кучу геморроя, как и переименование ИД текущих.
Aetae, так такое и не пройдёт, если пихать uuid напрямую в объект.
В текущих примерах всё захардкожено, поэтому ошибки не будет, но в реальном коде будет.
morsian1996, эээээ... Ты точно прочёл то, что я написал? Третьестепенные задачи ─ это задачи, которые на продукт влияют максимально минимально. Так зачем на это нанимать отдельного человека, когда это сделает команда, только чуть позже. А с учётом того, что такие задачи будут зависеть от основных, то "третьестепенный" разработчик будет постоянно сидеть и в носу ковыряться, ожидая пока полноценные разработчики закончат таск.
morsian1996, то, что ты предлагаешь, это программист, который хуже I в основных и второстепенных задачах, и хуже T в третьестепенных задачах. И зачем ты такой нужен?
Почему ты не подойдёшь даже для второстепенных задач? Потому что как, почему и на чём будет работать софт определяется ДО его реализации в коде, соответственно набираются специалисты по нужным направлениям и второстепенные задачи будут тесно связаны с первостепенными.
В итоге ты ожидаешь, что кто-то всерьёз будет брать человека на решение только третьестепенных задач?
