Чи повинен я комусь сказати, що їх вчинення спричинило регрес?

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

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

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

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

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

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

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

Тоді або:

Їх: Зрозуміло, це вирішити ... ситуація, про яку я не знав ...

Або щось у руслі:

Їх: Ні шкода, що я не пам’ятаю, мені виглядає неправильно.

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

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

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

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

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

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

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

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

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

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

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

Загалом, так .

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

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

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

Завжди пам’ятайте, що якщо ви зможете дізнатись, хто перевірив «помилку», вони можуть так само легко дізнатися, хто «виправив» їх код. Якщо ви думаєте, що вони будуть засмучені / роздратовані / збентежені, дізнавшись про вашу зміну після факту, обов'язково повідомте їх заздалегідь.

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

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

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

Ви отримуєте чудові відповіді тут.

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

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

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

Досить часто помилка була моєю, і вона це знала. Це вміння.

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

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

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

Гарна тяга до вашого питання! Всі говорили вам, що робити. Ви повинні сказати? ТАК! Щоразу, коли питання запитує «чи варто спілкуватися більше?», Відповідь майже завжди ТАК!

Але додати щось інше: ваше приміщення помилкове.

Співробітник взяв на себе зобов’язання, яке не порушило CI, але призвело до виявлення проблеми.

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

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

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

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

Скажи їм, коли його тільки ти двоє.

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

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

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

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

Так, абсолютно скажіть їм про це, але не робіть цього перед усією командою

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

Зазвичай я вважаю, що це найкраще працює, коли ви починаєте з компліменту, а потім переходите до помилки ... щось на кшталт "виправлене вами виправлення працює чудово, АЛЕ, здається, зламано x, y, z" або "спасибі, що зробили , b, c, Але, здається, це викликає x, y, z "

Проста відповідь: так.

Більш довга відповідь: Моя остання робота була в компанії Agile, яка використовувала TDD з інструментами CI, щоб переконатися, що те, що було в нашому репортажі SVN, було хорошим, працюючим кодом у всі часи. Коли щось було зроблено, наш сервер TeamCity отримав копію, склав та провів тестові одиниці. Він також проводив інтеграційні тести щогодини. Якщо щось було зроблено, що призвело до відмови CI, кожен отримав електронний лист із повідомленням про те, що збірка була зламана на основі зобов'язання певної особи.

Це не завжди все ловило; горе нам, ми не застосовували кодове покриття, і навіть якщо щось було охоплено тестами інтеграції чи інтеграції, вони можуть не використовувати цей код достатньо. Коли це сталося, той, хто отримав завдання виправити відому проблему (якщо QA її зловив) або дефект (якщо, dun-dun-dun, клієнти це зробили), запустив би «вину» (показує, хто востаннє змінив кожен рядок файл коду) та визначте винуватця.

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

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

У грі багато факторів.

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

Якщо проблема була незначною - помилка друку / thinko / cut & paste - і вимикач зайнятий однолітком, і ви впевнені у своїй оцінці проблеми, вам, ймовірно, не потрібно доводити її до відома. (наприклад foo.x = bar.x; foo.y = bar.y, foo.z = bar.y).

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

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

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

Що станеться, якщо ви не скажете їм?

Мінуси

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

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

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

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

Плюси

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

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