Якщо я натрапив на некритичну помилку в коді (скажімо, помилковий апостроф у заяві про друк (помилку)), чи варто взяти на себе зобов’язання вирішити цю помилку, чи її просто слід залишити в спокої?

Зокрема, мені цікаво зважувати підсумки журналу фіксації проти значення вирішення цих некритичних помилок. Я схиляюся до їх вирішення. Я педантичний?

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

Ви можете скористатись тефтом TRIVIAL:або позначити його як тривіальний, якщо його підтримує VCS.

Ви не педантичні, і краще вирішувати їх окремо. Чим більше атомних змін, тим краще - ви не хочете, щоб виправлення помилки, що збивається, змішувалося з 500 змінами коментарів / помилок.

У загальному випадку: Так

Це завжди варто того , щоб збільшити ремонтопридатність Вашого програмного забезпечення.

Просто займіться цим.

Якщо ви просто збираєтеся відправити реліз ...

... а якщо ви не керівник команди, то проконсультуйтеся з ним .

Щодо змісту журналу комісій ...

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

Поширена практика - мати кілька завмираючих завдань у вашому трекері випуску для відстеження позачасових і нескінченних змін. Наприклад, не рідкість мати завдання для:

• великі автоматизовані нешкідливі очищення (пробіли білі місця),
• граматичні та друкарські полювання,
• будувати модифікації системи,
• тощо ...

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

Друкарські помилки повинні бути додані як фіксація. Виправлення неправильно написаних слів або граматичних помилок збільшить читабельність вашого коду.

Використання повідомлення про фіксацію, наприклад "Виправлена ​​помилка" або "Виправлена ​​помилка у файлі.c", допоможе вам відрізнити ці коміти від інших основних кодів.

Так, вам слід зробити це абсолютно, особливо на початку проекту.

Чому? Два бали:

1. Ви, ймовірно, не дізнаєтесь, чи є помилка "критичною" чи ні, поки не пізно. Деякі виправлення, ймовірно, не виправляються, оскільки всі думають, що це не буде великою справою. Поки не буде.

2. Виправити помилку на друку на ранній стадії та навмисно буде набагато простіше, ніж виправити її після того, як з нею було здійснено кілька сотень рядків викликів коду / функції. Знову ж таки, тимчасові хаки можуть стати настільки постійними напрочуд швидко. Ось чому мені доводиться мати справу з об'єктами, які мають і методи "CollapseAll", і "ColapseAll".

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

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

Якщо ви переживаєте за те, щоб змусити журнал фіксувати, ви робите щось не так. :-) Часті вчинки - це добра справа! Я постійно здійснюю виправлення помилок. Отримайте їх у кодовій базі якнайшвидше та прискоріть цикл розробки!

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

Чи дозволяє ваш процес управління змінами?

У моєму середовищі кожне зобов’язання, яке я приймаю, повинно бути пов'язане із запитом на зміну, який було запропоновано або діловими користувачами, або з обов'язковою зміною на системному рівні разом із відповідними процесами тестування кінцевих користувачів. Простий друкарський помилок, як ви описуєте, мабуть, не був би записаний як жоден із цих (я знайшов помилки друку та граматичні помилки в одному з моїх додатків, який існував більше 4 років, але ніхто не помічав), тож якщо / коли аудитори прийшли зателефонувавши, я б дуже важко пояснив себе.

Я врятував би зміни, як ви описуєте (а насправді є таке, насправді - ім'я методу неправильно написано, і я щойно його виявив) на час, коли у мене є "справжня" зміна, яку потрібно зробив також і поклав "фіксовані різні друкарські помилки" в журнал.

Використовуйте DVCS для редагування історії

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

Зберігайте здоровий глузд інакше

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

Зауважте, що функціональні помилки як і раніше повинні здійснюватися якнайшвидше в атомному коміті.

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