Зробити невелику зміну, випробувати її, потім «промити і повторити» - шкідлива звичка?

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

Я отримую список завдань, які потрібно виконати для вирішення, навіть невеликих невеликих завдань, наприклад,

1. Змінення ресурсів цього керування користувача
2. Змінення розміру іншого
3. Додайте трохи HTML та кодування в інший елемент управління

Усі ці завдання невеликі. Я маю на увазі, що їх можна зробити протягом 10 хвилин, але я погано звик робити невеликі зміни, а потім перевіряти їх знову і знову у веб-браузері . Це хороша практика?

Або я повинен виконати їх усі відразу, а потім перевірити їх разом?

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

• Це хороша практика.
• Ви слідуєте науковому методу.
• Якщо ви змінили кілька речей перед будь-яким тестуванням, то тестування кожного буде складнішим, а може бути і недостовірним, оскільки попередні умови буде складніше підготуватися, і різні зміни можуть взаємодіяти між собою за способами, яких ви не передбачали.
• Час, коли ти відчуєш, що зараз "витрачаєш" , пізніше відновишся на етапах інтеграції, тестування та підтримки.
• Шлях.

Внести багато невеликих змін і протестувати кожну з них - це не погано. Це дозволяє побачити вплив кожної зміни, і тоді, коли одна зміна спричинить проблему, набагато простіше дізнатися, яка зміна викликала проблеми - найновішу!

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

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

Ваше запитання складається з двох частин:

1. я повинен виконувати їх один раз, а потім перевірити їх разом?

   Я припускаю, що ви використовуєте VCS .
   А для відстеження, які завдання виконано, є сенс розподілити список завдань до списку комітетів: одне завдання, одне виконання .

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

   Відповідь чітка:

   Ні, внесіть зміни лише одна за одною - одне завдання - одна фіксація .

2. але у мене погана звичка робити невеликі невеликі зміни, а потім перевіряти їх знову і знову в веб-браузері, це хороша практика?

   Добре практикувати тестування коду / інтерфейсу що завгодно , але це нісенітниця робити це знову і знову в браузері. Є інструменти, які роблять це автоматично для вас ( Selenium, PhantomJS / Casper, ZombieJS )

   Відповідь на цей випадок:

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

Для будь-якої звички, яку має розробник, є 2 основних питання:

1. Як це впливає на якість коду, який ви робите?
2. Як це впливає на вашу продуктивність?

Якщо відповідь на обидва - «Це робить краще», відкручуйте звичку, навчайте її інших!
Якщо відповідь на одне - «Краще», а на інше «Гірше» - це стиль, і ви повинні бути усвідомленим. Це не завжди застосовується, і вам може знадобитися докласти зусиль, щоб придушити це раз у раз.
Якщо відповідь на обидва - «Негативна» - у вас серйозна проблема.

Звичайно, для перших 2 випадків слід також подумати про те, "чи можна позитивний ефект якось автоматизувати чи інституціоналізувати?". Можливо, краще написати тест, ніж кожен раз пробувати різні браузери? (Зауважте, я знаю, що перевірити правильний макет у веб-розробці не так просто. Я не кажу, що це завжди можливо чи варто часу).

У цьому конкретному випадку мені здається, що якість підвищується, продуктивність може знижуватися. Що стосується невеликих змін, то, швидше за все, це погано (особливо, якщо зміни взаємопов'язані), для більших - це щось добре. Поки ви також тестуєте кінцевий результат (уникайте "кожен модуль був протестований і працює, тому вся справа працює також, не потрібно тестувати його!").

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

Це залежить від домену. Для розробки веб-сторінки це буде добре, і ви можете отримати негайний зворотній зв'язок (навіть це можна зробити безпосередньо в браузері!). Аналогічно, це буде добре для всього, що не потребує тривалого часу для ініціалізації. Це є кращим, оскільки це забезпечує низьке розумове навантаження та зменшує ймовірність помилок.

Однак для дійсно великих проектів, де вам потрібно зібрати код, а витрачений час нетривіальний (декілька хвилин), це може призвести до багато простою, тому вам часто доводиться вдаватися до:

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

(Можливо, є й інші способи.)

Як заявили інші, це, безумовно, не погана звичка. Я, як правило, волію вносити відразу кілька змін. Єдиний виняток - якщо у мене великий список змін, які не впливають один на одного (наприклад, зміни в другорядних стилях або копії, зміни на різних сторінках тощо). Якщо ви змінюєте макети, дотримуйтесь змін одночасно, щоб ви могли переконатися, що все є на 100% у всіх підтримуваних браузерах, перш ніж переходити до наступного випуску.