2008-10-17 77 views
5

中度或大型項目不需要建築師嗎?我曾參與多個涉及開發公司選擇不分配應用程序架構師的項目。要麼軟件是有機構建的,而且很少涉及設計,或者設計責任落在高級開發人員身上。什麼時候項目不需要應用程序架構師?

爲不必相信開發方法使不必要的建築的作用(這種說法可能對敏捷開發製作)從成本考慮一個建築師範圍的動機。一些開源項目按照集體貢獻的原則工作,而不是以建築領導的發展爲基礎。

回答

2

我將不得不在這裏使用一個比喻利用房屋。不久之前(相對而言),人們可以在沒有建築師或架構計劃的情況下建造房屋。他們砍倒了一些木頭,利用學過的技術來切割和飛機板並建造房屋。大教堂,城堡等......他們當然有建築師和工程師。但絕大多數時間,人們使用技能傳遞建設房屋。

這些房子做的工作,但沒有持續多久。他們可能有點泄漏,他們可能很難改善,等等。但是很容易使用水平衡你的基礎,然後添加木材。

現代房屋有基礎設施,以插入,有代碼得到滿足,等等。我們需要我們的住宅設計由建築師創建或批准,他們可以建立之前。建築師確保所有事情都可以遏制,並且房子將會站立並適合居住。


應用程序沒有什麼不同。我們不是生活在一個複雜的結構可以脫離而沒有建築的世界。當然,我可以爲我的圖書館編寫一個數據庫,作爲一項簡單的練習;我也可以爲我的圖書館建立書架,而不需要建築師參與。但是一旦你超越了簡單的結構,你就應該確保有人正在關注更大的局面 - 無論你的結構(房子還是應用程序)要做它需要做的事情,它是否與其他人搭訕,以及是否它符合建設時的規則。

+0

工程師。工程師是管理藍圖的建築規範要求的人員。建築師不這樣做。 – 2008-10-17 14:37:50

4

如果你已經有一個架構/系統模式,將允許你建立你的項目,你會不會需要一個建築師在所有。

我教軟件架構上大學,中央技能我們相信建築師帶來的表是一個系統的,全面的設計工藝,滿足與利益爭奪仔細考慮所有利益相關者的需求。建築師必須擁有大量的技術知識,但開發人員擁有相同的知識(甚至更多)並不罕見。

最關鍵的事情是捕獲質量方案,並知道如何應用設計技術/滿足這些品質的圖案。或者如果必須的話,可以發明一些東西。

行業中的建築重用性很高,通常都是建築師是多餘的。

因爲我這個東西很多說話,我真的可以去和和...

UPDATE: 我還以爲我會整理一些在其他的答案表達的思想。

  • 建築師是一箇中央通信點。
  • 建築師溝通設計 - 好的設計高效地完成設計。
  • 建築師爲產品/項目帶來重要經驗。
  • 更大的建築需要更大的設計,更多的規劃,原型設計等,需要有人來確保「正確的系統是正確的」。與開發人員相反,架構師認爲開發人員是利益相關者,並實施用於處理其期望的非運行時質量(可伸縮性,可維護性,可測試性,可重用性,可配置性(MeTRiCS))的策略。
+0

您是否鼓勵軟件架構師也是編碼人員?您的回答表明架構和編碼雖然相關,但不一定重疊。當然是 – 2008-10-17 14:44:42

+0

。通常需要進行早期原型設計以獲得關鍵場景的感受。雖然,我已經看到高級設計沒有爲更大的項目編程。我會說這取決於規模和複雜性。 – CVertex 2008-10-17 15:51:17

1

定義「要求」。

您絕對可以在沒有中心願景或領導力的情況下構建大型產品。它會花更長的時間,有更多的錯誤,更難以維護,並且需要更多的人工時間才能完成。

根據我的經驗,擁有Application Architect的優點遠遠超過並超過了缺點,而且項目越大,效果越大。

現在有些事情可以減輕這種影響,例如,有關應用程序預期設計的強大而完整的文檔,開發人員忠實地遵循這些文檔,但這只是用文檔代替應用程序架構師,這不是一個真正不同的方法。

敏捷開發可以成功,但它的成功在於擁有一個開發團隊的潤滑油機器,他們每個人都同意程序設計的基本概念,並且足夠舒適,當他們有時指出彼此做出糟糕的決定並糾正彼此的錯誤。

同樣,你並不是真正取代應用程序架構師的角色,而只是將責任分散給一羣人。

簡單的事實是,角色[我]是[/ i]你想要坐的東西。你的座位取決於你,但最有效的方法是讓一個人去做。

0

在我工作的地方,我們有一個大型項目的建築師。如果您喜歡「理智的聲音」,並且架起一座業務分析師風格角色(這是我們相信業界需要的角色)與高級開發人員之間的差距(「這就是它的工作原理」),那麼架構師就是如此。它們提供了軟件應該如何開發的一致視圖 - 如果您願意,可以提供更大的圖片。

在我看來,開發人員四處移動 - 特別是好的 - 並且獲得項目的一致性是關鍵。建築師專注於項目領域(記住大型項目),不要四處走動,因此他們對將要實現的目標以及應該如何實現目標有了很好的理解。

它們還提供了一個「平滑曲線」,用於根據不斷變化的業務需求獲得的觸發器情況以及開發人員改變已烘焙過程的自然阻力。

即使是開源項目,我也會稱之爲架構師 - 項目中的中心人員通常都會看到正在構建的內容以及應該如何構建。合作者正在提供想法和推動界限,但如果不合適,有人會否決一項改變。

0

這取決於你的意思是「建築師」。如果你的意思是CVertex的意思,那麼的確如此,這是正確的。如果你的意思是「一個不願意編寫代碼但很喜歡UML並親自管理背後的人」,那麼主要的風險是該項目將工作,而不是由管理層支持,而不是相反。

*根據我的經驗,很多這些無代碼的人的體重比我更多。雖然我看到很多瘦的程序員。

0

當只涉及少量維護時,不需要任何架構修改或分析。

0

我的經驗是,有時候建築師不會被稱爲那個。通常有人或某個組織負責代碼的整體設計。我曾經是技術領導,團隊領導或項目負責人。它也傾向於成爲一名開發者,負責指導大規模設計。也許我只是在較小的開發商店工作過,但我從來沒有見過讓某個人完成架構工作,在任何一個項目中都沒有足夠的工作量!

相關問題