VC
а где гарантия что сеньор не несет дичь?
гарантий нет, так же как нет гарантий, что сейчас в проекте не дичь ) С другой стороны, собесы нужны в том числе и для отсекания несущих дичь )
Size: a a a
2021 March 11
SZ
ага, в истории коммитов человек есть, а в джире нет
у нас когда продукт ушел. мы пачку его фичей нахер снесли, потому что кроме него мало кто в курсе о них был😂
ИЛ
у нас когда продукт ушел. мы пачку его фичей нахер снесли, потому что кроме него мало кто в курсе о них был😂
он их для себя пилил, что ли?
ES
Бюджет если только)
SZ
он их для себя пилил, что ли?
многие пилились как пилотные проекты, которые по какой-то причине не взлетели или не зашли юзерам. а обратную задачу на спилить никто не давал сразу
ES
А обратная задача по идее уже не от продуктов должна исходить
SZ
чтоб понимал на сколько масштабно - у нас была целая апка для производителей, ей как оказалось никто не пользовался. но продукт не давал ее снести) как только ушел то моментально улетело в помойку😃
SZ
остальные манагеры были более сговорчивые
SZ
А обратная задача по идее уже не от продуктов должна исходить
ну эт уже о жизненном цикле фичи. лучше этот цикл контролировать)
ES
остальные манагеры были более сговорчивые
Сложно согласиться когда изобрёл велик а он не поехал)
SZ
Сложно согласиться когда изобрёл велик а он не поехал)
это тоже да. поэтому и говорят что код надо писать чтобы он не легко расширялся, а легко удалялся)
ES
Delete driven development
SZ
https://programmingisterrible.com/post/139222674273/how-to-write-disposable-code-in-large-systems шоб опять не сказали что я тут чета выдумываю
SZ
https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ вот тут про это еще прилично написано
ES
Даже книжки уже про это пишут
SZ
канеш. есть легендарная https://www.oreilly.com/library/view/working-effectively-with/0131177052/
SZ
но там мозг сломать можно от кол-ва c++
ES
+500 к зп на последней странице
AM
я вот вынужден от 3 до 6 лишних файлов править просто потому что нет автовайринга и в сервисе часть вызовов не проксируется, а надо каждый новый прописывать
Напомнило slim + pimple
AM
https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ вот тут про это еще прилично написано
Когда с одной стороны советуют следовать рекомендациям и практикам Гугла, а с другой стороны сотрудники из него уходят и жалуются на игнор инициатив по важным вещам, как при перфоманс ревью, к примеру...