Коли здійснювати код?

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

Тож питання полягає в тому, коли дійсно взяти на себе зобов’язання зі сховищем, щоб виправдання було виправданим?

Як доповнення: чи правильна практика вимірювати розвиток проекту на основі його зобов'язань?

Ви здійснюєте зобов’язання, коли ви досягли стану кодової бази, яку хочете запам'ятати. Існує маса причин, чому ви можете запам’ятати певний стан кодової бази, тому не може бути чітких і швидких правил, коли потрібно виконувати. Однак кількість комісій, безумовно, не є показником якості або прогресу.

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

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

Це також залежить від системи SCM, яку ви використовуєте. Розподілені системи, як правило, роблять злиття та роздвоєння безболісними та швидкими, і ви можете здійснювати місцеве; це означає, що ви повинні зробити багато і натиснути / злитися, коли ви зробили значну кількість роботи. З централізованими системами, такими як svn чи cv, доручення дорожче, і це впливає на всіх. Розгалуження частково вирішує це питання, але оскільки це відбувається на сервері, воно може бути болісно повільним, а злиття може бути громіздким. Тож із централізованими SCM часто існує більш ретельна культура, де ви виконуються лише після того, як ви виконали значну кількість роботи.

Щодо додатку: Будь ласка, не робіть цього. Рядки коду, кількість комітів, кількість знайдених / вирішених помилок тощо - це все дуже погані вимірювання якості або навіть кількості.

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

Для нерозподілених VCS (наприклад, SVN) застосовується та сама логіка, замість локального сховища використовуйте приватну гілку, а не push - злиття з основною гілкою.

Ви повинні робити зобов’язання рано і часто.

Я знаю людей, які здійснюють так часто, як кожні 90 секунд. Серйозно. Здається, працює на них. Я експериментував із завданням кожного разу, коли я зберігаю файл, що, мабуть, частіше 90 секунд. Сьогодні я, мабуть, здійснюю кожні 15 хвилин. VCS, який дозволяє розбити декілька комітетів на один і дозволяє локальним комітетам (наприклад, git), робить це набагато простіше.

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

Ви вимірюєте розробку товару на основі цінності, наданої його користувачам. Іншого точного вимірювання немає.

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

• Додайте новий фрагмент даних або функції
• Виправити одну або кілька помилок (по одному зафіксуванню для кожного виправлення, якщо можливо), де можна виправити:
  • Поліпшення продуктивності
  • Виправлення неправильної поведінки коду
  • Видалення друкарських помилок
• Код або дані рефакторингу без зміни семантики. Це включає:
  • Перезапис коду, який поводиться ідентично оригіналу
  • Зміна подання даних в інший формат
  • Форматування коду або даних, щоб відповідати вказівкам щодо форматування проекту
• Об’єднати зміни з іншої гілки (або вгору / вниз за течією)

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

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

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

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

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

І відповідати на ваші додаткові питання - НІ !! міра того, де знаходиться проект, ніколи не повинна визначатися кількістю комісій ... хто знає, що насправді було вчинено? Це було успішно протестовано системою чи навіть тестованим пристроєм. Тільки тому, що це зроблено - це не означає, що воно готове до виробництва.

Як доповнення: чи правильна практика вимірювати розвиток проекту на основі його зобов'язань?

Ні. Щодня було WTF про те, чому це жахлива ідея.

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

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

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

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

Як тільки відповідне завдання виконано . Завдання є частиною користувальницької історії .

Завдання виконується в наступних випадках:

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

Ви можете мати інше визначення зробленого .

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

Вчиняйте кожну істотну зміну, яку, на вашу думку, щось не порушує. Єдине, чого ви не повинні здійснювати - це зміни стилів, оскільки вони не втілюють зміни в логіці. Але в іншому випадку, чим менші зміни, які ви здійснюєте, тим краще.

Чим менше комісій, тим детальніше ви можете задокументувати процес думки, що є одним із аспектів хорошого журналу фіксування. Хороший огляд коду має стосуватися не лише кодового результату, але й продуманого процесу.

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

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

Ось як це працює з Git, але головне стосується будь-якого контролю версій.

Коли:

• він будує (ВЖЕ)
• одиничні тести проходять
• вона працює (якщо вона чітко не позначена як "незавершена робота")
• переваги збереження стану коду переважають клопоту виконувати тести, продумувати гарне повідомлення про фіксацію та вирішувати будь-які конфлікти злиття під час процесу фіксації