Как стать автором
Обновить

Комментарии 18

Рассмотрение коллегами

image
Я бы назвал пункт «Проверка кода коллегами» или просто Code Review.
если вы можете по стилю определить, кто из ваших коллег написал код — то это очень плохой знак

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

Ни в коем случае не спорю с вашими доводами, но правильный дифф покажет всё-таки нечто подобное:
Ну опять же — смотря где дифф смотреть. А вот конфликты резольвить определенно удобнее будет с описанным в статье подходом.
Предлагаете найти программу, которая позволяет подобным образом делать merge?

Описанный в статье подход плох тем, что он unenforceable. Нельзя сделать формальную метрику «длина строки не более 40 символов», засунуть её в git hook и надеяться на то, что ни у кого не появится необходимости действительно сделать такую строку. Без формальных метрик этот подход особенно плох, потому что новоприбывшие коллеги всегда будут ошибаться.

Есть только одно хорошее решение. Нужно использовать хороший софт, и не подстраиваться под плохой.

Вот авторы использовали лямбда-функцию со своим ORM, и получили серьёзные проблемы с производительностью. Тем не менее, если бы ORM через рефлексию подобные лямбды переводил в SQL, или если бы он делал custom SQL functions, или хотя бы выдавал предупреждение «осторожно, таблица будет загружена целиком», таких проблем бы вообще не возникало.

Но авторы пошли путём Роскомнадзора, (почти) решили проблему административно, продолжив использовать низкокачественное ПО.
> потому что новоприбывшие коллеги всегда будут ошибаться.

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

> Предлагаете найти программу, которая позволяет подобным образом делать merge?

Ну только «подобным образом _удобно_ делать». Заодно можно найти тех, кому удобно читать текст длинными строками, а не колонками (у человеков с этим проблемы, им почему то удобен spritz).
Потом обучить новоприбывших коллег этой прекрасной, но никому не известной, программе.

Ну а потом посчитать убитые на это человекочасы и сформулировать чем же тут административное решение проигрывает
Такой ерунде новоприбывшие коллеги обучаются максимум со второго тыканья носом.

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

Заодно можно найти тех, кому удобно читать текст длинными строками, а не колонками (у человеков с этим проблемы, им почему то удобен spritz).

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

Впрочем, длинные строки говорят не о том, что «кто-то тут не умеет оформлять», а о том, что тут ORM с использованием method chaining вместо хорошего набора комбинаторов. ПО плохое, как всегда.
Так вы просто смотрели как текст носом месяцами и вручали про ущербные технологии, или Вы нашли и внедрили совершенный софт?

У вас недовольство технологиями не так уж сильно коррелирует с желанием ими поделиться. От административных решений толку больше
* Так вы просто смотрели как тыкают носом месяцами и бурчали про ущербные технологии
Везде можно так смотреть git diff --word-diff или отдельные утилиты типа dwdiff всё покажут и в консоли.
Я за короткие строки, но дифф тут явно не аругмент
Всё это прекрасно, кроме одного: главная страница вашего сайта своей тяжестью просто убивает обычные компьютеры.
А уж эта новомодная фича с живым видео на фоне, которое ещё и стартует само без спроса…
Какие-то детские примеры с использованием where и sum. У них реально был такой код? Реально для кого-то неочевидно, что лучше фильтровать суммировать на уровне базы данных, а не приложения?
Я бы сказал по другому — «какой то самопиар»
Приэтом делать map поверх массива AR сущностей вместо того, чтобы сделать #pluck в первом примере.
Ага, их код:
usernames = Users.where(:status => 1, :deleted => false).map{ |u| u.first_name.downcase }.reject{ |n| n == ‘john’ }.map{ |n| n.titleize }


Мой код:
usernames = Users.where(status: 1, deleted: false).where("lower(first_name)!='john'").pluck('lower(first_name)').map(&:titleize)

В прочем тут тоже видны косяки:
Что за «status: 1»? Это же классическое волшебное число, которого нужно избегать (как минимум scope-ом заменить)
Да, глубина рассмотрения вопроса захватывает дух: обеспечение качества кода в масштабных проектах достигается 1) кодинг-стайл 2) код-ревью 3) тестирование.

Видно человеку сказали «надо попиариться, напиши как мы работаем», думал автор не долго. А ведь компания-то — передовая. Для социума то, что они делают, это — прорыв, повышают организованность человеческого общества програмными средствами в рамках капиталистического хозяйствования в масштабах Земли. Бросают вызов одной из крупнейших, консервативнейших и most established индустрий планеты — гостиничной. В данном случае автору лучше было бы просто нащёлкать фоток из офиса, тем более из «130 человек», наверняка есть и девушки красивые, и модные хипстеры, есть что показать наверняка.
Автоматизацию проверки и коррекции стиля js кода какую-то используете в IDE? Если да, то можно еще несколько предложений именно об этом?
Господи, когда уже прекратят выпускать зеркала-мониторы? Смотреть на такой сплошная боль
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.