Як поводитися з керуючими системами?

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

Зараз керівництво хоче продовжити проект на ще один рік, і в цей час майже втричі базу користувачів.

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

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

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

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

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

Зараз керівництво хоче продовжити проект на ще один рік, і в цей час майже втричі базу користувачів.

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

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

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

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

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

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

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

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

Я вже писав звіт, в якому висловлював свої занепокоєння

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

Зараз керівництво хоче продовжити проект на ще один рік, і в цей час майже втричі базу користувачів

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

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

підтримка застарілої системи, розробленої декількома розробниками (в різний час) протягом останніх 5 років

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

Як стажист (або будь-яка позиція початкового рівня) як я "відштовхуюся"?

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

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

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

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

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

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

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

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

Що ви можете зробити:

Залиште речі чистішими

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

Створення документації

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

Зробити це менш болісно

Як я вже заявив, ви можете висловити свої занепокоєння, але найкраще просто старанно працювати над системою та покращити роботу над тими, хто після вас. Виправити помилки належним чином. Документ. Дисперсний код пахне. Зробіть це краще. І коли ви робите ці речі, повідомте про це начальству. Скажіть їм, що ви робите X, Y і Z для поліпшення процесу розвитку. Це створює довіру і в перспективі допоможе вам і вашій компанії більше, ніж будь-що інше.

ВАМ НЕ !!! Це ВЕЛИКІ можливості!

Ви стажування для навчання! Цей проект є реальним світом, як він отримує.

Вам дуже пощастило це мати. Те, що ви некваліфіковані, не викликає ваших проблем. (Якщо \ коли менеджмент зрозумів це, ви отримаєте багато)

Ви отримаєте кваліфікацію, коли закінчите цю стажування, і це чудова новина.

PS: Зробіть резервні копії релігійно, будьте впевнені, що ВСЕ, що ви робите, може бути відкинуте назад. Почніть з проблем, які є "Простими виправленнями", але великі больові точки для користувачів. Робіть кроки дитини.

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

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

Ось що я рекомендую вам зробити:

1. Спочатку залиште свою неприязнь до "спадкової системи". Це зробить вас дуже протилежним.

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

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

Діпан.

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

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

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

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