Реєстрація коду «коментування» [закрито]

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

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

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

Ми хочемо врешті-решт досягти точки, коли ми в повній мірі використовуємо переваги Постійної інтеграції та автоматичного розгортання на веб-сервері розробки. На даний момент не існує версії веб-серверів або серверів баз даних для розробки, але це все незабаром буде змінено.

У будь-якому разі, які ваші думки? Чи вірите ви в те, що "закомментований" код корисно мати у сховищі?

Мені дуже цікаво почути інших на цю тему.

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

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

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

Ось принципи, яких я навчився і намагаюся дотримуватися:

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

Це означає:

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

Отже, підсумовуючи, НІ! Якщо код не готовий перейти до наступного етапу (залежно від того, який для вас: IntTest / QA / UAT / PreProd / Prod), його не слід привласнювати до магістралі або гілки мульти-розробника. Період.

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

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

"Ніколи" рідко буває хорошим словом для використання в настановах.

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

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

Коментований код ніколи не повинен реєструватися з метою збереження історії. У цьому полягає сенс контролю джерела.

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

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

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

Один випадок, коли я залишаю коментований код:

// This approach doesn't work
// Blah, blah, blah

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

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

Думаю, ми всі згодні з цими пунктами:

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

Деякі кажуть, що існують інші категорії, такі як тимчасово видалений код, або додаткове, але неповне вдосконалення, яке включає невелику кількість коментованого коду як документацію того, що буде далі, або дуже короткий (в ідеалі 1 рядок) фрагмент коментованого код, що показує щось, що ніколи не слід повторно додавати. Коментований код ЗАВЖДИ повинен супроводжуватися коментарем, який говорить про те, чому його коментують (а не просто видаляють), і вказує очікуваний термін служби коментованого коду. Наприклад, "Наступний код приносить більше шкоди, ніж користі, тому коментується, але його потрібно замінити перед випуском XXX."

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

Коли мені реєструвати коментований код? Один із прикладів - коли я попередньо видаляю те, що, на мою думку, існує велика ймовірність, що його потрібно буде додати найближчим часом у якійсь формі. Коментований код повинен служити прямим нагадуванням про те, що він є неповним. Звичайно, стара версія знаходиться під контролем джерела, і ви можете просто використовувати коментар FIXME як прапор, що потрібно щось більше. Однак іноді (якщо не часто) код є кращим коментарем.

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

Рекс М сказав: 1) Перевірте лише повну функціональність, 2) [Якщо] завдання занадто велике - розбийте його на менші, які можна виконати.

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

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

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

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

Я думаю, ніколи не буває занадто сильним станом.

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

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

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

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

Для мене коментований код, як правило, розглядається як прояв неповаги до менш задумливого колеги.

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

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

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

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

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

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

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

Я припускаю, що ви з табору "хорошого коду", а він - з табору "робочого коду".

[EDIT]

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

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

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

З мого досвіду, комутатори розробників коментуються кодом.

Іноді паралельно будуються нові фонові інтерфейси, а активуючі перемикачі коментуються в контролі джерела.

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

Ще одна причина реєстрації коментованого коду:

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

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

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

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

На мою думку: якщо розробники працюють у власних гілках або у власній зоні пісочниці, вони повинні мати можливість реєструвати все, що хочуть. Коли вони перевіряють код у спільну гілку (філію функцій, гілку команди або, звичайно, MAIN / trunk), код повинен бути якомога недосконалішим (без коментованого коду, більше FIXME тощо).

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

Щоб вирівняти цю розхитаність, переконайтеся, що всі знають, що коментований код має термін дії. Будь-хто може видалити коментований код, якщо він існує цілий тиждень і ніколи не був активним. (Замініть "тиждень" тим, що вам здається правильним.) Таким чином, ви залишаєте за собою право вбивати безлад, коли бачите це, не втручаючись занадто безпосередньо в особисті стилі людей.

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

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

Я вважаю, що це ускладнює код і ускладнює читання.

