Якщо клопі 5+ років, то це особливість? [зачинено]

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

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

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

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

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

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

Я відчуваю твій біль.

Але виправити щось лише тому, що це помилка - недостатньо вагома причина.

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

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

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

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

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

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

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

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

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

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

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