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

Question

[Егор]

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

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

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

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

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

анекдот на тему

Мужик тупой пилой пилит дерево пилит. Его спрашивают: Мужик чего пилу не наточишь? Мне некогда, пилить надо!

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

Спасибо ещё раз всем кто участвовал в обсуждении. Надеюсь все ответы и коментарии помогу кому-то ещё.

Comments

[McMike]

А что не так со сравнением?

[Егор]

McMike: А что с ним так? Мы если что про JS говорим

[alvvi]

Егор: ну вы так написали, будто само использование == - антипаттерн. Это не так.

[Егор]

Илья Ростопка: Если нету какой-то железобетонной причины использовать ==, то лучше не использовать. В том числе везде подряд его вставлять.

[McMike]

Егор: ну поясните мне, почему не надо использовать '==' для сравнения? И что тогда использовать?
В JS '==' - это оператор сравнения, в чем коллизия?

[Егор]

McMike: Поведение == не очевидно, в отличии от ===. Этот оператор одно время хотели выпились из языка сам создатель языка, но не сложилось.

[Arris]

ногами бить пробовали?

[alvvi]

MaxKorz: конечно, во всей настабильности кода виноват ==! Ох уж этот проклятый ==
Интересно, а вы понимаете почему эти таблицы вообще различаются?

[McMike]

MaxKorz: спасибо. У меня проблемы с фронтендом, так что плаваю в таких вопросах.

[alvvi]

MaxKorz: прекрасный ответ. Очень предсказуемый, на самом деле. (pun intended)
Если вам все же захочется разобраться, что же на самом деле происходит при var1 == var2, а не просто винить оператор за его существование или создателей языка/спецфикацию за то, что они сделали что-то менее понятно и не очевидно с первого взгляда, что-то что требует небольших, но все же усилий для полного понимания, то советую почитать книгу Кайла You Don't Know JS или посмотреть его же курс https://frontendmasters.com/live-event/advanced-js... где все подробно объясняется с точки зрения того, как это происходит на уровне нативного кода.

В упомянутой вами же спецификации оно, кстати, тоже подробно описано, но вы ведь вряд ли читали эти разделы, не так ли? Легче ведь открыть исходники jQuery и сказать "Хэй, смотрите, умные дяди используют ===, а я что, не умный что ли? Раз они так делают, значит и я буду!"

[alvvi]