У мене немає проблем з перевіркою напівзавершеного коду (отже, ви отримуєте перевагу контролю над джерелом), яку не викликає жива система. Моя проблема полягає у пошуку розділів кодованого коду без пояснення. Ділема полягала в тому, що код був виключений.

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

/* My commented code start here
My commented code line 1
My commented code line 2
*/

Замість того, щоб на індивідуальній основі, наприклад:

// My commented code start here
// My commented code line 1
// My commented code line 2

(ви зрозуміли ідею)

Причиною, з якою я вживаю надзвичайну обережність, є те, що залежно від технології ви повинні бути дуже обережними щодо інструменту diff / merge, який ви використовуєте. З певною системою управління вихідним кодом та певною мовою інструмент diff / merge можна легко сплутати. Наприклад, стандартна різниця / злиття ClearCase, як відомо, погана для об'єднання файлів .xml.

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

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

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

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

Навіть тоді огляд більш ніж приблизно 3 версій в основному ніколи не трапляється.

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

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

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

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

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

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

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

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

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

Я думаю, що коментований код вважається "марнотратством".

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

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

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

Потрібно задати питання " чому " код коментується. Кілька порад:

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

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

Якщо ви коментуєте код, оскільки "щось не працює", тоді ВИПРАВІТЬ ! Поширений сценарій - "непрацюючі тести" або "завдання" . Якщо у вас є такі, ви заощадите собі багато часу, або виправивши їх, або просто позбувшись їх. Якщо їх можна «зламати» протягом певного періоду, їх, швидше за все, можна зламати назавжди.

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

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

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

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

У коментарі ви зазначаєте, що не використовуєте приватні відділення. Моє питання до вас - чому ні? Гаразд, я нічого не знаю про TFS, тому, можливо, є вагомі причини. Однак, використовуючи git протягом року, я повинен сказати, що хороший DVCS повністю розсіює цю напругу. Бувають випадки, коли я вважаю, що коментування коду є корисним, оскільки я будую заміну, але я втрачу сон над ним, якщо буду наносити це іншим. Можливість локальної гілки означає, що я можу зберігати значущі коміти для свого індивідуального процесу, не турбуючись про (або навіть повідомляючи) розробників про тимчасові помилки.

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

неповний / експериментальний код повинен бути у гілці, яку слід розробити до кінця. голова / багажник повинен бути основною лінією, яка завжди складається та є судноплавством. як тільки експериментальна гілка буде завершена, вона повинна бути об'єднана в головну / основну лінію. Існує навіть стандарт IEEE (IEEE 1042), який описує це, якщо вам потрібна документація про підтримку.

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

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

" Шрамова тканина " - це я називаю коментованим кодом. За днів до широкого використання систем контролю версій Code Monkeys залишали коментований код у файлі на випадок, якщо їм потрібно буде повернути функціональність.

Єдиний раз прийнятним є реєстрація "рубцевої тканини"

1. Якщо у вас приватне відділення і
2. Ви не встигнете змусити компілювати код без помилок і
3. Ви їдете у тривалі канікули і
4. Ви не довіряєте своєму VCS, наприклад, якщо ви використовуєте Visual Source Safe АБО .
   [РЕДАГУВАТИ]
5. У вас є незначна помилка, яка може бути повторно введена, якщо неправильний код не залишиться як нагадування. (хороший момент з інших відповідей).

Практично немає виправдання для №4, оскільки навколо є безліч доступних та надійних систем VCS, найкращим прикладом є Git .

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

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

[EDIT] Я б додав, що існує два основних сценарії, які потрібно розрізняти:

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

Просто скажіть "НІ" рубцевій тканині!

Не знаю - перед внесенням змін я завжди коментую оригінальні рядки - це допомагає повернути їх назад, якщо я передумаю. І так, я перевіряю їх.

Однак я вилучаю будь-який старий коментований код із попередньої реєстрації.

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

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

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

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

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

Також було б добре знати, хто прокоментував цей код, щоб, якщо потрібне якесь обгрунтування, їх можна було запитати.

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

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

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

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

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

Система VCS повинна допомогти розробнику в цьому робочому процесі (git - це відмінна система VCS, яка дуже добре працює з цим).