XC4: Тестирование кода/модульность/читабельность/запахи кода

Контрибьютерам/приемщикам в XC

Тестирование кода/модульность/читабельность/запахи кода


подходи к любому изменению - как к источнику багов

если ты не нашел багов - значит плохо поработал
баги есть всегда
весь вопрос в их серьезности



если изменений слишком много
то очень высока вероятность ошибок


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

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

требуй хорошей читабельности и модульности - это гарантия что ты найдешь все баги


если читабельность/модульность плохая,
то переделывай


плохая читабельность/модульность это всегда баг, если не сейчас, то при следующем изменении


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


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

Правильно найти и устранить корневую причину - кучу дерьма
нежели фиксить сам запах.

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

Без решения родительской-корневой причины фиксить дочерние причины методом заплаток - это неэффективная работа программиста.