Чи повинен програміст виправити чужу невдалу збірку? [зачинено]

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

Чи правильно зробив другий програміст чи він просто зачекав, поки перший програміст вирішить проблему?

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

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

Це залежить.

• Чи помилка настільки очевидна, що додавання бібліотеки - це спосіб її виправити? Іноді виправлення полягає в пошуку обходу, щоб не потрібна ця бібліотека.

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

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

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

Ваша репутація на 100% у вашому контролі. Такі речі затьмарюють вашу репутацію і намагатися відполірувати затьмарену репутацію дуже складно.

Спілкуватися

Для цих сценаріїв немає жорстких правил (крім правил власної команди).

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

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

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

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

Мій девіз: не призначати SVN після 15:00, таким чином ви завжди зможете виправити свої власні збої.

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

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

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

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

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

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

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

Звичайно, якщо у вас є випадок автоматичного вимикача, особливо з малюнком "зареєстрований, пішов додому, побудований зламаний днями" - відповідальній особі потрібно поговорити про те, чому існують системи та тести КІ та як слід перевірити перед реєстрацією :)

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

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

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

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

Це залежить, це залежить ...

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

У будь-якому разі, для останнього хлопця, який зламав складку, щоб носити дивну шапку, достатньо, щоб наступного разу приділити більше уваги ^ _ ^

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

У інших умовах це дуже грубо або очікувано з дуже поганих причин.

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

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

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