Список из рекордов на коленке

Честно подсмотрено.

THeader = record
  x,y,z: TMyRecordField;
  NextLabel: packed record end;
end;

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

Парное_программирование VS ревью_кода

 Данная заметка - реакция на статью http://alexnesterov.com/code-review/, где практика code review рассматривается как антипаттерн, а парное программирование как способ решить задачи ревью кода правильно. 

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

Минусы парного программирования

Минусы full-тайм парного парного программирования которые сразу бросаются в глаза:

1. Практика full-тайм парного программирования доступна не всем компаниям:
• Не каждый кандидат может/согласится работать в такой методологии. 
• Вопрос организации пар тоже не самый простой.
• Все остальные процессы в компании должны затачиваться под парное программирование: организация рабочего места, распорядок дня (приход-уход, удаленная работа, больничные, обеды).
• Т.е. отрезаем себя от части рынка труда и добавляем дополнительные сложности. 
2. Фул-тайм парное программирование не всегда эффективно. Есть множество достаточно простых  или рутиных задач в которых от создание пары не получить буста в производительности или качестве. Т.е. фул-тайм парное программирование просто получение максимального качества без учета экономической обоснованности. 
3. Парное программирование не решает всех задач ревью код
• Как происходит распространение знаний между парами? Ротациями пар? На сколько это эффективно и какой лаг? 
• Код ревью под парами (инструменты настроены и все знают как ими пользоваться) позволяют в любой момент подключить нужное количество ревьюверов в асинхронном режиме) 

Золотая середина?

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

1. Мозговые штурмы или решение сложных задач требующих скорейшего решения. 
2. Менторство для новичков. 

Мифические проблемы ревью кода

Неправильное использование любой техники может привести к ее негативному восприятию.

Потеря контекста

Это не проблема, а сигнал что в процессе разработки что то не так. Контекст и мотивация автора должна быть понятна из ревью. Про это у меня есть статья http://cemick.blogspot.com/2015/08/svn-git-git.html. 

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

Это не баг, это фича

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

Отсутствие эмпатии

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

Нарушение потока автора

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

Что же такое ревью кода

1. Это гибкость
   Можно организовать менторство.
   Можно в любой момент подключить нужное количество людей с известными всем правилами обсуждения и документированием.
   Можно выпонять асинхронно и синхронно. 
2. Контроль соблюдения стандартов и правил оформления кода 
3. Распространение знаний о важных изменения в проекте. Об изменения в архитектуре и в сквозной части функционала необходимо извещать все заинтересованные стороны.
4. Повышение квалификации 
5. Сохранение дополнительной метаинформации по коммиту: обсуждение в рамках ревью остается задокументированным. 
6. Распределение нагрузки по контролю за кодовой базой или распространением информации с тимлида или начальника отдела на всех.