Робочий процес, редагування речей, які не є вашим поточним завданням

12

Зазвичай, коли я програмую, я маю перед собою чітке завдання, але знаходжу дратівливі речі, які я хотів би прибрати, продовжуючи.

Тут я бачу три варіанти:

Зробити це пізніше (можливо, забув / доведеться витратити час на додавання квитка)
Зробіть це зараз і виконайте це разом із моєю поточною роботою (незрозуміло)
Зробіть це зараз і виконайте це окремо (доведеться його знайти, можливо, помилиться і невмисно перейдіть до варіанту №2)

Це, мабуть, досить базово, але які способи обійти це за допомогою svn / git / other?

— Nattfrosten
джерело

пов'язані (можливо, дублікат): Код функції + код інфраструктури - як структурувати коміти / проблеми JIRA?

— гнат

Я зазвичай йду з 2-м варіантом. Але якщо я зробив багато рефакторингу, я роблю два окремих коміти. 1 для мого конкретного завдання та ще одне, що я позначено як "Рефакторинг", яке я rebaseзамість цього merge.

— Альтернатекс

7

Особисто я думаю, що це залежить :-).

Для невеликих виправлень найкращим є варіант три (зараз, в окремій комісії), тому що накладні витрати робити це пізніше не варто. У цьому випадку ви просто створите окремий комітет. Як це зробити, залежить від VCS, який ви використовуєте, і це окреме питання :-).
Якщо це більше виправлення , ви створюєте квиток. В іншому випадку ви ризикуєте постійно ухилятися від свого основного завдання ("О, дивіться, ще одна можливість рефакторингу, о, є ще одна, і там, і там ...").

— sleske
джерело

Для вашої першої кулі невеликі виправлення, негайно виправлення редагування здається найкращим варіантом. Я поняття не маю, чому я не думав про це, я думаю, шкідливі звички. Я, як правило, трохи потрапляю до кодуючої частини програмування, на відміну від частини управління кодом :)

— Nattfrosten

@Nattfrosten: Так, це природно, і це не погано - адже, зазвичай, увага повинна приділятися кодуванню. Управління кодом - це просто для полегшення кодування.

— sleske

5

Розглянемо це. Коли ви «знайдете дратівливі речі (...) для прибирання» і ви приймаєте виконавче рішення для цього, ви вирізаєте решту своєї команди з обговорення пріоритетів та прийняття рішень. Ви дозволяєте вашому порядку денному козирувати всім іншим через ваші привілейовані стосунки з кодом. Я не думаю, що це приємно. З досвіду це також призводить до обурення команди / акціонерів.

Натомість створіть проблему / завдання для очищення / рефакторингу. Хоча це свіжо у вас в голові, перелічіть важливі причини: оцінки підвищеної стійкості, простоти в обслуговуванні, такі речі. Можливо, включіть оцінку зусиль залежно від того, як працює ваша команда. Потім на наступній зустрічі з вибором / завданням / пріоритетами викладіть свою задачу рефакторингу та порівняйте її з іншими завданнями. Як команда, вирішіть, коли вона має бути завершена.

Будь ласка, не думайте, що я кажу вам викинути здоровий глузд в ім'я принципів. Використовуйте голову. Якщо у функції, яку ви редагуєте, є щось потворне, це не нова задача рефакторингу. Виправте це і перевірте все. Якщо перейменування ресурсу, з яким ви працюєте, на щось більш розумне, впливає на кілька додаткових вихідних файлів, це не нова задача рефакторингу. Виправте це і перевірте все. Якщо, з іншого боку, вам не подобається, як інший розробник (Мітч, я ненавиджу цього хлопця) робив щось у функції, яку ви не редагуєте, і зазначена функція, здається, працює нормально, залиште його поки що в спокої . Створіть завдання рефакторингу та представіть свою справу своїй команді.

Якщо ваша команда рефакторингу завжди не відповідає своїм новим функціям, почніть шукати іншу роботу. Простіше знайти роботу, коли вона вже є.

— Мізерний Роджер
джерело

1

Дуже дякую за цю відповідь, до цих пір я в основному брав участь у сольних проектах, тож саме звідси і з’явився мій погляд. Мені доведеться змінити багато звичок, щоб згодом краще вписатись у команду, і така річ - саме те, що мені було потрібно.

— Nattfrosten

Той самий висновок, але часто начальники вирішують піти на нові функції, а не на рефакторинг: - |

— Марк Херд