Что делать если команда говнокодит?

Что делать если команда пишет говнокод, и я никак не могу на это повлиять? Мирится с этим какое-то время и надеться что все образумится, или не морочить голову и попытаться найти другое место работы? Скажу что я не гуру-тимлид, но я вижу когда люди пишут сравнение == или умудряются создать в объекте 4 одинаковых метода с разными названиями, тут явно что-то не так.
Если у кого-то есть подобный опыт подскажите, что делать.

UPD:
Спасибо коллеги, что откликнулись и приняли бурное обсуждения вопроса. Обсудил данных вопрос с командой по указанным на мой взгляд допущениям и не только. Теперь хочу собственно рассказать позицию команды (в частности тимлида) по этим вопросам.

Как оказалось все написано не просто так и по мнению тимлида не говно код.
Сравнение с помощью знака ==, которое так бурно обсуждалось быть и ли нет, оказалось вполне нормальным явлением, по-мнению тимлида конечно. Объяснение данного финта в том, что данных с бэкенда приходят только в виде null или нужных данных, и это для него нормальная ситуация. Кстати говоря не могу быть уверен, что таким способом проверяются только данные пришедшие с бэка. В этом вопросе наши мнения естественно расходятся.

На счет 4 одинаковых методов, как оказалось они не одинаковые. Может быть они и делают одно и тоже внутри, но используются для разных целей.

Так же писали на счет линтинга и кодревью. Про линтинг мне сказали четко: Eslint вводить не будем. Как мне сказали команда и так умеет писать код и точки с запятой расставлять. Дали инструкцию на как настроить отступ в редакторе на 4 пробела, чтобы как у всех было. Вообщем-то я почему-то даже спорить тут не стал. Видимо ответ был дан четко и понятно. На кодревью сейчас времени нету. Может быть будет потом, но сейчас пилить надо.
анекдот на тему
Мужик тупой пилой пилит дерево пилит. Его спрашивают: Мужик чего пилу не наточишь? Мне некогда, пилить надо!


Вообщем-то там было много ещё чего интересного в разговоре. Мое субъективное мнение такое, что люди как будто в первый раз собрались проект писать новый. Я понимаю что нужно всегда что-то быстро сделать и кому-то показать или запустить. Но мне кажется что некоторые банальные вещи можно и сразу делать хорошо без потери времени. Если никто это сейчас не делает, где гарантия что это потом сделают, а не бросят и всё? Для себя я выводы сделал.

Спасибо ещё раз всем кто участвовал в обсуждении. Надеюсь все ответы и коментарии помогу кому-то ещё.
  • Вопрос задан
  • 11185 просмотров
Решения вопроса 9
Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

Прямо уж откровенной копипасты и лапши у нас вроде бы нет почти. Мы стараемся избегать её, придумывать декларативные абстракции во всех случаях, где много тупого императивного кода, писать в функциональном стиле. Я думаю, что необходимы постоянные целенаправленные усилия в этом направлении, чтоб не допускать засилья энтропии.

Ещё пара идей.
  • можно отправить разработчиков на какой-нибудь онлайн-курс по чистому коду, хотя я таких даже не знаю, но наверняка должны быть
  • или устраивать "хакатоны чистого кода", на коих команда разбивается на пары-тройки, каждая из коих пишет какую-нибудь маленькую, но полезную, а главное чистую и оттестированную штуковину, причём тема - по собственному выбору. Потраченное время - оплачиваемое, разумеется. Это уже зависит от руководства фирмы, согласится ли оно на такие развлечения.


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

Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

Я, конечно, сам не волшебник, я только учусь, и работа с командой - такая штука, которой надо постоянно учиться. Видимо, вы тоже учитесь; успехов в этом.
Ответ написан
saintbyte
@saintbyte
Django developer
Постареть и понять пока хипстеры дрочат на говнокод , старые задроты выкатывают прототип и получают финанирование.
Ответ написан
alexraven
@alexraven
веб-разработчик, специализация - wordpress
Сменить команду. Потому что во всех косяках команды всегда виноват тимлид.
Ответ написан
Комментировать
teke_teke
@teke_teke
programador
тоже говнкодить.
увидел говнокод, скажи себе "а ты....... ну я тебе сейчас покажу.....". и - бегом говнокодить, пока злость еще не прошла.

но, не более 3х раз за день. а иначе привыкнешь и не сможешь отличать код от говнокода.
Ответ написан
Комментировать
@immaculate
Программист-путешественник
Это сложный вопрос, на который нет однозначного ответа. Лично я для себя нашел следующие выходы: не связываться вообще с языками, в которых очень низкий порог входа (Javascript, PHP). Пытаться спорить и воспитывать коллег (это тяжело и дает плоды только на очень длинной дистанции). Менять работу.

Те, кто говорят, что только хипстеров заботит красота кода: я еще не видел успешного проекта с говнокодом. Множество раз меня звали на проекты, я отказывался после первого взгляда на код, и больше я никогда об этих проектах не слышал. Когда люди пишут четыре одинаковых метода под разными именами, когда используют разработку копи-пастой, однобуквенные имена переменных, и т.п., они в итоге сами увязают в своем говнокоде, и проект не взлетает. Остается за ним дурно-пахнущее нечто, что никто не берется поддерживать и развивать, в итоге, проект тихонько загибается.

