Bạn nên mang gì đến bàn với tư cách là Kiến trúc sư phần mềm? [đóng cửa]

Đã có nhiều câu hỏi với câu trả lời hay về vai trò của Kiến trúc sư phần mềm (SA) trên StackOverflow và Lập trình viên SE . Tôi đang cố gắng hỏi một câu hỏi tập trung hơn một chút so với những câu hỏi. Định nghĩa về SA rất rộng nên vì mục đích của câu hỏi này, hãy định nghĩa SA như sau:

Kiến trúc sư phần mềm hướng dẫn thiết kế tổng thể của dự án, tham gia vào các nỗ lực mã hóa, tiến hành đánh giá mã và chọn các công nghệ sẽ được sử dụng.

Nói cách khác, tôi không nói về phần còn lại của người quản lý và áo vest ở các loại mào (các từ có vần điệu hơn nữa được tách ra) của các loại SA. Nếu tôi theo đuổi bất kỳ loại vị trí SA nào, tôi không muốn tránh xa tiền mã hóa. Tôi có thể hy sinh một chút thời gian để giao tiếp với khách hàng và Chuyên viên phân tích nghiệp vụ, v.v., nhưng tôi vẫn tham gia về mặt kỹ thuật và tôi không nhận thức được những gì đang diễn ra trong các cuộc họp.

Với những điểm này trong tâm trí, một SA nên mang gì đến bàn? Họ có nên đưa ra một tâm lý "đặt ra luật" (có thể nói) và thực thi việc sử dụng một số công cụ nhất định để phù hợp với "cách của họ", tức là hướng dẫn mã hóa, kiểm soát nguồn, mẫu, tài liệu UML, v.v.? Hay họ nên xác định phương hướng và chiến lược ban đầu sau đó được đặt lại và nhảy vào khi cần thiết để điều chỉnh hướng của con tàu?

Tùy thuộc vào tổ chức này có thể không hoạt động. Một SA dựa vào TFS để thực thi mọi thứ có thể đấu tranh để thực hiện kế hoạch của họ tại một chủ nhân chỉ sử dụng StarTeam. Tương tự, một SA cần phải linh hoạt tùy thuộc vào giai đoạn của dự án. Nếu đó là một dự án mới, họ có nhiều sự lựa chọn hơn, trong khi họ có thể có ít hơn cho các dự án hiện có.

Dưới đây là một số câu chuyện SA tôi đã trải nghiệm như một cách chia sẻ một số nền tảng với hy vọng rằng câu trả lời cho câu hỏi của tôi cũng có thể làm sáng tỏ những vấn đề này:

• Tôi đã làm việc với một SA, người đã xem xét mã từng dòng mã của nhóm. SA sẽ làm điều này không chỉ cho dự án của chúng tôi mà các dự án khác trong tổ chức (hãy tưởng tượng thời gian dành cho việc này). Lúc đầu, nó rất hữu ích để thực thi các tiêu chuẩn nhất định, nhưng sau đó nó trở nên tê liệt. FxCop là cách SA sẽ tìm ra vấn đề. Đừng hiểu sai ý tôi, đó là một cách hay để dạy các nhà phát triển cơ sở và buộc họ nghĩ về hậu quả của cách tiếp cận đã chọn, nhưng đối với các nhà phát triển cấp cao thì nó được coi là hơi hà khắc.

• Một SA đặc biệt đã chống lại việc sử dụng một thư viện nhất định, cho rằng nó chậm. Điều này buộc chúng tôi phải viết hàng tấn mã để đạt được những điều khác biệt trong khi thư viện khác sẽ giúp chúng tôi tiết kiệm rất nhiều thời gian. Chuyển nhanh đến tháng cuối cùng của dự án và khách hàng đã phàn nàn về hiệu suất. Giải pháp duy nhất là thay đổi chức năng nhất định để sử dụng phương pháp bỏ qua ban đầu mặc dù có cảnh báo sớm từ các nhà phát triển. Vào thời điểm đó, rất nhiều mã đã bị loại bỏ và không thể tái sử dụng, dẫn đến tăng ca và căng thẳng. Đáng buồn thay, các ước tính được sử dụng cho dự án dựa trên cách tiếp cận cũ mà dự án của tôi bị cấm sử dụng vì vậy nó không phải là một chỉ số thích hợp để ước tính. Tôi sẽ nghe Thủ tướng nói "chúng tôi đã làm điều này trước đây",

