Все же ожидал дельных советов, а не очевидных вещей типа:
№6. Оба члена пары должны хорошо видеть экран
Сам я не особо люблю парное программирование, так как меня всегда сбивал с толку темп другого человека. Так что совет номер 5 нахожу хорошим.
Для меня работал такой хак: если вы работаете на ноутах, то можно просто сесть рядом каждый со своим ПК и изучать проблему. Когда у кого-то появляется дельная мысль, он ее озвучивает и показывает. Ведь необязательно же смотреть в один монитор, главное думать над одной задачей и делиться мыслями.
Через месяц вы можете и не вспомнить, что означает каждая строка кода. А тот, кто будет работать с вашим кодом, вообще этого не знает. Поэтому важно писать полезные комментарии, чтобы избежать проблем и сэкономить впоследствии время, когда придётся снова вернуться к этому коду.
Я бы сказал, что комментарии уместны тогда, когда читатель понимает, что написано, но не понимает, зачем так сделано. Иными словами, комментарии отвечают не на вопрос «что?», а на вопрос «зачем?». В таком случае уместно заметить, что этот воркэраунд к такой-то проблеме или что-то вроде того. А в целом я бы выделил две основных причины, чтобы не писать комментарии:
1. Вам не нужно помнить, что делает код. Так же как не должно составлять труда понять это за считанные секунды из простых и лаконичных строк кода. Короче вся эта фигня про самодокументацию
2. Иногда комментарии «уезжают» от того кода, который они объясняют. И получается, что они только путают.
Короче, пишите нормальный код, который не требует комментариев. Оставляйте комменты только там, где непонятно, зачем вы делаете то или иное действие.
А в чем проблема заинжектить моки в поля? InjectMocks, MockitoAnnotations.initMocks(). Те же моки уйдут в тестовый бин как через поля, так и через сеттеры
Но суть же не в том, что инъекция через поля — это зло, скорее злом является чрезмерно сложный класс. А если класс лаконичен и не требует рефакторинга, то будет ли проблемой заинжектить 1-2 поля через Autowired?
У меня плотный график до первых числе августа, поэтому я последние недели мало времени выделяю на рассказ. И качество контента в таком режиме сильно страдает, но скоро все вернется в свое русло)
Вы все фильтруете через свою призму восприятия. Обвинения против Джо строятся, в первую очередь, на личном отношении Райтнова к нему, это было в предыдущих главах. А еще какое-то странное восприятие, что допрос все моментально разложит по полочкам. Кстати, ночь в карцере может служить отличной интерлюдией к допросу, если углубляться в детали.
То есть, по-вашему, провести ДОПРОС потценциально опасного человека – это гарантия безопасности и торжество здравого смысла, а временно изолировать этого человека в карцере – это nobody cares?
Сам я не особо люблю парное программирование, так как меня всегда сбивал с толку темп другого человека. Так что совет номер 5 нахожу хорошим.
Для меня работал такой хак: если вы работаете на ноутах, то можно просто сесть рядом каждый со своим ПК и изучать проблему. Когда у кого-то появляется дельная мысль, он ее озвучивает и показывает. Ведь необязательно же смотреть в один монитор, главное думать над одной задачей и делиться мыслями.
Я бы сказал, что комментарии уместны тогда, когда читатель понимает, что написано, но не понимает, зачем так сделано. Иными словами, комментарии отвечают не на вопрос «что?», а на вопрос «зачем?». В таком случае уместно заметить, что этот воркэраунд к такой-то проблеме или что-то вроде того. А в целом я бы выделил две основных причины, чтобы не писать комментарии:
1. Вам не нужно помнить, что делает код. Так же как не должно составлять труда понять это за считанные секунды из простых и лаконичных строк кода. Короче вся эта фигня про самодокументацию
2. Иногда комментарии «уезжают» от того кода, который они объясняют. И получается, что они только путают.
Короче, пишите нормальный код, который не требует комментариев. Оставляйте комменты только там, где непонятно, зачем вы делаете то или иное действие.