(UA) IT/Tech Ukrainians in Canada
-
думаю все від проекту залежить, бачив там багато команд без BA/PO - про який повний цикл у такому випадку йде мова?
-
Є такий вираз "product mindset", коли людина вболіває за результат і зробить все, навіть не свою роботу, навіть пофіг на правила, процеси і т. д., якшо воно аргументовано і призведе до результату. На аутсорсерах такий підхід не завжди популярний. ІМХО час від часу в аутсорсерів популярніше розказувати, який заказчик нудак, нічо не знає і оті от хотєлки не по процесу. Ото десь така різниця, яку замічаю. Воно не сильно виражено, але деколи замітно
-
У мене є на думці певна послідовність, хочу дізнатися як мені її вирішити. Уявімо що у людини є product mindset, тобто вона євангеліст якості коду до глибини душі, розуміє що є баланс між імпактом і технічним боргом який нікому не потрібен (наприклад немає сенсу переписувати легасі сервіси які навряд будуть замінені або активно розроблятися найближчим часом). І от, наприклад, є сервіс в активній розробці, але контрібьютить в нього індус який пише, умовно, на Scala не знаючи мови, ну тобто через певний час код буде важко підтримувати в принципі, не кажучи вже про відсутність high cohesion, low coupling, solid etc. Що робити людині, якщо blaming - не прийнятний варіант, а будь-яке нарікання на якість коду це блеймінг і айайай. Як ви здогадалися то на code review в подукті всім насрати, бо сумнівний код регулярно заїзджає в default branch. Що б робили ви?)
-
ну як, ну такий рівень розробників що вони або роблять аби як або не бачать проблем
-
так є ж)
-
Я просто хочу почути якусь story with happy end де один інженер переміг boiling frogs syndrome)
-
Я роблю 90 рев'ю на місяць, і дрючу їх по всіх фронтах 😁 не тільки логіка структура патерни бест пректісес тести і все таке інше, а й variable, class, method naming, alphabetic ordering, xml файл з код стандартами є для ide, вони чітко прописані. Також на пропускаю оверінженірінг чи yagni. Але якщо рішення чи синтаксис прийнятні, але я б зробив трохи по іншому - не придовбуюсь. Так само ревьюить ще пару людей - як результат, код у нас не ідеальний звісно, але досить на високому рівні.
-
Продовжуючи тему ресторанів … The significant infractions included "use utensils not of readily cleanable form," and "use dirty cloth for cleaning food contact surface." www.blogto.com/eat_drink/2023/06/yu-ki-japanese-restaurant-toronto-dinesafe/
-
це і для України актуально, якщо на проекті не біда
-
Йой, шось ви стільки всього намішали... Продакт майндсет не має ніякого відношення до євангелістів якості коду. 2. Ви назвали вже запущену ситуацію. Продакт майндсет - це не означає бардак повний, і то не означає фанатизм на технологіях. Здоровий глузд ніхто не відміняв. Тому в першу чергу я би спитав якого фіналі той тіп робить ту тачку на Скалі, про яку нічо не знає. Нафіга нам вопше та скала, якої ніхто не знає і хрєн наймеш когось. І звичайно, шо були би код ревю, були би налаштовані сонар, були би вимоги по автотестах. То, шо хтось обижаться на код ревю - то або ви не вмієте фідбек давати, або він сприймати. Ото вище було би на норм проекті шо в аутсорсері, шо в продукті. Так вот продукт від аутсорсингу відрізняється тим, шо може прийти начальник, сео, менеджер і сказати - якшо ми то зробим за Х часу, ми отримаємо дуже жирного клієнта, а не зробим - отримаєм судовий позов. І в аутсорсингу можуть почати жалітися на заказчика, тикати процесом і т. д. Не завжди, але буває. А в продукті - впряжуться і вирулять, навіть, якшо тимчасово тре буде відключити статичний аналізатор коду, рул по код кавередж по тестах і т. д. Бо контракт з жирним клієнтом важливіший від красоти коду. І то важливо розуміти. Код можна і порефакторити потім, скалу можна викинути, як ніхто не знає, а клієнт як пропав, то вже все, то вже втрачені гроші.
-
Бо Канада 😄
-
Але звісно рев'ю робиться ввічливо та переважно у запитувальному тоні, "а чи не краще зробити так?", або "хіба нам справді це тут треба?" - а не "шо це за гівно, ти мудак, переписуй все наново" 😂