• SA người sẽ thực thi việc sử dụng các lớp DTO, DO, BO, Service và vv cho tất cả các dự án. Các nhà phát triển mới đã phải học kiến ​​trúc này và SA hướng dẫn sử dụng một cách kiên quyết. Các ngoại lệ đối với hướng dẫn sử dụng đã được thực hiện khi hoàn toàn khó thực hiện theo hướng dẫn. SA đã được căn cứ trong cách tiếp cận của họ. Các lớp cho DTO và tất cả các hoạt động CRUD được tạo thông qua CodeSmith và các lược đồ cơ sở dữ liệu là một quả bóng sáp tương tự khác. Tuy nhiên, đã sử dụng thiết lập này ở mọi nơi, SA không mở ra các công nghệ mới như LINQ to SQL hoặc Entity Framework.

Tôi không sử dụng bài đăng này như một nền tảng để trút giận. Có những khía cạnh tích cực và tiêu cực đối với những trải nghiệm của tôi với những câu chuyện SA được đề cập ở trên. Câu hỏi của tôi sôi lên:

1. Một SA nên mang gì đến bàn?
2. Làm thế nào họ có thể đạt được sự cân bằng trong việc ra quyết định của họ?
3. Có nên tiếp cận một công việc SA (như được xác định trước đó) với tâm lý rằng họ phải thực thi các quy tắc cơ bản nhất định?
4. Bất cứ điều gì khác để xem xét?

Cảm ơn! Tôi chắc chắn rằng các nhiệm vụ công việc này dễ dàng được mở rộng cho những người là nhà phát triển cấp cao hoặc lãnh đạo kỹ thuật, vì vậy hãy thoải mái trả lời với khả năng đó.

Một kiến ​​trúc sư hệ thống nên:

1. Chỉ định kiến ​​trúc cấp cao
2. Tham gia đánh giá mã
3. Phê duyệt công nghệ sử dụng
4. Hỗ trợ các nhà phát triển trong nỗ lực mã hóa của họ
5. Duy trì và theo dõi tiến độ phát triển
6. Sản xuất các tạo phẩm SA, như sơ đồ UML, biểu đồ Gantt và những thứ tương tự.

SA phải biết cách viết mã và nên tham gia vào một số công việc mã hóa, làm ướt tay, có thể nói như vậy. Điều này giữ cho họ liên lạc với cử chỉ của nỗ lực phát triển. Như chú Bob Martin đã từng nói , Kiến trúc sư nên tự mình thực hiện một số mã hóa, để anh ta có thể nhìn thấy nỗi đau mà anh ta đang gây ra cho người khác bằng các thiết kế của mình.

SA nên có lời cuối cùng về tất cả các quyết định về thiết kế, công nghệ và mã hóa. Nhưng, giống như tất cả các nhà quản lý, công việc của SA là dọn đường cho người của anh ta để họ có thể làm việc hiệu quả. Điều đó có nghĩa là, đối với hầu hết các phần, các nhà phát triển phải quyết định, ở cấp độ của họ, cách giải quyết vấn đề. Điều đó có nghĩa là SA giữ các ông chủ tóc nhọn ra khỏi tủ của nhà phát triển. Và nó có nghĩa là SA góp mặt để giúp đỡ, khi cần thiết.

Giống như tất cả mọi người, SA có thể và thực hiện sai lầm. Những người tốt học hỏi từ những sai lầm đó, và trở thành SA tốt hơn.

Tôi chưa bao giờ gặp một Kiến trúc sư hữu ích, chủ yếu vì họ không thực tế.

