(UA) IT/Tech Ukrainians in Canada
-
Мені здається, все ж таки у вас сторі пойнти скоріше сприймаються як міра часу, що невірно. Об'єктивна складність окремого тікета не залежить від рівня розробників, і якщо є така ситуація, що хтось постійно ставить вищі бали, це може просто говорити про недостатнє обговорення тікету на рефайнменті, недостатньо детальний опис чи потенційно завеликі тікети, які треба ділити на менші. В команді, в якій є джуни, мідли і сіньйори, середня продуктивність на людину в сторі пойнтс пер спрінт все одно має бути приблизно на рівні мідла, тому що сіньйори втрачатимуть більше часу на код рев'ю та менторінг, а джуни будуть підтягуватись завдяки менторінгу, pair programming, etc
-
«Чому саме 5 а не 2» - людина відповідає «ну там же не просто 1 строчку поміняти, там же мені ще треба потестити та юніт тести написати» І все. Не поспориш. Тестити можна від забору і до обіду. Писати юніт тести теж понятіє растяжимоє - можна 2 написати, можна 20, і все це прокатить як «писав два дня юніт тести»
-
Ще скажу таку річ, сіньйор, який просто кодить швидше за інших - це не сіньйор, це стронг мід :-)
-
Тю Менторинг не повинен залежити від бажань керівництва чи наявності dedicated meetings/time slots 😊 Мідл: "а як краще оце зробити?" Сіньйор: "отак" Це не менторинг Сіньйор: "тут є декілька варіантів, оце неприйнтяне тому що ..., оце більш менш, але не дуже, тому що ..., а оцей варіант працює краще за все - ми використаємо такий-то паттерн, що дозволить нам підвищити readability/maintainability, а абстракція отак і отак суттєво підвищить reusability" Оце менторинг (хоча й дуже банальний приклад) - і для нього не треба окремі мітинги, це може і має відбуватись щоденно, тому що гарний сіньйор - це людина, до якої ти прийдеш з питанням, а підеш не тільки з відповіддю, але й з новими знаннями. Якщо когось взяли на сіньйора, а він не тягне - це має бути видно в quarterly чи якихось там review, і далі то вже задача менеджера розбиратись, що робити далі. У мене в команді, коли я був тім лідом, був випадок, коли взяли дуже язикатого чувака на міда, а він в кращому разі був середнім джуном. Зробили все можливе і неможливе, щоб його підтягнути, але - просто може це не його - не вдалося, тому просто звільнили
-
А зачем они нужны? Шо плохо на темплейтах работает? Как то жили без этого, но нееееет, давайте из кнопок делать калькулятор
-
Бачив колись як бекендери пробують фронтовий код писати?)
-
опять фронты говорят шо они тоже погромисты?
-
ясно шо кожен девелопер hates unit tests with a passion 😃 я теж але намагаємось покрити шо можемо, хз шо там на фронті, подивлюсь уважніше завтра шо наші фронти роблять ) на бекенді звісно теж є речі, які або не потрібно, або неможливо покрити юніт тестами
-
На практиці (фронтенду) покривають відсотків 20, бо багато чого або не має сенсу покривати, але занадто багато часу займає
-
Не погоджусь 😊 public function ()... { } Юніт тест кейси для цього методу виглядатимуть так - testWhenSucceededConditionScenario1 - testWhenSucceededConditionScenario2 - testWhenExceptionThrown1 - testWhenExceptionThrown2 Дуже грубо, але має бути зрозуміло Тобто кількість юніт тестів - це не якась рандомна величина, це необхідня і достатня кількість кейсів, щоб покрити всі можливі маршрути в коді
-
Я закинул удочку и жду пока все фронты соберутся вместе во взрослого разраба
-
Товсто якось, аж овочі на таком можна смажити
-
я забув шо у вас нема qa 😆
-
Повертаємось до того, що пойнти - це не міра часу на "скільки подумати" ) Але ми здається почали ходити по колу вже )
