Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Як ви вирішуєте спірні питання в роботі?

Така от ситуація. Кодимо апку на реакті. Я відповідаю за сторінку редагування сутності. З часом помічаю що при кожному onChange уся сторінка з кожним копонентом перерендерюється. Додаю memo() та трошки переписую архітектуру, — заміняю реакт контекс на проперті дріл.

Пізніше колега, пропонує переписати сторінку, бо її код виглядає трошки не красиво. Я пояснюю причину такого стану речей і кажу з якою метою написав саме так. Він же стверджує, що трохи лишнього ререндерінгу ніби не створює якихось суттєвих проблем.

Короче, хочу почути як ви вирішуєте суперечки подібного роду. Як часто ви «доводите» свою точку зору. Як правильно це робити, щоби не зіпсувати відносини з колегами.

UPT: короче зійшлись на тому що трохи лишнього рендеру це таки погано, «некрасиві» зміни відрефакторили настільки наскільки це було можливо і додали ще некрасивих змін. стало ну дуже некрасиво, зате дуже швидко.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Як ви вирішуєте спірні питання в роботі?

Демократией жеж. Собирается вся команда, ей представляются разные варианты решения — и команда демократическим голосованием выбирает. Зэка. Или там, клоуна...

Если коллега — не тимлид, то никак не нужно ничего доказывать.

Цим ви по суті провокуєте відкритий конфлікт

Пишу пост на ДОУ, прошу поради і поступаю так, як мені порадять.

Типовий підхід мілленіалів ))))

Називаєте це тімбілдінгом і чек потім не забудьте занести в бухгалтерію

1. Собирается компания тех, кого затрагивает решение
2. Оппоненты выдвигают свои аргументы каждый по 5 минут
3. Компания выносит вердикт за 5 минут
4. Принятое большинством — утверждается всеми
5. Кейс закрыт, большинство довольно

А якщо замовник потім не затвердить?

Использовать soft skill и он утвердит.

Я делаю так, как скажет старший по званию. Какие будут последствия — не мои проблемы.

А якщо старший в даний момент ви? Решта хворіють, у відпустках і т.д.

проигравших оппонентов легко определить по синякам

та трошки переписую архітектуру, — заміняю реакт контекс на проперті дріл.

Ви відповідаєте за архітектуру проекту, це входить в обсяг Ваших компетенцій — вирішувати де які підходи використовувати і переписувати архітектуру?Тоді і питань нема.
Інакше, йдете до старшИх, вони вже вирішують, але ж не з аргументами ’її код виглядає трошки не красиво’, ’трохи лишнього ререндерінгу ніби не створює якихось суттєвих проблем’ - це булшіт.
З pros and cons по Context API vs. Property Drilling на зараз і можливі проблеми в майбутньому і з конкретними метриками по ререндерінгу, щоб визначити наскільки це допустимо чи ні.

Тут надо понимать, что именно вы делаете и какой контекст разговора. Что важно для бизнеса ?
какие характеристики системы важны ?
К примеру — если важна производительность, то Вы можете спокойно построить диалог след. образом:

— разговор — это хорошо, но давайте померяем затраты ресурсов. конкретно проведем бенчмарки

Ведь лишний рендеринг, это:
— лишние затраты CPU
— лишние затраты памяти
— лишние затраты сети (в некоторых случаях)
— соот. это лишние расходы клиента — к примеру батарея
— многие люди вполне способны это заметить. Особенно это заметно на нагруженных машинах или со слабым CPU. или на моб. клиентах. А это уже прямой негативный опыт пользователя

и так далее

А нафіга вам доводити свою точку зору? Якщо ви будете не праві — ви будете винні! Я не доводжу свою точку зору, я скоріше намагаюсь спихнути відповідальність. У цьому випадку — фічу пилили таки ви, то мабуть ваша зона відповідальності. Тому якщо просто так послухаєте і воно потім буде тупити, то вам влетить за його помилку. Але якщо він хоче відповідальність взяти — хай, тоді вже він буде винний, якщо воно тупити буде, він кака ви цяця, на рівному місці.

Взагалі — ієархія і розподіл обов’язків.

Якщо це не твоя зона відповідальності — твоя думка важить менше. Ну і якщо шо — йдіть до ліда, техліда, вони за все відповідають, крім іншого. Ну і намагайтесь аргументи викристовувати, загалом, якщо нема переконливих аргументів, то пофіг шо робити, фігня буде у будь якому випадку, приблизно однаково погана =) В мене не багато бажаючих взяти відповідальність лишається, після того як я аргументи викладу.