Đối với tôi, những vấn đề lớn nhất tôi từng thấy là:

• tuân thủ mù quáng để xử lý vì lợi ích của quá trình
• thiên vị mù quáng với công nghệ trước khi biết vấn đề
• tạo ra và thực thi các quy tắc mà không có sự biện minh tốt
• rewrite from scratch tâm lý

"Kiến trúc sư" giỏi nhất mà tôi từng làm việc mang đến bàn:

• Các câu hỏi hướng đến sự hiểu biết tốt hơn về vấn đề và các giải pháp tiềm năng.
• Tùy chọn thiết kế / công nghệ và sự đánh đổi của họ.
• Giải thích rõ ràng và hợp lý cho cả sự lên án và chứng thực của thiết kế và công nghệ.

Vấn đề đối với tôi là "Kiến trúc sư" giỏi nhất mà tôi từng làm việc không có "Kiến trúc sư trong tiêu đề của họ. Họ thường là Kỹ sư phần mềm, những người có căn cứ trong các vấn đề và dự án cụ thể. Họ hiểu rằng trong hầu hết các doanh nghiệp, đó không phải là ' Họ thực hiện để viết lại một cơ sở mã hoạt động từ đầu. Họ đưa ra quyết định thiết kế hoặc cung cấp các tùy chọn và lý do hoặc biện minh của họ. bất cứ điều gì là dejour hoặc quen thuộc. họ sẽ truyền đạt một tầm nhìn gắn kết như thế nào điều nên làm việc và tại sao, NHƯNG quan trọng hơn là họ sẽ vạch ra làm thế nào để đạt được điều đó và chi phí.

1 SA nên mang gì đến bàn?

• Một làn da dày
• Kỹ năng đàm phán tốt
• Một sự hiểu biết tốt về các tầng phần mềm khác nhau (từ độ tốt AJAX cho đến I / O mạng cấp thấp). Bạn không nhất thiết phải là một chuyên gia, nhưng bạn sẽ có những quyết định quan trọng về việc phần mềm nào sẽ được thực thi ở lớp nào.
• Sẵn sàng để có được bàn tay của họ trong mã, các thiết kế giấy trắng chỉ không cắt nó.
• Khuyến khích sự khéo léo của phần mềm - hãy là người cổ vũ để thực hiện mọi thứ đúng cách bất cứ khi nào có thể và là cách tốt nhất đưa ra những hạn chế trong các trường hợp khác. Vì vậy, những thứ như kiểm soát nguồn, TDD, xây dựng và CI, mã hóa DOJO, đánh giá mã, một hệ thống theo dõi vấn đề tốt, v.v.

2 Làm thế nào họ có thể đạt được sự cân bằng trong việc ra quyết định?

• Phần lớn phụ thuộc vào (các) nhóm của bạn và khả năng của họ.
• Môi trường của bạn (ví dụ: bạn có thể bị buộc phải sử dụng sản phẩm của một nhà cung cấp cụ thể)
• Nhìn chung, tốt nhất không nên là một kiến ​​trúc sư tháp ngà, hãy chung tay, là một phần của nhóm - mọi người sẽ hiểu quyết định của bạn theo cách đó.

3 Có nên tiếp cận một công việc SA (như được xác định trước đó) với tâm lý rằng họ phải thực thi các quy tắc cơ bản nhất định?

• Vâng, những thứ như kiểm soát phiên bản và hệ thống xây dựng khá quan trọng và các nhà phát triển cần sử dụng những thứ này. Tuy nhiên, đó là cách tốt nhất để biến chúng thành một phần của giải pháp.

Còn nhiều điều nữa, tôi nghĩ sẽ có một số câu trả lời thực sự hay được đưa ra cho câu hỏi này.

1. SA nên mang theo cái gì?

"Họ có nên đến với tâm lý 'đặt ra luật pháp' ... Hay họ nên chỉ định phương hướng và chiến lược ban đầu sau đó được đặt lại và nhảy vào khi cần thiết để điều chỉnh hướng của con tàu?"

