собачники против кинофобов

[WMix]

Вурдалак, по живому же режешь, особенно про именование переменных.

 

[Вурдалак]

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

Интересно как это происходит: у вас отсутствует code review как обязательный этап? Ну, то есть чувак написал транслитом. Ты возвращаешь ему — он не в состоянии исправить или в следующий раз история повторяется? Тогда он просто идиот и я не понимаю о каком успехе проекта с идиотами можно говорить.

У меня паренек один, отличный математик и алгоритмист из пригорода

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

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

 

[WMix]

Вурдалак, все что сказанно не опровержимо, гитлер тоже мечтал о совершенном мире

 

[Redjik]

Вурдалак, все правильно говоришь, вот только меня смущают два факта.
1) В Екб на зп в 80 к в легкую берут человека, который может ответить на 2 вопроса:
- чем отличается inner join от left join
- зачем нужен полиморфизм (и для чего нужны интерфейсы)
Это примерный эквивалент московской зп, ибо у нас все же жить подешевле. Так что, да! Берут всех подряд и пофиг на скобочки после if.

2) Сейчас на проекте 80 процентов времени занимают правки за 2мя ребятами, у которых все отлично с именованием переменных и оформлением кода.
И знаешь - лучше бы они транслитом переменные называли, это хотя бы реально поправить, с этим реально жить... а вот архитектурные вещи (как приложения так и базы) приходится полностью переписывать.

 

[AmdY]

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

 

[Вурдалак]

Как выше упомянули, code review это не только про конвешены, но и про архитектурные моменты. Если в код попало такое говно, которое приходится полностью переписывать, то возникает вопрос как оно там оказалось вообще.

А касаемо соглашений по стилю, у меня есть такая фашисткая мысль для какого-нибудь нового проекта сделать хук с PHP-CS-Fixer, чтобы запушить не по CS было бы тупо нельзя. Ну, и возможность быстро отключить хук для экстренных случаев.

 

[Adelf]

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

В этом случае он будет отключен как-нибудь, да так и оставлен ;-)

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

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

 

[Вурдалак]

В этом случае он будет отключен как-нибудь, да так и оставлен ;-)

Не, надо хитрее, с какой-нибудь опцией можно пушить, пропуская хуки, но будет письмо на dev о том, что был not verified push или как-то так.

 

[grigori]

Принцип реально утопичный.
Когда мы написали неплохое приложение, а Сотмаркет объявил о банкротстве сокращениях - пофиг какой был стиль именования переменных. Гораздо важнее как приложение будет работать.
Архитектура важнее, чем стиль именования переменных. Постановка задачи важнее, чем архитектура. Анализ бизнес-логики важнее, чем постановка задачи.
Вот так у меня в работе расставлены приоритеты.

 

[Вурдалак]

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

 

[grigori]

это называется делегирование, сотрудников надо не только проверять, надо еще и просто доверять

 

[Redjik]

Я другого не пойму, вот пишите code review нужен. А кто его делать то будет?
Вы ведь пишите, что проверять нужно вообще весь код.
=> Должен быть человек, аля тим лид, который отлично знает приложение и его архитектуру и при этом отличный программер, который может объективно оценивать чужой код.
Нарисовали картинку? Так вот, вы правда думаете, что такой человек пойдет на code review???
Своих задач у него не будет (не будет времени), тим лид таким не будет заниматься, у него своих дел хватает.

 

[Вурдалак]

Да любой разработчик, который уже более-менее является частью команды. Если он плохо знаком с той часть системы, которую ревьюит, то заодно примерно поймёт как она устроена.

А у вас, насколько я понимаю, сразу 2 проблемы:
1) code review нет => можно коммитить всякое говно
2) чувак не понимает устройства других частей системы, он работает только со своей. Уволился чувак => сосите копайтесь в его говне, все остальные впервые увидели этот код. Single point of failure практически

 

[artoodetoo]

он не должен быть отличным программером, он должен быть педантом и беспощадной сволочью

 

[WMix]

любить работу это правильно, задумываться о названии переменных очень важно, но совсем не хочется делить на черное и белое, есть очень неплохие отеннки сероватых цветов.
глядя на наши имена переменных, попадаются такие как ek (einkaufspreis) vk (verkaufspreis) (закупка продажа) те. сокращения от немецкого языка, но мне это не режет слух как к примеру в одной компании была переменная nalstrdok (наличие страхового документа).

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

 

[AmdY]

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

добавлю недостающую часть манифеста

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева.

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

 

[Adelf]

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

 

[Вурдалак]

Вурдалак, все что сказанно не опровержимо, гитлер тоже мечтал о совершенном мире

О, закон Годвина в действии.

 

[WMix]

Adelf, я против немецких переменных, особено слово uebersetzen (наелся). а с счетом так получилось, смотришь на бумажку а там EK, VK, GVK, и само получается. да если буду делать webservice придется мапить

 

[grigori]

AmdY, наука экономика основана на аксиоме: ресурсы ограничены. Я оцениваю ситуацию в целом как менеджер.
Когда я хочу закоммитить что-то в фреймворк, я принимаю совсем другие требования: строгий coding style, документирование и naming conventions. Я делаю это не для денег.

Когда я работаю ради денег - я делаю то, что выгодно владельцу. Я не говорю, что для стабильной работы проекта нам нужно несколько серверов для failover. Я спрашиваю: "Какая частота падений и какая длительность простоев допустима? Какой у нас годовой бюджет на сервера?".
Я не говорю, что нужно делать полный code review, я обсуждаю приоритеты. Мне важнее чтоб зарплаты платили вовремя и повышали.