Единственное исключение: один раз видел код одной довольно популярной соц. сети. Он был реально ужасен, но эта сеть до сих пор существует и довольно популярна, хотя и вытесняется потихоньку общепризнанными лидерами типа facebook. Как у них все не рушится, не понимаю, но код был такой, что просто волосы дыбом встали, когда увидел. Впрочем, это исключение, которое подтверждает правило.
Ответ написан
search
@search
мама говорит что я особенный
Ой как я вас понимаю. Сам страдал от подобного долгие годы (9 лет, если быть точным). К сожалению, мгновенного решения для вашей проблемы не существует. А смена работы - всего-лишь временная отдушина. В моём случае технический скилл был (и надеюсь остаётся) выше среднего, а лидерский (так называемый софт-скилл) - на нуле. Умение договариваться с людьми, адекватно реагировать на нужды коллег, продукта и бизнеса - оказались очень полезными навыками. К сожалению этот скилл не прокачаешь за выходные. Вот примерный список того что можно делать для прокачки лидерских качеств:
- читать книги (в т. ч. художественную литературу)
- участвовать в опен-соурс проектах
- делиться опытом (выступать на митапах, выступать в кругу коллектива)
- прокачивать т.н. "эмоциональный интеллект"

В своём случае я почувствовал ощутимые улучшения примерно через год целенаправленной работы над собой.

Как показывает жизненный опыт, на одних-лишь технических навыках в рай не уедешь. Чтобы быть красавчиком нужно уметь решать конфликтные ситуации.
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Здесь стоит посмотреть с 2х строн:
1. Если вы часть команды и мелкая сошка -- смирится, либо идти по головам к начальству с наглядными примерами, и объяснением того в долгосрочной перспективе ваш подход принесет больше прибыли (меньше убытков). Если начальник адекватный, он задумается и поставит вас тимлидом, если нет -- то это его проблемы, вы свою точку зрения донесли.

2. Если вы лицо принимающее решение в команде, и являетесь тимлидом --- тогда руководить и вводить метрики, ревью кода, и т.п. штуки, чтобы когда кто-то косячил, другие говорили ему "Вася ты дурак".
Ответ написан
Комментировать
@ArcadyZherdev
Проблема не техническая, а организационная и соответственно решить технически её полностью нельзя. Никакие хуки на гит репо и continuous integration не защитят на 100%. Если есть желающие нагадить в коде они умудрятся это сделать.
Решается организационно, либо ктото за ними подтирает и ему за это платят ..либо ктото заставляет их исправлять (про code review выше писали) ..воспитывать/обучать "серунов" (если работает) ..либо увольнять.
Ответ написан
Комментировать
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
1. Если Вы можете понять код, просто объясните им проблему, укажите на ошибки и научите: это проще и дешевле, чем искать новых и "притираться" долгое время.
2. Пусть пишут текстом: для чего создан каждый объект и каждый из его методов.
3. Если не поможет - пусть изначально рисуют блок-схему.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 7
kellas
@kellas
веб-разработчик
Нужно выделять время на рефакторинг: https://refactoring.guru/ru всем программистам с которыми был знаком нравилось рефакторить код. Что касается "кое что можно сразу писать нормально" - нет, нельзя, этому ещё нужно научиться, а чтобы этому научиться нужно сначала написать говнокод, а потом его отрефакторить и может в будущем писать немного меньше говнокода.
Ответ написан
Комментировать
@Voltera
Очередная грустная история убегателя от проблем.
"Всегда же будет идеальное место для меня", - нет не будет.
Если вы видите в себе светоч чистого кода, то поделитесь с коллегами, возможно ваше представление о жизни изменится, похоже на историю о лучшем проекте пока он у вас в голове.
Ответ написан
Комментировать
@Olezaika
Что делать если команда говнокодит?


Поменять тимлида? Не ну а зачем нужен тимлид, который про linter'ы не знает?
Ответ написан
Комментировать
dmitry_pavlov
@dmitry_pavlov
World-class .NET freelance contractor (remotely)
Просто внесите свою лепту :)

Ну а кроме шуток по этому поводу я высказывался: "Постигайте кунгфу рефакторинга legacy кода - многопроходного бережного улучшения архитектуры приложения, без перебоев в работе приложения и в параллели с разработкой новой функциональности... (С) Я 2017" Полностью тут: Как аргументировать начальству создание существующего проекта заново, с ноля?
Ответ написан
Комментировать
@Edymov
Я бы не стал работать в такой конторе. Работая с говноделами, сам постепенно скатишься на их уровень. Чаще всего они даже не понимают, в чём проблема.
Ответ написан
Комментировать
webinar
@webinar
Учим yii: https://youtu.be/-WRMlGHLgRg
Задайте себе вопрос: "Если я перейду на другую компанию, там будет лучше?" Если ответ положительный, переходите, если нет решайте вопросы в своем коллективе. Думаю штрафы за говнокод и премии за неделю без говнокода, могут решить проблему. Для тех кто на бронепоезде, всегда есть заявление об уходе.
Ответ написан
@sisn
К руководству обращайтесь.

Оно вам расскажет
Возможно что просто политика руководства - как можно дешевле нанимать.

А еще лучше расскажите руководству, что существуют программы для автоматической проверки стилистики и автоматического поиска ошибок (всевозможные линтеры и коде-стайл-чекеры).

У нас, в частности, они настроены на автоматический запуск при каждом коммите.

И разработчику сразу видные его косяки.
Пока через линтеры-автоматы коммит не пройдет - его код не отправляется на рассмотрение на внедрение в production

Если вам текущая команда нужна для обучения и повышения вашей квалификации - бегите оттуда.

Само по себе не изменится.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
04 дек. 2021, в 19:54
80000 руб./за проект
04 дек. 2021, в 19:30
50000 руб./за проект
04 дек. 2021, в 19:20
3000 руб./за проект