MaxKorz: если бы вы знали, как работает ==, вы бы никогда не написали такой код. (:

[alvvi]

MaxKorz: нет, конечно не считаю, Но вот что я действительно считаю, так это то, что повторять бездумно за "умными дядями" - глупо, и любой программист, хоть с 20-летним опытом должен воздерживаться от этого, и тем более не учить новых программистов мыслить подобным образом.

Вы не согласны, что использовать == лучше ===?

Нет, я вообще не люблю абсолютные утверждения, хоть иногда они необходимы в программировании. Это не тот случай.

[Егор]

Илья Ростопка: Зачем стрелять себе в ногу преждевременно, если можно подстраховаться и не стрелять? Да я знаю отличия == от === но серьезно? Использовать только == только потому что я считаю себя ниндзя мастером в js? Нужно проект пожелеть и людей которые будут с ним работать. Мол в этом месте я использовал == потому что знаю спецификации а вы холопы нет? И не важно что вдруг в будущем кто-то будет ловить целую ночь баг связанный с ==

[alvvi]

Егор: в том то и дело, что нужно это знание не делать элитарным, и сразу новичкам объяснять, что такое неявное приведение типов и как оно происходит при ==.

[alvvi]

MaxKorz: я не понимаю, в чем смысл перехода на личности, это никак не делает вас более правым в споре.

[Алексей Николаев]

MaxKorz: угу, зато задачки на приведение типов и приоритет операторов бывают на каждом собеседовании. К чему они, если это считается антипаттерном? Зачем мне тогда решать "сколько будет a+++b", если я могу в скобки явно все вынести? Это особенности языка, и разработчик должен ее знать, чтобы эффективно использовать нестрогое сравнение и неявное преобразование типов. Если кто-то слишком умен, чтобы засорять свою голову этими знаниями, и неспособен эвристически определить (даже руководствуясь приведенными вами таблицами) в какой тип сконвертируются переменные при сравнении, то это явно не проблема разработчика, использовавшего ==.

[Толстый Лорри]

Алексей Николаев:

задачки на приведение типов и приоритет операторов бывают на каждом собеседовании. К чему они, если это считается антипаттерном? Зачем мне тогда решать "сколько будет a+++b", если я могу в скобки явно все вынести?

Кандидат должен знать, что здесь есть грабли. Умный интервьюер ждет, что кандидат возмутится и скажет, что за такое расстреливать нужно.

[alvvi]

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

Абсолютно любой ответ можно так прокомментировать - вас никакой бы ответ не устроил.

Ответ "потому что == позволяет неявное приведение типов, а === - нет" меня бы вполне устроил. Вы не согласны с тем, что этот ответ более четко объясняет, почему те таблицы отличаются, чем "потому что спецификация"?

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

А почему бы мне ей не прикрываться, если в ней все отлично объяснено? Почему бы мне не ссылаться на ресурс, в котором автор как раз и оспаривает то, что пишете вы?

Я не спорю, что если ты супер профи в JS, то можно использовать "==" и не париться. Но зачем? Что это дает кроме повышения ЧСВ?

Повышение редабилити кода в определнные моменты, менее многословный код - плохая причина?
Возьмем ваш же пример с операциями над числами и строками. Что если мы хотим выполнить какой-то код в случае если аргумент строка, приводимая к 1 ИЛИ число 1? Как вы напишите такой код? Наверное, как-то так:

function f(x) {
  if(x === 1 || x === '1') {
    // do smth with x
  }
}

Классно, работает, но почему вот здесь и не воспользоваться тем самым приведеинем типов?

function f(x) {
  if(x == 1) {
    // do smth with x
  }
}

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

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

, которые, как мне кажется, не являются рациональными и противоречат банальным фактам, которые вы сами приводите в следующем же абзаце

56 нестрогих проверок

Строжайше запрещенно, но в 10% случаев все равно используем?

Но вы, конечно, можете в ответ опять сделать меня тимлидом команды говнокодеров и назвать жирным троллем. Я не обижусь, просто не понимаю этого, честно.

[devalone]

Ох уж эти джаваскриптеры, сами придумали эту ужасную систему типов и сами от этого теперь страдают..

[pashted]

Вы явно не встречали людей, которые весь html выводят через echo, да еще с кучей экранированных двойных кавычек. Или делают поиск объекта в DOM 10 раз за один document.ready. Еще они делают круглые глаза , когда слышат слово breakpoint. После такого любой остальной говнокод кажется ерундой. Возможно, вам стоит посмотреть на "дно" и понять, что не все так плохо)

[Dark Hole]

maximus2223: Илья Ростопка: MaxKorz: ребят, ну зачем разводить холивары, что лучше == или ===.
К MaxKorz можно придраться тем, что в рантайме у нас должна быть типизация. Если мы условились, что переменная A должна быть строкой в этом отрезке кода, то она должна быть строкой(для чего и сделали TypeScript, maximus2223, а вовсе не для строгого сравнения) . В таком случае, === помогает отсеивать некорректные реализации. Иначе будет плохо как и с ==, так и с ===.
Справедливости ради, стоит отметить, что === все таки помогает это поддерживать, при правильной реализации, Илья Ростопка.
Но, однозначно, само использование == говнокодом, как видимо не считает автор, вовсе не является.

[xtalen]

== - лакмусовая бумажка говнокода - это конечно через чур)))
maximus2223 TypeScript не решает данной проблемы, т.к. он защищает тебя только на уровне компиляции, а в ходе выполнения программы переменная может содержать что угодно.

