Виправлення помилок поза берегом

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

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

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

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

Аутсорсинг виправлення помилок, ймовірно, погіршить ситуацію.

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

Поки офшорні хлопці не замінять морських хлопців.

Ідіть , біжіть ... швидко і ніколи не озирайтеся ...

Я працював у такій компанії, вони думали, що вони розумні,

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

• давайте відкриємо офшорний офіс і дозвольмо іншим займатися цим.

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

хо ... але чекай ...

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

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

це зробило «сеньйорів» абсолютно непридатними для власних помилок. Найгірше, тому що все сталося так далеко, що менеджмент не усвідомив і те, і якість коду знизилася ДУЖЕ швидко з уже неприємного рівня якості.

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

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

Це методологія управління паперовим пакетом .

Станьте на залізницю, чекайте, коли поїзд приїде, коли його побачите, покладіть паперовий мішечок над головою і ... ПУФА .. поїзд пішов !!. Магія!

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

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

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

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

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

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

Я біг би далеко, далеко, далеко. Розробник завжди, завжди, завжди відповідає за виправлення власних помилок. Їжа собачої їжі є основним принципом хорошої інженерії.

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

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

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

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

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

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

Словом, тікай.

Чи справді вони очікують, що купа офшорних молодших розробників зможе виправити купу коду старших розробників? Начебто медсестра двічі перевіряє роботу всіх неврологів і переробляє її там, де він робив помилки. ПОГАНА ІДЕЯ!

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

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

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

На основі мого досвіду, що цитата говорить, що ваш потенційний роботодавець дешевий.

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

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

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

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

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

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

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