Hello, World, друзі! Чи часто вам доводилось бачити, як колеги пишуть гівнокод? Чи задумувались ви про те, щоб сказати їм про це? Певен, що хоч раз у житті у вас таки була така ситуація.
То казати чи не казати – ось в чому питання…
Це дуже делікатне питання. Звичайно ж, казати потрібно, але тут важливо, як це робити. Навіть якщо критика справедлива, її можуть дуже жорстко сприйняти.
Прагнення ідеальності безглузде, як на мене. Ідеальний код сьогодні більшість програмістів завтра сприйме як гівнокод. Я дуже часто через місяць або два після написання коду можу сказати про свій же код, що він не ідеальний, а в деяких випадках навіть гірше. Є речі, які я писав кілька років тому і до нині пишаюсь ними, але все одно навіть у таких випадках можу сказати, що щось можна було зробити ще краще. Все це бачиш з часом.
Потрібно прагнути до хорошого коду, а до ідеалу прагнути практично нереально.Якщо ви бачите неефективний або поганий код, то спочатку потрібно зупинитись і подумати – чи дійсно він настільки погано пахне?
Я кілька разів натрапляв на ситуацію, коли під час code-review програмісти прискіплювались до таких речей як цикл проти linq. Так, linq є більш сучасним підходом, але чи реально він робить код кращим? Тут навіть дуже спірне питання.
Бувають випадки, коли цикл читається простіше, а у випадку простих речей linq чудово читається. Проте особисто я не бачу серйозних проблем при виборі того чи іншого. Тут більше має місце якийсь корпоративний або командний стандарт, котрий би визначав що краще обрати.
У будь яких стосунках дуже важливо зберігати ввічливість та взаємодопомогу.
Можна сказати, що це проблема програміста, якщо він не може нормально сприймати критику. Його робота писати хороший код, і, якщо він пише щось не так, то потрібно виправляти, а не мудрувати. В принципі, логіка тут є, але якась військова логіка, що дуже тхне дідовщиною.
Мені складно уявити людину, яка нормально відреагує на коментар типу – це гівнокод або цей код жахливий. Навіть якщо вона не подасть вигляду, не думаю, що їй буде приємно почути подібні репліки.
Мені складно говорити, як би зараз я реагував на подібне, але коли був молодим програмістом, мені було дуже не дуже приємно чути таку жорстку критику, хай навіть вона і була обумовлена моїми реальними “косяками”.
Коли мені доводиться переглядати чужий код і я бачу проблему, то я намагаюсь чітко вказати, що саме можна покращити. При цьому я не наполягаю, а пропоную. Наприклад, припустимо, що я бачу код, котрий буде виконуватись повільно. Можна написати коментарі типу:
- жахливий код;
- дуже повільно, потрібно переписати;
- що за лайно.
А можна написати більш коректний, на мій погляд, коментар:
- ця реалізація буде працювати, але якщо ти будеш використовувати тут Hash суму, то код можна зробити значно швидшим.
Автор коду написав робочу реалізацію. Так, вона не найоптимальніша, але якщо вона робоча, то чому не можна вказати на це? При чому вказати бажано на самому початку. Коли розмова починається з позитиву, то, зазвичай, в такому руслі він і продовжується.
У США, Канаді та ряді європейських країн прийнято спочатку хвалити. Хвалити, звичайно, особливо нема чого, якщо код працює настільки повільно, що потребує аби його переписати, проте я все ж вважаю, що потрібно відмітити, що він працює або ще щось позитивне. Мені не складно написати щось таке, а людині буде приємно.
Коли мова заходить про те, щоби сказати про гівнокод, то все залежить від підходу, тому що якщо людина пише щось невірно, то потрібно не критикувати, а допомагати зробити код кращим.
У випадку зі “смердючим” кодом, як і у випадку з багами – не повинно бути підходу в стилі покарання або осуду, коли вказують пальцем. Має бути допомога.
Якщо ви не можете коректно та ввічливо пояснити чому ваш підхід або рішення задачі краще, то воно таким не є.
Коректність та ввічливість створює тактовність у команді. Мені було б не дуже приємно працювати у команді з підходом, де потрібно працювати як робот, бо мені платять і я зобов’язаний тупо слідувати чомусь.
Правила роботи в команді повинні бути суворими, але не жорсткими. Якщо виникають спірні ситуації, то вони повинні вирішуватись максимально ввічливо.
Я вказую не на поганий код, я вказую як зробити хороший код це кращим і в такому випадку складно зачепити чиєсь самолюбство чи створити токсичність.
Під час прийому на роботу часто пишуть, що мастхев стресостійкість, вміння працювати під напрягами або тиском дедлайнів, проте це не означає, що ми самі тепер маємо створювати стресові ситуації в команді.
Ставтесь до людей так, як хочете, щоб ставились до вас. Саме про це я не думаю під час спілкування з іншими, просто треба бути ввічливим і поважати чужий труд.