// ts
function f(x: number) {
  if(x === 1) {
    // do smth with x
  }
}
// скомпилируется в
function f(x) { if(x === 1) { } }

// т.е. ничего не поменялось

На мой взгляд описанные проблемы автора топика не являются критичными и решаются внедрением code review.

[lega]

вы считаете себя умней дядь, которые пишут библиотеки и фреймворки и работают над движками браузеров?

Не надо переоценивать разработчиков фреймворков, у них говнокода тоже вполне себе бывает. Например в том же Ангуляре долгое время выражения наподобии: false == "false" давали true, про архитектуру можно долго разговаривать, к счастью её покрошили в новой версии, в которой кстати тоже не все гладко, метеор разрабатывался нанятыми студентами, т.к. это бизнес в первую очередь по осваиванию денег. и т.д.

[Леонид Крашенко]

Мне как-то удалось добиться значительных улучшений:
1) хуками на гит (не дает коммитить, если код не соответствует pep8 (с некоторыми оговорками)),
2) разнесением ответственности: смысловой говнокод можно написать на и pep8 - пожалуйтса, но делайте это в своих модулях (которые вы потом будете поддерживать, а не я).
3) в маленьком модуле наговнокодить можно, но это не страшно обычно - в небольшом проще разобраться.
Это - в общем - работает; иногда возникает проблема, когда кто-то уходит, и приходится разбираться в том, что он там наделал.

P.S. наезжать на кого-то со словами "ты гонокодишь, переделай" - не стоит, т.к. плохая атмосфера в коллективе породит худшие, на мой взгляд, проблемы.

[lega]

P.S. наезжать на кого-то со словами "ты гонокодишь, переделай"

А ещё, если ты думаешь что "Вася" говнокодит, вполне возможно он думает о тебе так же.

[Сергей]

> 3) в маленьком модуле наговнокодить можно, но это не страшно обычно - в небольшом проще разобраться.
Это - в общем - работает; иногда возникает проблема, когда кто-то уходит, и приходится разбираться в том, что он там наделал.

это самая главная проблема коллективов, код должен быть отделен от разработчика.
Нет разницы, говно в большом или малом модуле. Если говно в интерфейсах взаимодействия, то говно и внутри будет. Так что если говно в АПИ, то это гораздо хуже.

[Виолетта Морозова]

Следуя из UPD, я бы поступила как 1 1
Вас не устраивает подход вашей компании, беседы ни к чему не привели, соответственно вам не комфортно с ними работать. Можете мириться - миритесь, но не поддавайтесь)) не можете мириться - страна у нас большая компаний много ;)

Answer 1

[Anatoly Scherbakov]

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

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

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

Ещё пара идей.

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

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

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

Я, конечно, сам не волшебник, я только учусь, и работа с командой - такая штука, которой надо постоянно учиться. Видимо, вы тоже учитесь; успехов в этом.

Comments

[Stalker_RED]

Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление

Следует ли из этой фразы, что если коммит содержит менее чем N ошибок в расчёте на единицу объёма кода, но не ноль, то исправлять не нужно?
Это не описка, у вас действительно есть какой-то допустимый процент ошибок?

[Anatoly Scherbakov]

Stalker_RED: у нас на самом деле ничего нет. :) Как я сказал, мы только собираемся вводить CI. Теперь по сути. pylint/pyflakes любят и умеют тоннами давать false positives, и поэтому запрещать коммит при наличии любых предупреждений с их стороны будет неразумно.

Python - язык очень динамический. В коде создаётся объект класса A, и линтер ожидает его там увидеть; но внутри - сюрприз - особо ушлый метакласс, который подменяет результат объектом класса B. И тут же вызываются у него всякие методы. Работает-то оно отлично, но линтеру этого не постичь и он будет вопить, что методы - неправильные и мёд тоже. Такие штуки широко используются во внутренностях Django, да и во многих других сколь-нибудь сложных библиотеках.