Если коллеги не на одной волне, то самый эффективный способ — показать примером и крепким агрументом. В вашем случае замеры таймингов рендеринга в масштабах более сложных разметок и отсылы к best practices могут помочь. А могут и нет. В авторитарных коллективах часто последнее слово будет за альфа-самцом и даже если он не всегда по делу говорит. В принципе вариантов несколько:

1. Путь «дипломатии» или «мягкой силы»: если нашли хорошее решение и считаете что оно верно, доносите свою мысль всем коллегам, общайтесь, объясняйте, показывайте. Если упираетесь в железобетонное НЕТ от одного или нескольких коллег, попробуйте выслушать и понять их аргументацию. Пытайтесь найти компромис и золотую середину. Практикуйте и оттачивайте софт скилы постоянно и уверенно. Вода камень точит.

2. Путь бусидо или путь воина: Кодекс чести (использование лучших практик, соответствие стандартам индустрии, непринятие полу-решений) превыше всего. Это ваше кредо с которым вы идете по жизни и профессии. Иногда полу-решения необходимы для бизнеса, нужно уметь идти на уступки, но быть настойчивым и всегда закрывать долги после таких мер.

Путь дипломатии конечно очень хорошо прокачивает софт скилы и наоборот чтобы прокачивать путь дипломатии нужно прокачивать софт скилы.
Путь воина предполагает что у вас есть большие яйца и вы готовы к конфронтации. Я набил много шишек на этом методе за свою жизнь. В итоге софт скилы здесь прокачиваются не меньше, а то и больше. К кодексу бусидо добавляется идея поиска идеального коллектива (читай фул agile), организации в которой нет иерархий и flat-структура не пустое слово. Вы должны быть готовы в любой момент взять свой вещмешок и идти дальше в поисках другов самураев которые следуют пути бусидо. А это много собеседований и компаний. Вы несете свои идеи и посвящаете в них молодых и еще не видавших сражений бойцов... Честь и кодекс — превыше всего.

В независимости какой путь выберете нужно взращивать свой авторитет и постоянно практиковать и оттачивать навыки оратора и лидера и естественно быть техническим гуру в своей области.

Ще добавлю пару варіантів
3. Достати всіх мітингами на цю тему. Чим більше мітингів тим краще , щоб в кінці вже всі просто погодились, аби від них відстали.
4. Інверсія пункту 3. Постаратись продавити твій варіант як «тимчасове» рішення і хай інші сетять мітинги, готують докази та приклади, чим твій підхід гірший.

Оо, бачу пан справді має великий досвід

замеры таймингов рендеринга

І на цьому можна було б і закінчити. Хоче колега переписати на якийсь там на його думку кращий код — та будь ласка, якщо покажеш в результаті кращі таймінги. Ми ж не в мистецтві якомусь там працюємо, де у кожного своя думка, що є прекрасним, а що ні, а в якому не якому, ІТ. Намалювалась сторінка швидше — все, переможців не судять.

Алгоритм:
— что это за кусок го*на"трошки не красиво", тут нужно все переписать
— переписываешь код тратя уйму времени
— передаешь эстафету следующему

що трохи лишнього ререндерінгу ніби не створює якихось суттєвих проблем

Поэтому я возненавидел фронт, пихают это спа куда надо и не надо, в итоге оно тормозит и постоянно перерендеривает или переколбашивает данные по 100500 раз, забыв вообще зачем этот спа делался.

Но ничего страшно, подкинут планочку памяти, добавят ядрышек в проц и формочка будет крутиться чуточку быстрее :-)

А когда спа пихают туда куда надо то все ок?)

Деяким фронт-ендерам точно не завадить час від часу виходити з фронт-енд задзеркалля.

Так як і бекендерам, та і всім вузьколобим

Я мав на увазі не вас конкретно.

ноу проблем
Я теж не мав на увазі когось конкретно ображати.

Главное — успеть втащить первому.

бо її код виглядає трошки не красиво.

нехай формально пояснить що такє — не красиво ;)

а взагалі, доводити свою точку — ризикова справа для збереження стосунків, якщо не маєш авторитету серед колег, або підтримки колег наступного рівня, «старших» колег, тех лідів.

і треба з’ясувати для себе, що для вас в приоритеті, поставити АБО
технічная досконалість вашого рішення АБО не зіпсувати відносини з колегами

