Нещодавно у мене виїхав колега з нашої компанії. Перед відходом він зашифрував компонент, який сильно просочився в пам'яті, що призвело до відключення виробництва ( OutOfMemoryErrorна Java). По суті, проблема полягала в HashMapтому, що записи зростали і ніколи не видалялися, а рішенням було замінити HashMapреалізацію кешу.

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

Який загальний протокол для подібної ситуації?

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

Незалежно від того, чи є він другом, чи колишнім колегою.

Нічого не робити.

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

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

Якщо ти не підпадає під дію NDA, я б ризикну сказати, що йому / їй не буде байдуже.

Що вбік, чи невдоволена ця людина? Це було щось, що насправді могло бути навмисним?

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

Цей колега - це ваш ДРУЗЬ, з яким ви продовжуєте тісний контакт після від'їзду? Якщо так, то поговоріть про це, якщо / коли ви приймаєте пиво на барі.

Інакше навіщо турбуватись?

PS: Що стосується NDA, у чому тут секрет? Містер X - той, хто написав код у будь-якому випадку, і якщо вихід залишається нещодавним, програмне забезпечення продовжується на тому ж рівні розкриття.

Все було б інакше, якби ця розмова відбулася через 3 роки після від'їзду, і ти скажеш речі, які він не повинен знати, крім тебе ...

Це залежить від того, як ця людина покинула та ваші стосунки з ним / нею.

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

Якщо ні, то ви, мабуть, витрачаєте його час і свій.

* Чи ви зіткнетесь з проблемою щодо розкриття активів / даних компанії, які не є працівником?

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

Напевно, ні

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

Всі ми робимо випадкові помилки.

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

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

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

Тримайте це цивільно

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

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

Юридичні?

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

Мисли позитивно

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

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

Дізнайтеся з їхніх помилок

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

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

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