Это очень щекотливый вопрос. Конечно же говорить нужно, и тут больше вопрос в том, как это делать. Даже если критика по делу, ее могут воспринять очень жестко.
Стремление к идеалу бессмысленно на мой взгляд. Идеальный код сейчас большинство программистов воспримет как говнокод завтра. Я очень часто через год или два после написания могу сказать о своём же коде, что он не идеален или в некоторых случаях даже хуже. Есть вещи, которые я написал лет 10 назад и до сих пор горжусь ими, но все равно даже в таких случаях могу сказать о некоторых реализациях, что что-то можно было сделать ещё лучше. Всё это видно со временем.
Нужно стремиться к хорошему коду, а к идеалу стремиться практически нереально. Если вы видите неэффективный или плохой код, то сначала нужно остановиться и подумать – а действительно ли он на столько плохо пахнет?
Я несколько раз сталкивался с ситуацией, когда во время ревью кода программисты придирались к таким вещам, как цикл против LINQ. Ну да LINQ является более современным подходом, но на столько ли он реально делает код лучше? Вот тут очень даже спорный вопрос.
Бывают случаи, когда цикл читается проще, а в случае простых вещей LINQ отлично читается. Но лично я не вижу серьезных проблем в выборе того или другого. Тут больше должен быть какой-то корпоративный или командный стандарт, который бы определял – что лучше выбирать.
В любых отношениях очень важна вежливость и взаимопомощь.
Можно сказать, что это проблема программиста, если он не может воспринимать нормально критику. Его работа писать хороший код, и если он пишет что-то не так, то нужно исправлять и не умничать. В принципе здесь логика есть, но какая-то военная логика, очень сильно пахнет дедовщиной.
Возможно вы нормально отнесётесь к ней, если также с нежностью принимать точно такую же критику. Но мне сложно представить себе человека, который нормально отреагирует на комментарий типа – это говнокод, или этот код ужасный. Даже если он не подаст виду, не думаю, что ему будет приятно слышать подобное.
Мне сложно говорить, как бы прореагировал бы я на такое сейчас, но когда был молодым программистам мне было не очень приятно слышать жёсткую критику, даже обоснованную.
Когда мне приходиться смотреть чужой код и я вижу проблему, то я стараюсь четко указать, что именно можно улучшить и при этом предлагаю, а не настаиваю. Например, допустим, что я вижу код, который будет выполняться медленно. Можно написать комментарии типа:
- ужасный код
- очень медленно, нужно бы переписать
- что за фигня
А можно написать более корректный на мой взгляд комментарий:
- эта реализация будет работать, но если ты будешь использовать здесь Hash сумму, то можно сделать его на много быстрее
Автор кода написал рабочую реализацию. Да, она не самая оптимальная, но если она рабочая, почему бы не указать это? Причём указать это желательно в самом начале. Когда разговор начинается с чего-то положительного, то он обычно и продолжается также.
В США и Канаде принято сначала похвалить. Хвалить тут конечно же тут особо нечего, если код на столько медленный, что требует переписывания, но я все же считаю, что можно отметить, что он рабочий или что-то положительное. Мне не сложно написать что-то такое, а человеку будет приятно.
Когда идёт вопрос о том, чтобы сказать о говнокоде, то все зависит от подхода, потому что если человек пишет что-то неверно, то нужно не критиковать этот код, а помогать сделал его лучше.
В случае с не очень хорошо пахнущим кодом, как и в случае с багами – не должно быть подхода в стиле наказания или порицания, когда указывают пальцем. Должна быть помощь.
Если вы не можете корректно и вежливо объяснить почему ваш подход или решение задачи лучше, то оно таким не является.
Грубость создаёт тактичность в команде. Мне не очень приятно было бы работать в команде с подходом, где нужно работать как робот, потому что мне заплатили, и я должен тупо следовать чему-то. Я сам с подобным не сталкивался, но слышал о разных вещах.
Правила работы в команде должны быть строгими, но не жесткими. Если возникают какие-то спорные ситуации, то они должны разрешаться максимально вежливо.
Я указываю не на плохой код, а указываю как хороший код сделать ещё лучше и в таком случае сложно затронуть чье-то самолюбие или создать токсичность.
При приеме на работу часто пишут, что должны быть стрессоустойчивость, нужно уметь работать под какими-нибудь напрягами или давлением дедлайнов, но это же не значит, что мы сами теперь должны создавать стрессовую ситуацию в команде.
Относитесь к людям так, как хотите чтобы относились к вам. Именно об этом я не думаю во время общения с другими, просто нужно быть вежливым и уважать чужой труд.
Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание
Паника, что-то случилось!!! Ничего не найдено в комментариях. Срочно нужно что-то добавить, чтобы это место не оставалось пустым.
Добавить Комментарий