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

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

50% мого часу, проведеного в Notepad ++, аналізуючи журнали програмного забезпечення та намагаюся з’ясувати, що пішло не так. 30% виправлення чужих помилок, а решта (за наявності) перевірка розробниками коду спагетті.

Я почав ненавиджу цей продукт і думав про стратегію виходу з цієї компанії.

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

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

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

Іншими словами, заголовки здебільшого безглузді.

Стаття у Вікіпедії визначає архітектора програмного забезпечення :

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

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

• Я б сказала, що вище називається 50+30=80%підробка, яку вони вам дали .

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

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

_{Трохи позитивнішою увагою, ваше запитання демонструє хоча б одну майстерність, яка є досить важливою для архітектора: вміння класифікувати різні види діяльності та відслідковувати зусилля, витрачені на них. Розгляньте можливість додавати до "набору інструментів" додаткові навички, щоб узагальнити свої спостереження та оцінки та чітко повідомити про них, особливо вгору по сходах управління. :)}

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

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

Ви повинні бути активними:

1. Створіть плани навчання, щоб інші люди (розробник / підтримка) могли зняти навантаження. "навчіть людину ловити рибу" і всього цього джазу.
2. Винайдіть способи та розробіть інструменти для швидшого та легшого аналізу дефектів та виділення першопричини. Якщо вам здається, що це нудно, інші, можливо, менш талановиті або досвідчені розробники вважають це не просто нудним, але й складним і, можливо, навіть жахливим. Допоможіть їм подолати це за допомогою технологій.
3. Почніть зусилля, щоб підвищити якість продукту - спростіть, модулюйте, створіть тестові рамки - ведіть на прикладі, а не скуголяючи і не погрожуючи кинути.
4. Переконайтеся, що розробники знають, що ви робите, - а також ваші менеджери. Роль архітектора набагато більше стосується стосунків з іншими людьми, а тоді - кодування та аналізу. Наскільки ви можете ненавидіти це, тут відіграє ключову роль політика. Якщо переконатись, що ваші ровесники бачать ваші досягнення, це полегшить переконати їх пізніше, що ви праві. Якщо вас там ще немає, відправте свої претензії дослідженнями та POC.
5. Якщо все інше не вдається, і лише витративши час на спробу покращити справи, поговоріть зі своїм менеджером. Скажіть, що ваші навички краще використовувати при плануванні та розробці етапів, і подивіться, що можна зробити для зміни поточної ситуації. Ваш продукт може бути дрібним, і відповідь вашого менеджера може бути "ми потрібні вам для цієї речі прямо зараз, прямо зараз". Я хотів би наполягати на довгостроковому плані - як ми змінимо ситуацію, що склалася.

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

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

З огляду на те, що ви сказали:

50% мого часу, проведеного в Notepad ++, аналізуючи журнали програмного забезпечення та намагаюся з’ясувати, що пішло не так. 30% виправлення чужих помилок, а решта (за наявності) перевірка розробниками коду спагетті.

Це не роль справжнього СА, і натомість це більше того, що я мав би наш розробник 1, а програмісти рівня 2 починають разом зі старшим розробником. Я кажу, що, зокрема, тому, що я вважаю, що це дійсно допомагає новим розробникам в нашій компанії потрапляти в продукт і код, працюючи на цьому рівні над питаннями якості коду. Ви новий SA в своїй компанії, і вони змушують вас виконувати цю роботу, щоб потрапити в систему? Якщо так, то, можливо, це нормально на короткий час. Якщо це ваша щоденна робота і займається не один рік, то, можливо, саме час шукати іншу роль.

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

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

Це важко вирішити, але моя порада:

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

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

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

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

Удачі.

Ні, ви тут, щоб управляти великою картиною.

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

Однак ви можете впроваджувати та виправляти помилки в основній архітектурі.

Приклад: ви працювали над PRISM, MEF тощо у проекті WPF / C #, але ви не працювали б на XAML для відображення заставки.

Ви працювали б над розробкою БД, але не записували б збережені процедури для операцій CRUD.

тощо.

Частиною відповіді було б знайти інженера, який готовий взяти на себе цей вантаж.

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

Я бачу дві можливості.

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

2. Назва багато в чому церемоніальна - кістка, кинута вам, щоб утримати вас.

У цьому випадку керівництво може не бути дуже зацікавленим у зменшенні вашої підтримки.

-

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

50% мого часу, проведеного в Notepad ++, аналізуючи журнали програмного забезпечення та намагаючись з’ясувати, що пішло не так. 30% виправлення чужих помилок, а решта (за наявності) перевірка розробниками коду спагетті.

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

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

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

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

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

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

Якщо говорити, "так".

Ось як я кваліфікую свою відповідь:

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

Більше про №2:

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

Відповідь, мабуть, ні. Чому ви витрачаєте стільки часу на налагодження та підтримку проблем? Хтось призначає вам цю роботу?

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