Я думаю, что мы подберём порог N экспериментально.

Answer 2

[Егор Казанцев]

Постареть и понять пока хипстеры дрочат на говнокод , старые задроты выкатывают прототип и получают финанирование.

Comments

[Lander]

Говнокод со временем увеличивает стоимость внесения изменений. В живом проекте (который уже работает и приносит прибыль), обязательно нужно избегать говнокода и выделять время на рефакторинг существующего! В данном случае "Лучше день потерять, потом за час долететь".

[kn0ckn0ck]

Lander: Говнокод говнокоду рознь :)

[Егор Казанцев]

Lander: Любитель коротких итераций

[Евгений]

Не раз видел говнокод, который приходилось переписывать все равно. Потому что проект растет, и по производительности говнокод не устраивает, правки тоже очень тяжело делать. А рефакторингу понемногу он может не поддаваться. Говнокод - это часто такая гигантская какашка, в которой все говноклассы и говнофункции (типично, размерами в сотни и тысячи строк) очень тесно связаны. Тронешь в одном месте, отваливается кусок в другом.

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

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

Не раз видел, как такие люди уходят, потому что сами не могут поддерживать свой код. Приходят на одну работу, несколько месяцев пишут говнокод, его становится все тяжелее поддерживать, и они сваливают на новое место начинать сначала, а поддерживать за ними приходится другим. Так они и какают в проекты прыжками по 3-6 месяцев. Накакал в один, получил зарплату, перепрыгнул в другой. Что там дальше с ними происходит, не знаю.

[Lander]

Егор Казанцев Нет, лучше пилить 2 года, чтобы понять что это нафиг никому не нужно. Хотя, если смотреть на это только с точки зрения программистов: А чё, 2 года попа в тепле! :)

[Егор Казанцев]

Когда вы уже забьете на поиск серебряной пули... Надо выпускать в продакшен а не шлифовать код.

[Евгений]

Хорошо писать — не значит писать два года и не значит без конца шлифовать код. Хорошо писать — это значит не использовать костыли, рефакторить по ходу дела, если видишь, что что-то сделано плохо.

Если проект пишется два года — это тоже говнокод. Потому что столкновения с реальностью такой проект не выдержит. Все эти хрустальные дворцы из два года обдумываемых паттернов и иерархия классов глубиной в 25 уровней вложенности, не выдержит, когда выяснится, что пользователям нужно что-то другое, и вся эта иерархия классов с нагромождением паттернов не решает их задачу.

Хорошо писать код, это, например, прежде чем написать код, изучить документацию по языку и используемым фреймворкам и библиотекам, а не копи-пастить куски из документации и примеров на StackOverflow. Хорошо писать код — это читать код open source приложений (с хорошим кодом) и учиться на примерах. Хорошо писать код — это думать, когда пишешь, задумываться: что делает эта строчка, что делает этот класс, что делает этот вызов функции.

[evnuh]

Если вы что-то пишете с нуля, то всё равно перепишите это через год-два, вне зависимости от того был ли это говнокод, либо хорошо продуманная архитектура. Сменится направление движения, может сменится команда или внезапно понадобятся другие технологии. В общем, говнокодить для быстрого запуска - вполне ок.

[Samarkand]

Егор Казанцев: Надеюсь, это была ирония?

[Егор Казанцев]

Samarkand: нет иронии нет , надо решать проблемы здесь и сейчас а не дрочить на качество кода. Вы представляете сколько бы делался вконтакте если бы они решили что надо допустим использовать С++ ибо будет хорошо работать при 5М юзеров.

[sompylasar]

Не нужно забывать, что крупные и долгоживущие проекты переписываются регулярно (не с ног до головы, естественно, но энтропию стараются уменьшать). Об этом пишет Google, это известно о Facebook, это можно наблюдать по коду ВКонтакте, и т. д. На коленке слепленный с нуля прототип будет работать до тех пор, пока не потребует внесения в него изменений. Вносить изменения в существующий и работающий продукт – это не то же самое, что слепить с нуля прототип.