Một sự kết hợp của cả hai tôi sẽ nói. Khi quyết định về công nghệ và quy trình, cởi mở với các ý kiến ​​và đề xuất có thể đưa ra phản hồi / đầu vào có giá trị cho các quyết định và khiến bạn học hỏi từ người khác. Nhóm của bạn (hy vọng) thông minh; tận dụng điều đó Nhưng một khi quyết định (quyết định của bạn) được đưa ra, luật đã được đặt ra. Xác định những người sẽ phàn nàn về bất cứ điều gì không phải là lựa chọn của họ và những người sẽ chọn bất cứ điều gì và không quan tâm - và sau đó bỏ qua họ.

Theo như công nghệ: hoạt động với những gì bạn có, nếu công ty sử dụng StarTeam thì đó là những gì bạn sử dụng. Kết hôn với bất kỳ sản phẩm / công nghệ / quy trình cụ thể nào sẽ không làm gì cho bạn.

2.Làm thế nào họ có thể đạt được sự cân bằng trong việc ra quyết định của họ?

Lắng nghe nhóm và biết khi nào họ đúng và sai là điều quan trọng, và có các đồng phạm để nói với họ rằng họ sai và tuân theo quyết định của bạn. Không lắng nghe sẽ mang lại sự thiếu tôn trọng, cũng như thất bại trong các quyết định của bạn.

3. Có nên tiếp cận một công việc SA (như được xác định trước đó) với tâm lý rằng họ phải thực thi các quy tắc cơ bản nhất định?

Luôn luôn. Nếu không, các tù nhân cuối cùng sẽ chạy tị nạn, công khai hoặc ngụy biện. Tuy nhiên, quyết định về các quy tắc cơ bản đó có thể thông qua nói chuyện với nhóm. Hãy nhớ rằng bất kỳ đội nào có thể không phải lúc nào cũng có cùng các thành viên như hiện tại, do đó, việc nhượng bộ cho một nhóm nhỏ trong số họ có thể cản trở nhóm trong tương lai sau khi họ ra đi. Điều đó bao gồm SA.

4. Bất cứ điều gì khác để xem xét?

• Để tham khảo ví dụ thứ hai của bạn: Có vẻ như nhóm dự án đã hình thành một sự phụ thuộc chặt chẽ vào một hệ thống con trong nhà. Mặt tiền được ghép lỏng lẻo không chỉ dành cho mã của bên thứ ba. Tạo một sự trừu tượng cho hệ thống con đó có thể cho phép chuyển đổi dễ dàng hơn sang sử dụng thư viện đó nếu giải pháp nội bộ thất bại. Đây là một giải pháp hợp lý cho một kiến ​​trúc sư phần mềm, nhưng cũng là một dạng Quản lý dự án với các mối quan tâm biểu hiện nhóm, đáng lẽ nó phải là một giải pháp rõ ràng.
• Liên quan đến ví dụ thứ ba của bạn: Việc kiến ​​trúc hoặc quy trình sản xuất phần mềm được biết đến là một ý tưởng không tồi (mặc dù, phải thừa nhận rằng, bạn đã nói 'tất cả các dự án'). Đây là dính vào những gì làm việc. Như đã nói, cần phải có những cơ hội trong đó các kỹ thuật mới có thể được thử để xem liệu chúng có mang lại giá trị bổ sung hay không. Phần mềm chỉ dành cho nội bộ hoặc các dự án phạm vi nhỏ hơn nơi các công nghệ này có thể được thử là những nơi lý tưởng. Mặc dù vậy, hãy ghi nhớ rằng onus cũng thuộc về nhà phát triển để cung cấp các cuộc biểu tình / lập luận được nghiên cứu và thuyết phục cho việc áp dụng các công nghệ. Và SA không thể biết được mọi ORM cạnh tranh cũng như điểm mạnh và điểm yếu của nó so với các ORM khác.