можливо треба відійти від свого рішення, але: якось, десь зафіксувати, оприлюднити свою особисту думку. хоч у комент до таскі додати шмат свого коду (якщо то суворо не заборонено правилами).

Загальна ж порада:
шукати компроміс, тобто такий варіант який не подобається нікому, але всі з ним згодні.

але як з всякою загальною порадою — практичної користі від неї небагато.

суперечки ж будуть завжди
бо програмування — то не математика:
не існує ідеального рішення, існують лиш декілька прийнятних, та купа неприйнятних. Причому оті прийнятні рішення можуть бути несумісними.

Він же стверджує, що трохи лишнього ререндерінгу ніби не створює якихось суттєвих проблем

і можливо він правий :)
станьте «адвокатом диявола», та спробуйте розкритикувати своє рішення з його позиції, знайдіть раціональне зерно у аргументах опонента.

І слухаю, як ви, засранцi потнi
Отут патякаєте. Знаю вашi мислi
Х&uовi — про аршин,
Яким не можна мiряти Росiю,
Бо ним ви &ъя мiряли у банi
Вiн правильную цифру не покаже

В поединке.

А если серьезно — делаете тест на тапнет девайсах/браузерах, если визуально торможение заметно — фиксить тем способом который устроит всех. Если нет — забить.

Код немного некрасивый — это даже не серьезно.

Судя по предыдущим вашим комментариям: dou.ua/...​rums/topic/26057/#2041068
опыта работы с React мало, т.е вместо того чтобы прочитать пару статей как правильно использовать Context API, лучше создать топик на DOU с жалобой на коллегу?

Есть 2 варианта: разбираетесь с инструментом который используете, второе ищите другую работу.

второе ищите другую работу.

дякую що не порадили прийняти отруту.

Сократ принял, и норм.
Чем вы хуже Сократа?

Сократ принял, и норм.

Кому норм, Cократу?

Ммм, нет.

Сократ загнулся от яда, а с ядом, вскрытием вен и горячей ванной был Сенека.

Раньше спорил, отстаивал свое решение до победного. Сейчас чаще соглашаюсь с оппонентами. Иногда у них получается делать по-своему, и выходит норм.
Иногда они набивают шишки и делают правильно потом. А я просто наблюдаю, потирая свои старые шрамы в тех же местах. Это тоже опыт.

влияет конечно.

вроде чем больше разговариваешь и влияешь на других, тем быстрее получишь надбавку от хозяина

вот же блин.
я то думал что п...деть — не мешки ворочать.
к тому же, вместо надбавки за инициативность можно получить и выговор за «токсичность», если доказывать каждому по мелочам, где тот неправ.

а если тихонько сидеть, то никогда главным не станешь

так я и не хочу.
мне всего хватает. и зарплаты, и обязанностей, и ответственности.

Руководствуюсь принципом «Choose your battles».
Если на возникший вопрос наиболее подходящим ответом является 42 «Всем пох*й» (а это наверное 9 случаев из 10), то нет смысла даже ввязываться в эти бесконечные дискуссии.
Если же вы видите серьезную проблему — пишите документ, собирайте митинг, берите задачу в спринт. Raise awareness, так сказать.

Насправді немає будь-якої проблеми погодитися з опонентом.
Але тільки за однієї умови — він повністю приймає відповідальність за свою пропозицію і всі потенційні проблеми буде виправляти сам.

Пізніше колега, пропонує переписати сторінку, бо вона виглядає трошки не красиво

Ответь ему, что у него рожа трошки некрасива, но ничего, ты же терпишь.

А если серьезно, просто обсудите нормально с аргументацией на колле, можете привлечь еще коллег, чтоб услышать и другие аргументы.

виглядає трошки не красиво

Виправив це речення, малось на увазі код сторінки. UI для енд юзера не змінився.
В мене ж на компі коли тайпаю текст проц більше не підскакує до 100%

Показать заказчику оба варината с пояснениями в чем проблема. Пускай выберет, или скажет оставить оба с переключателем «красота-скорость».
ЗЫ: Как на работе решаем — а у нас module ownership. Каждый делает у себя как хочет, в чужой код не лезет. Если плохо работает — можно поматюкать, чтобы исправил.

Залежить від кількості грошей в контори. Бо окрім:

Bus factor == 1

Ще маємо
Dev speed *= 5
та
Dev cost >>= 2