Answer 3

[alex maslakoff]

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

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

Answer 4

[Евгений]

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

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

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

Comments

[Boris Köln]

1с-битрикс и других их поделки?

[Евгений]

Boris Korobkov Нет, я не хочу называть имя. Это реальная социальная сеть, довольно популярная в узких кругах, с миллионами пользователей. Это у меня и вызвало удивление, как они с таким кодом умудряются все это поддерживать. Правда функциональность сети довольно простая, но все же.

Это было около 5-6 лет назад, они взяли меня на работу, в первый рабочий день я открыл исходники, просидел над ними до вечера, и сказал, что очень сильно прошу прощения, но с этим я работать не буду. Они предложили рефакторинг, но я все равно испугался. Может быть, это было неправильное решение, но я видел:
1) Сотни тысяч строк говнокода, рефакторинг которых занял бы годы, и скорее всего, все заглохло бы, так как людей нанимают, чтобы исправлять ошибки и разрабатывать новые фичи, а не годами код переписывать
2) Я новый человек, только что пришел в команду из нескольких разработчиков, которые годами писали этот говнокод. Скорее всего, они его говнокодом не считают. А вот я для них никакого авторитета не представляю. Помимо работы с говнокодом пришлось бы преодолевать сопротивление команды, зарабатывать у них авторитет.

В тот момент я почувствовал, что это слишком сложно для меня.

А сеть до сих пор существует.

[Егор]

Евгений: Почему-то кажется что вы про vk говорите. Но я хз, это просто догадки.

[Евгений]

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

[Егор]

Евгений: Ну во фронте у них по-моему раньше спицифические решения были.

[Stalker_RED]

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

[sisn]

Я тя умоляю - даже в Go с его полуавтоматическими коде-стайлами и кучей линтеров на все случаи жизни - умудряются говнокодить.
Порог вхождения программистов - не при чем.
Разве что порог вхождения в задачу того или иного уровня имеет смысл.
То есть на серьезных задачах говнокодеров меньше.

[Антон]

Евгений: Я кажется знаю, что это за соцсеть :)
Это служба знакомств, так? :) Если да, то я месяц назад пришёл и через неделю ушёл оттуда просто вот слово в слово по описанной вами причине)

[Евгений]

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

Я потом ради интереса глянул резюме одного из участников. Выпускник МГУ, сертификаты о прохождении серьезных курсов на Курсере, ИИ, все дела. Но блин, то, что он написал:
а) не работает вообще
б) адский треш нарушающий все законы здравого смысла

[sisn]

Евгений:
99% выпускников по специальности "программист" всего лишь "заготовка программиста".
Это нормально.

Строго говоря, так во всех профессиях

[Евгений]

Ну, он пишет в резюме, что не совсем свежий выпускник, якобы он уже несколько лет занимается разработкой, даже портфолио разработанных сайтов есть. Что поставило меня в тупик, т.к. я явно вижу в коде отсутствие способности сделать даже простейший сайт и вообще отсутствие здравого смысла у человека. Например, в проекте на Django, он начал свою часть реализовывать с использованием шаблонов Jinja. Потому что ему так удобнее, как он объяснил менеджеру. В итоге, и так неработающий проект получил еще две разных системы шаблонов и без пол-литры не понять где какой язык шаблонов используется.

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

Руководство меня не поняло (не технические люди), и мы расстались в самом начале, не на самых дружественных нотах. Вообще, это долгая история, просто вспомнилось, так как меня в тупик ставят такие люди и такие проекты - откуда они берутся вообще.

[f0rk]

я еще не видел успешного проекта с говнокодом.

А я не видел ни одного успешного НЕ с говнокодом :)

[Егор Казанцев]

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

