Що ви повинні подати до столу як архітектор програмного забезпечення? [зачинено]

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

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

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

Маючи на увазі ці моменти, що повинен додати до столу СА? Чи повинні вони входити з менталітетом "встановлення закону" (так би мовити) та примусового використання певних інструментів, щоб відповідати "їхньому шляху", тобто вказівки щодо кодування, управління джерелами, зразки, документація UML тощо? Або вони повинні вказати початковий напрямок і стратегію, після чого відкласти назад і стрибати в міру необхідності для виправлення напрямку корабля?

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

Ось кілька оповідань про SA, які я пережив як спосіб обміну деяким досвідом, сподіваючись, що відповіді на мої запитання також можуть пролити трохи світла на ці питання:

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

• Один конкретний SA був проти використання певної бібліотеки, стверджуючи, що це повільно. Це змусило нас написати тонни коду, щоб досягти речей інакше, тоді як інша бібліотека заощадила б нам багато часу. Швидко вперед до останнього місяця проекту, і клієнти скаржилися на результативність. Єдиним рішенням було змінити певну функціональність для використання спочатку ігнорованого підходу, незважаючи на ранні попередження розробників. До цього моменту багато коду було викинуто і не використовувалось повторно, що призвело до понаднормових робіт та стресу. На жаль, оцінки, використані для проекту, базувалися на старому підході, який мій проект забороняв використовувати, тому він не був відповідним показником для оцінки. Я почув би прем'єр-міністра сказати: "Ми це робили раніше"

• SA, який буде застосовувати використання DTO, DO, BO, Сервісних шарів тощо для всіх проектів. Новим розробникам довелося вивчити цю архітектуру та SA, які неминуче застосовували вказівки щодо використання. Винятки з правил використання були зроблені, коли дотримуватися цих принципів було абсолютно важко. SA був обґрунтований у їх підході. Класи для DTO та всіх CRUD-операцій створювались за допомогою CodeSmith, а схеми баз даних - ще одна схожа кулька воску. Однак, використовуючи цю установку скрізь, SA не був відкритий для нових технологій, таких як LINQ до SQL або Entity Framework.

Я не використовую цю посаду як платформу для вентиляції. У моєму досвіді з вищезгаданими розповідями про SA були і позитивні, і негативні моменти. Мої запитання зводяться до:

1. Що повинен піднести до столу SA?
2. Як вони можуть досягти рівноваги у прийнятті рішень?
3. Чи варто підходити до роботи в галузі SA (як було визначено раніше) з урахуванням того, що вони повинні виконувати певні основні правила?
4. Ще що слід врахувати?

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

Архітектор систем повинен:

1. Вкажіть архітектуру високого рівня
2. Беріть участь у оглядах коду
3. Затвердити використовувані технології
4. Допоможіть розробникам у їх кодування
5. Ведення та моніторинг графіку розвитку
6. Випускайте артефакти SA, такі як діаграми UML, діаграми Ганта тощо.

SA повинні знати, як кодувати, і повинні брати участь у деяких роботах з кодування, мочити руки, так би мовити. Це підтримує їх зв'язок з гештальтом зусиль розвитку. Як казав одного разу дядько Боб Мартін , архітектор повинен зробити деякі кодування сам, щоб він міг бачити той біль, який він завдає іншим своїм дизайном.

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

Як і всі люди, SA може робити і помилятися. Хороші вчаться на цих помилках і стають кращими.

Я ніколи не наштовхувався на архітектора, який був корисним, насамперед тому, що вони не були практичними.

Для мене найбільші проблеми, які я бачив:

• сліпе дотримання процесу заради процесу
• сліпа упередженість до технології, перш ніж знати проблему
• створення та виконання правил без гарного обґрунтування
• rewrite from scratch менталітет

Кращі «Архітектори», з якими я працював, принесли до столу:

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

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

1 Що повинен донести до столу SA?

• Товста шкіра
• Хороші навички ведення переговорів
• Добре розуміння різних програмних рівнів (від нескінченної доброти AJAX до мережевого вводу / виводу низького рівня). Вам не обов'язково бути фахівцем, але ви повинні приймати важливі рішення щодо того, яке програмне забезпечення повинно виконуватися на якому рівні (іх).
• Готовність забруднити руки кодом, проекти з білого паперу просто не скорочують його.
• Заохочення майстерності програмного забезпечення - будьте вболівальником за те, щоб робити речі правильно, коли це можливо, і найкращим чином, враховуючи обмеження в інших випадках. Таким чином, такі як управління джерелами, TDD, збірка та CI, кодування DOJO, огляди коду, хороша система відстеження проблем тощо

2 Як вони можуть досягти рівноваги у прийнятті рішень?

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

3 Чи варто підходити до роботи в галузі SA (як було визначено раніше), маючи на увазі, що вони повинні виконувати певні основні правила?

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

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

1.Що повинен донести до столу СА?

"Чи повинні вони входити з менталітетом" встановлення закону "... Або вони повинні вказати початковий напрямок і стратегію, а потім відкласти назад і стрибати в міру необхідності, щоб виправити напрямок корабля?"

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

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

2.Як вони можуть досягти рівноваги у прийнятті рішень?

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

3.Чи слід підходити до роботи в галузі СА (як було визначено раніше), маючи на увазі, що вони повинні виконувати певні основні правила?

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

4.Що все ще врахувати?

• Стосовно вашого другого прикладу: Схоже, команда проекту сформувала жорстко пов'язану залежність від внутрішньої підсистеми. Нещільно пов'язані фасади - не лише для сторонніх кодів. Створення абстракції для цієї підсистеми могло б дозволити простіший перехід до використання цієї бібліотеки, якщо власне рішення не вдалося. Це логічне рішення лише для архітектора програмного забезпечення, але, будучи формою менеджера проектів із занепокоєнням висловів команди, воно повинно було вдвічі бути таким очевидним рішенням.
• Стосовно вашого третього прикладу: Непогано мати відому архітектуру чи процес для виробництва програмного забезпечення (хоча, правда, ви сказали "всі проекти"). Це дотримується того, що працює. З огляду на це, мають бути можливості, де можна спробувати нові методи, щоб побачити, чи приносять вони додаткову цінність. Ідеальне місце - це лише програмне забезпечення для домашнього використання або проекти менших масштабів, де можна використовувати ці технології. Майте на увазі, що навантаження також є на розробниках, щоб забезпечити досліджувані та переконливі демонстрації / аргументи для впровадження технологій. І від SA не можна очікувати, що знає кожен конкуруючий ORM та його сильні та слабкі сторони порівняно з іншими.