Якщо низька текучість кадрів і немає потогонки, то тоді норм, інакше небезпечно.

Ми 6 років проект робили — ніхто не пішов. Начальство далеко, контролю нема, пишіть як хочете — але щоб був результат.

Показать заказчику оба варината с пояснениями в чем проблема.

Хм. Это требует наличия у него технических скиллов, сопоставимых со скиллами спорящих.

Я думал, там «некасиво» в плане UX

Потрібна аргументація.

виглядає трошки не красиво

Це не аргументація. Невідповідність код стайлу, антипатерни, нечитаємий код без коментарів теж може бути аргументом, але «не красиво» ні.
Ви навели аргумент чому було так зроблено, нехай тепер ваш колега наведе на свою користь.

Як правильно це робити, щоби не зіпсувати відносини з колегами.

Ідеально мати процеси, які б таке вирішували. Процесами може бути, наприклад, код-рев"ю, де зміна обговорюється в коментарях до пул реквесту.
Також наявність визначеного код-стайлу дуже допомагає. Можна просто взяти звідси і не вигадувати велосипед google.github.io/styleguide/jsguide.html

Повністю згоден. Якщо хтось незадоволений, він пише коментар в pull request, далі нехай команда і замовник підключаються до code review.

Ну як...

Достаю из шкапчика дедовские латы, из кладовки прадедовскую шпагу и счастливую сорочку эпохи Токугава с толедскими оборками, вывожу из конюшни Росинанта, делаю справку об отсутствии ковида и отправляюсь в Бангладеш вызывать на бой обидчика, который вообще ветки попутал и комитит свою срань куда ни попадя. Там основательно и методично заміняю йому реакт контекс на проперті дріл и теми же огородами до утреннего стэндапчика возвращаюсь домой. Case closed.

Однажды забыл дома перчатки, пришлось бросать ему в лицо носки с покемончиками, очень переживал, что потеряются. Вся Дакка была в курсе, ой геволт.

Отже, таким чином щë ни с одним псом не зіпсував відносини, всë быстро решается, очень рекомендую, даже не нужно дëргать манагеров.

Залежить від багатьох чинників. Але є класика.

Пишеться простенький RFC з кількома обов’язковими пунктами:
— Суть проблеми
— Детальний опис запропонованого рішення
— Короткі описи альтернативних рішень (навіть якщо альтернатива — це нічого не міняти).
Можуть бути інші пункти в залежності від специфіки проекту.
Якщо використовуєте GitHub, то ідеальне місце для RFC — це в GitHub Issues. Далі відбувається обговорення в коментарях. Коли дійшли до якоїсь згоди, нехай навіть і неповної — відкривається черновий Pull Request з грубою реалізацією рішення для подальшого, більш детального обговорення. Або одразу кілька PRів, якщо є потреба в порівнянні конкуруючих рішень.
Коли дійшли повної згоди по якомусь рішенню, то PR доопрацьовується до належного стану і проходить класичне код ревью.

В результаті ви маєте документ, який повністю зафіксував хід прийняття рішення. Якщо це вимушений workaround або хак для якоїсь проблеми в закритому коді, то можна прямо в коментарі перед хаком лишити посилання на обговорення.

Якщо ніколи не писали RFC, то пошукайте в інтернеті RFC template і виділіть доречні вам пункти.

Абсолютно спокійно треба звернутись до техліда, якщо він у вас є. Якщо немає — змінюйте компанію, ви нічого не втратите. Також треба змінювати компанію, якщо техлід є, а толку від нього немає (таке теж бачив на власні очі).

Зазвичай техлід — це представник замовника, сидить десь за океаном і йому м’яко кажучи не сильно цікаво розбирати ваші суперечки.

Ви забули дописати фразу «у нас» на початку.

Це не техлід, це порожнє місце. Що робити коли техліда нема — там вище написано.
Тому що у будь-якому колективі розробників має бути людина, за якою останнє слово (скрам-сєктанти це можуть заперечувати, але так, як вони розповідають, воно ніколи не працює). Тому що з-за кожної дрібниці збирати мітинги і писати довгих листів ви швидко втомитесь. І це буде перемога лайнокодерів з досить передбачуваним результатом.

У кого лычка выше, тот и решает
P.S. приведённый в примере вопрос наверняка имеет подробный раздел в гайде по реакту, где простым языком описываются преимущества и недостатки того или иного подхода. Учитывая масштабы реакта и статьи можно найти

Підписатись на коментарі