Answer 5

[Demian Smith]

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

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

Как показывает жизненный опыт, на одних-лишь технических навыках в рай не уедешь. Чтобы быть красавчиком нужно уметь решать конфликтные ситуации.

Comments

[Коал Коалыч]

красавчик =)

[Егор]

Спасибо, интересные пункты. Приму к сведению.

Answer 6

[Сергей]

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

2. Если вы лицо принимающее решение в команде, и являетесь тимлидом --- тогда руководить и вводить метрики, ревью кода, и т.п. штуки, чтобы когда кто-то косячил, другие говорили ему "Вася ты дурак".

Answer 7

[ArcadyZherdev]

Проблема не техническая, а организационная и соответственно решить технически её полностью нельзя. Никакие хуки на гит репо и continuous integration не защитят на 100%. Если есть желающие нагадить в коде они умудрятся это сделать.
Решается организационно, либо ктото за ними подтирает и ему за это платят ..либо ктото заставляет их исправлять (про code review выше писали) ..воспитывать/обучать "серунов" (если работает) ..либо увольнять.

Answer 8

[xmoonlight]

1. Если Вы можете понять код, просто объясните им проблему, укажите на ошибки и научите: это проще и дешевле, чем искать новых и "притираться" долгое время.
2. Пусть пишут текстом: для чего создан каждый объект и каждый из его методов.
3. Если не поможет - пусть изначально рисуют блок-схему.

Answer 9

[Alex Step]

Нужно выделять время на рефакторинг: https://refactoring.guru/ru всем программистам с которыми был знаком нравилось рефакторить код. Что касается "кое что можно сразу писать нормально" - нет, нельзя, этому ещё нужно научиться, а чтобы этому научиться нужно сначала написать говнокод, а потом его отрефакторить и может в будущем писать немного меньше говнокода.

Answer 10

[Voltera]

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

Answer 11

[Olezaika]

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

Поменять тимлида? Не ну а зачем нужен тимлид, который про linter'ы не знает?

Answer 12

[Dmitry Pavlov]

Просто внесите свою лепту :)

Ну а кроме шуток по этому поводу я высказывался: "Постигайте кунгфу рефакторинга legacy кода - многопроходного бережного улучшения архитектуры приложения, без перебоев в работе приложения и в параллели с разработкой новой функциональности... (С) Я 2017" Полностью тут: Как аргументировать начальству создание существующего проекта заново, с ноля?

Answer 13

[Edymov]

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

Answer 14

[Максим Тимофеев]

Задайте себе вопрос: "Если я перейду на другую компанию, там будет лучше?" Если ответ положительный, переходите, если нет решайте вопросы в своем коллективе. Думаю штрафы за говнокод и премии за неделю без говнокода, могут решить проблему. Для тех кто на бронепоезде, всегда есть заявление об уходе.

Comments

[AlikDex]

что делать, если ты ничего не решаешь будучи простым трудягой в коллективе, но не желающий терпеть это дерьмо? =)

[Максим Тимофеев]

AlikDex: Нарисуй плакат, ходи по офису ))) Я бы просто сходил к директору, пояснил и стал тимлидом.

Answer 15

[sisn]

К руководству обращайтесь.

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

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

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

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

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

Само по себе не изменится.

Comments

[Максим Павлов]

Но говнокод - это не только плохое форматирование и ошибки. Это еще и "лапша", отсутствие архитектуры и т.д.

[sisn]

Максим Павлов:
Все это - проблема руководства.

[sisn]

Максим Павлов:
Ваше дело как исполнителя работать с тем, что дают.
Или предлагать свои варианты.

Вполне возможно, что ваши интересы расходятся с интересами бизнеса - если переделка архитектуры означает на ново проект с нуля переделать и нанять новых квалифицированных исполнителей дороже - то это может противоречить бизнесу.

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

[sisn]

Максим Павлов:
говнокод существует просто потому что он кому-то нужен.

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