Не соглашусь. Если рассматривать наш диалог, именно вопрос привел к тому, что мы выяснили:
— Мы кодим на php
— Для php кавычки не влияют на производительность.
Теперь нам только осталось договориться о том, какие кавычки использовать. И вероятнее мы будем исходить из того, какие кавычки уже использовались в остальном коде.
В данном случае использовать\не использовать одинарыне\двойные кавычки становится осознаным. Это гораздо лучше чем «У нас принято везде писать одинарные кавычки».
Цель вопроса не деморализовать, а заставить задуматься.
Человек не знает, что одинарные работают быстрее, поэтому они предпочтительнее, если нет обработки переменных. Он ищет информацию об этом, или спрашивает у проверящего. И вносит изменения в свой код.
Человек знает об этом, но данный код представляет из себя кладбище домашних животных. Время на рефакторинг нет. И кавчки не решат ни чего. Ну и смысл тратить время на исправление?
У вас идеальный код. Везде одинарные кавычки, все по гайдлайну. Вы объяснили человеку почему это так, и как это важно для вас лично. Человек занимается умышленным вредительством, осознано. Кастрируйте этого тупорылого #@удака, пока он весь мир не заразил.
Ну собственно, да. С кавычками я утрирую, но вот бывает, что проверяющий парится на вкусовщине — тут важно чтобы решение оставалось за исполнителем таска. Могут вдвоем запарится и ничего плохого в этом тоже нет.
Я конечно не исключаю, что и такое может быть и по другому никак. Но обычно стоит разделить такую Entity на структуру, пару тройку другую сервисных объектов, интеракторов, фабрик.
Нельзя пропускать коммиты если они содержут явные ошибки (Errors). Напр.: Забыл обернуть в транзакцию БД.
Остальные замечания сделать рекомендательными (Warnings). Удобно делать их вопросами. Напр.: Почему были использованны двойные кавчки вместо одинарных?. По факту это вкусовщина. Если инициатор коммита задумался после вашей рекомендации, то он скорее поправит код. Возможно это было осознаным решением. А возможно вам нужно забить на это замечание.
Ну и пулреквесты должны быть вменяемого объема, чтобы проверяющий их смог переварить. С 1000 строк я вероятнее отклонил PR.
Спасибо, что поправили. Тут это сделано скорее умышленно. Проверять грамотность написанного текста также можно периодически. Если есть возможность потратить на это время. Мне это дается сложнее, но это однако не значит, что я не могу написать текст без ошибок. А если верить авторам вышеизложенной статьи то я «безграмотный».
Делить по паттернам поведения тоже не верный подход.
Все люди делятся на две категории: те, у кого револьвер заряжен, и те, кто копают. Копай.
Я ем оливье когда я хочу его есть. Т.е. преодически, меня нельзя отнести ни к какой категории. Я использую новые технологии, переодически. Довожу до идеала код переодичекски. Проявляю оптимизм или пессимизм тоже перодически и.т.д. стараюсь всегда смотреть по ситуации, относить меня к какой-то категории нельзя. А к чему призывает эта статья — увидели паттерн поведения человека. Поставьте на нем клеймо. И по этому клейму применяйте решение.
Все люди делятся на две категории: те, кто мыслит стериотипами, и те, кто умеют думать. Копай.
Все евреи жадные, а американцы тупые, гуманитарии не могут мыслить логично, женщины не умеют пользоваться молотком. Куча каких-то штампов. Для комичной статьи написанно слишком серьезно. Для серьезной статьи написанно слишком глупо.
Из-за того, что бизнес-логика уходит в ServiceObjects, тесты для ServiceObjects выглядят как описание бизнес логики. И это очень и очень удобно. Писать на русском удобно, особенно если термины существуют только на русском языке. Бизнес вряд ли будет смотреть тесты, если у вас не IT компания. Но если вы смогли их заставить это сделать, вы очень круты :)
Так и есть. И зачастую все называют лошадью. И кобыл, и жеребцов и коров =)
На 180 градусов развернутся не получится, это решение не для MVP. Но всяческие корректировки проходят в разы быстрее. По-большому счету если изменился процесс — переписываем только ServiceObject, изменился порядок процессов — меняем Interactor. И из-за слабой связанности классов, не боимся, что у нас что-то рассыпаться в другом месте.
Согласен. Если смотреть на всякие старые методологии, вроде RUP, то в них, деятельность IT воспринималась как автоматизация документооборота. А результатом любой хоз. деятельности бизнеса являлся документ. А оборот это как раз связки, унификация и выстраивание потоков.
Да, это можно так решить. Но тест на степ Дано в системе 0 бронирований от пользователя это по факту, DELETE FROM booking WHERE user_id = ?. Или 'TRUNCATE users', что на самом деле не совсем корректный тест, так как мы искуственно подчищаем базу.
Мы проверяем увеличене на единицу.
Хотелось бы иметь что-то вроде
describe `Создается 1 бронирование в системе:`;
before_count = SELECT COUNT(*) FROM bookings where user_id = ?;
run nested steps;
after_count = SELECT COUNT(*) FROM bookings where user_id = ?;
after_count - before == 1;
Основная проблем gherkin это отсутвтие блоков, что делает его крайне не удобным языком для тестов. Взять те же отели, нам нужно посмотреть что у нас создалась бронь.
Дано незарегистрированный пользователь
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе
Чтобы проверить, на то что боннирование создалось. Нам надо убедится что создалась 1 запись в бд. Но посравнению с чем?
или нам очищать все бронирования перед началом теста:
Дано незарегистрированный пользователь
И в отеле нет ни одного бронирования
Когда пользователь заходит на сайт
И делает бронирование
То создается 1 бронирование в системе
Т.е. мы или каждый раз чистим базу, или перед тестом сохраняем количество бронирований в глобальной переменной. Что в любом случае дает знатный костыль.
Было удобнее если бы в функционале gherkin появилось что-то вроде:
Дано незарегистрированный пользователь
Создается 1 бронирование в системе:
Когда пользователь заходит на сайт
И делает бронирование
Без подобных вещей все тесты написанные для gherkin-спецификаций, подверженны огромной энтропии. Приэтом сами спецификации выглядят прекрасно.
— Мы кодим на php
— Для php кавычки не влияют на производительность.
Теперь нам только осталось договориться о том, какие кавычки использовать. И вероятнее мы будем исходить из того, какие кавычки уже использовались в остальном коде.
В данном случае использовать\не использовать одинарыне\двойные кавычки становится осознаным. Это гораздо лучше чем «У нас принято везде писать одинарные кавычки».
Цель вопроса не деморализовать, а заставить задуматься.
feature/epic_new_entity => feature/epic
Почему были использованны двойные кавчки вместо одинарных?. По факту это вкусовщина. Если инициатор коммита задумался после вашей рекомендации, то он скорее поправит код. Возможно это было осознаным решением. А возможно вам нужно забить на это замечание.
Делить по паттернам поведения тоже не верный подход.
Я ем оливье когда я хочу его есть. Т.е. преодически, меня нельзя отнести ни к какой категории. Я использую новые технологии, переодически. Довожу до идеала код переодичекски. Проявляю оптимизм или пессимизм тоже перодически и.т.д. стараюсь всегда смотреть по ситуации, относить меня к какой-то категории нельзя. А к чему призывает эта статья — увидели паттерн поведения человека. Поставьте на нем клеймо. И по этому клейму применяйте решение.
Впечатление сложилось правильное :)
Да, это можно так решить. Но тест на степ
Дано в системе 0 бронирований от пользователяэто по факту,DELETE FROM booking WHERE user_id = ?. Или 'TRUNCATEusers', что на самом деле не совсем корректный тест, так как мы искуственно подчищаем базу.Мы проверяем увеличене на единицу.
Хотелось бы иметь что-то вроде
Чтобы проверить, на то что боннирование создалось. Нам надо убедится что создалась 1 запись в бд. Но посравнению с чем?
или нам очищать все бронирования перед началом теста:
Т.е. мы или каждый раз чистим базу, или перед тестом сохраняем количество бронирований в глобальной переменной. Что в любом случае дает знатный костыль.
Было удобнее если бы в функционале gherkin появилось что-то вроде:
Без подобных вещей все тесты написанные для gherkin-спецификаций, подверженны огромной энтропии. Приэтом сами спецификации выглядят прекрасно.