RK
На практике это нихрена не проще, как часто ты делал BFS на N-tree с произвольным N вручную?
Size: a a a
2018 December 13
RK
Опять же - пазлы. Ты там бота писал для них, помнится мне. При этом ты говорил, что сделать за тасками задача архитектора и в том числе их реджектить/пускать в работу. Тогда Рома М. абсолютно прав - архитектор будет тупо следить за тасками, т.к. его ими просто завалит в большой команде
RK
Если будет: пазл на бизнес логику для реста, пазл на апдейт схемы, пазл на тест, итд
RK
И так вся команда из 20 рыл
SK
Опять же - пазлы. Ты там бота писал для них, помнится мне. При этом ты говорил, что сделать за тасками задача архитектора и в том числе их реджектить/пускать в работу. Тогда Рома М. абсолютно прав - архитектор будет тупо следить за тасками, т.к. его ими просто завалит в большой команде
Не завалит. Паззлы становятся тасками в момент закрытия PRа. Не нравится что в PRе - режекть или ремарки давай. По пазлам
RK
Ну так идея пазла в том, что ты как бы откладываешь основную часть работы на потом. Соответственно, если я большую часть твоей работы, кроме интерфейсов/абстрактных классов не вижу - с какой вероятностью я могу здраво рассудить реджектить мне твой PR или нет?
RK
50/50?
RK
И потом это ж сколько сил надо вбухать, чтобы объяснить команде как это говно устроено и что не надо на каждый чих пихать паззл?
SK
Ну так идея пазла в том, что ты как бы откладываешь основную часть работы на потом. Соответственно, если я большую часть твоей работы, кроме интерфейсов/абстрактных классов не вижу - с какой вероятностью я могу здраво рассудить реджектить мне твой PR или нет?
Ну так пазлы не должны быть one-linerами, они должны развернуто пояснять - что надо сделать, почему, где и как? Чтобы и ревьюеру было понятно, и будущему девелоперу, которому этот пазл достанется
SK
Если пазл не такой - нехер его пропускать
RK
Воот, вот это интересный поинт
RK
и будущему девелоперу, которому этот пазл достанется - то есть даже самую простую таску, типа запилить эндпоинт, могут делать несколько разных человек.
RK
Knowledge transfer hell?
RK
Или LOC комментов >> LOC бизнес-логики?
SK
Knowledge transfer hell?
Про траснфер знаний вчера флеймили. знания должны быть в проекте, а не в головах девелоперов.
SK
Девелопер - штука непостоянная. Завтра уйдет, а ним удут и его знания.
SK
Жесткий диск никуда от тебя не уйдет
RK
Соответственно, хреначим больше комментов, файлуха вытерпит, нахрен писать логику.
RK
“Архитектор, тормозни дедлайн, я тут придумываю коммент?”
SK
Соответственно, хреначим больше комментов, файлуха вытерпит, нахрен писать логику.
Почему "нахрен писать логику" то?