(UA) IT/Tech Ukrainians in Canada
-
Тобто, через те що на плануванні потребують «таку оцінку, що підійде всим» вони більше під слабших людей, бо слабші люди голосують за оцінки повище. Далі, коли сеньор бере таку «переоцінену» таску, це вже залежить від його настрою/лінивості/упоротості/чесності він зробить за стільки як оцінено (оцінено мідлом по суті) чи швидше
-
У нас на рефайнментах якщо є такий розброс (хтось каже 2, хтось 3, а хтось 5) - ми не ставимо просто найвищий, а просимо аргументувати, чому саме 5 (або 2), і в процесі обговорення краще розуміємо один одного та погоджуємочь на якусь цифру
-
Мені здається, все ж таки у вас сторі пойнти скоріше сприймаються як міра часу, що невірно. Об'єктивна складність окремого тікета не залежить від рівня розробників, і якщо є така ситуація, що хтось постійно ставить вищі бали, це може просто говорити про недостатнє обговорення тікету на рефайнменті, недостатньо детальний опис чи потенційно завеликі тікети, які треба ділити на менші. В команді, в якій є джуни, мідли і сіньйори, середня продуктивність на людину в сторі пойнтс пер спрінт все одно має бути приблизно на рівні мідла, тому що сіньйори втрачатимуть більше часу на код рев'ю та менторінг, а джуни будуть підтягуватись завдяки менторінгу, 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 Дуже грубо, але має бути зрозуміло Тобто кількість юніт тестів - це не якась рандомна величина, це необхідня і достатня кількість кейсів, щоб покрити всі можливі маршрути в коді
-
Я закинул удочку и жду пока все фронты соберутся вместе во взрослого разраба
-
Товсто якось, аж овочі на таком можна смажити
