Người quản lý của tôi gần đây đã thăng chức cho tôi thành "nhà thiết kế phần mềm". Tôi không biết rằng danh hiệu này tồn tại. Theo như tôi biết thì SA tạo ra thiết kế mã mức cao và làm sơ đồ.

Tôi có một thời gian khó hiểu những gì tôi nên làm thiết kế mã cấp cao. Theo người quản lý của tôi, tôi nên thiết kế tất cả các lớp và tất cả các phương thức bên trong các lớp đó. Đó là, tôi sẽ thiết kế toàn bộ cấu trúc mã và để nhóm của tôi thực hiện chức năng của từng chức năng hoặc lớp. Ví dụ, trong một hệ thống CRUD, tôi sẽ có thể lập kế hoạch nên sử dụng chức năng nào hoặc các lớp nào sẽ được tạo.

Với kinh nghiệm thiết kế phần mềm của tôi, tôi thấy điều này cực kỳ quan trọng để làm. Là một nhà phát triển, tôi luôn tạo các lớp của riêng mình, xác định và thực hiện các chức năng của riêng mình. Tôi chưa bao giờ có kinh nghiệm thiết kế các chức năng cho người khác.

Câu hỏi của tôi là:

• Đây có phải là phổ biến? Đối với một hệ thống rất lớn, cơ sở mã không thay đổi mọi lúc?
• Điều này có thể được thực hiện?

Tôi nhận ra rằng tôi có thể đang hỏi một câu hỏi rõ ràng và ngu ngốc ở đây, nhưng tôi vẫn luôn là một nhà phát triển thường xuyên cho đến bây giờ và vì vậy không có kinh nghiệm trong việc thiết kế toàn bộ hệ thống.

Ghi chú sơ bộ về tiêu đề:

• Đôi khi, những gì bạn thực sự không phù hợp với tất cả các tiêu đề chính thức của bạn. Một ví dụ, cách đây nhiều năm, tôi đã được thuê làm lập trình viên phân tích-nhà phân tích của bộ phận R & D trong bộ phận R & D tuy nhiên, không ai thuê phân tích, lập trình, nghiên cứu hay phát triển. Những gì tôi (và những người khác) thực sự đã làm là mã hóa. Một con khỉ có thể làm một nửa những thứ tôi đã làm. Bất kỳ sinh viên đại học có thể làm nửa kia.

• Thông thường, tiêu đề không quan trọng. Ở một số công ty, bạn có thể sẽ thực hiện rất nhiều nhiệm vụ khác nhau và đa dạng, và đơn giản là không có tiêu đề nào mô tả tất cả điều đó. Trong một công ty, tôi đã thực hiện các nhiệm vụ của một kiến ​​trúc sư, một trưởng nhóm, một người quản lý, một anh chàng UX, một lập trình viên và một chuyên gia về năng suất và tôi đảm bảo hai đội giao tiếp với nhau một cách chính xác. Không có tiêu đề duy nhất cho điều đó.

• Cuối cùng, tiêu đề có thể có ý nghĩa khác nhau trong các công ty khác nhau, hoặc những người đặt tiêu đề ở vị trí đầu tiên không có ý tưởng nhỏ nhất về ý nghĩa thực sự của tiêu đề, nếu có. Trong một số trường hợp, chỉ có tiêu đề thời trang và buzzwords. Bạn không cần một quản trị viên hệ thống, đó là kiểu cũ. Bạn cần một chuyên gia DevOps. Bạn không nói về kinh doanh thông minh hoặc khai thác dữ liệu khi bạn cố gắng thuê ai đó: bạn nói về Dữ liệu lớn!

Vì vậy, hãy quên đi các tiêu đề, và tập trung vào chính xác những gì bạn được yêu cầu làm. May mắn thay, câu hỏi của bạn làm chính xác điều đó.

Đây có phải là phổ biến? Đối với một hệ thống rất lớn, cơ sở mã không thay đổi mọi lúc?

Tôi đã không nhìn thấy nó, và tôi không tin rằng nó có thể bền vững.

Điều này có thể được thực hiện?

Có, nhưng với chi phí của những người bình thường rời khỏi đội.

Điều mà người quản lý của bạn có thể nghĩ đến là bạn thực hiện thiết kế và trình bày nó dưới dạng sơ đồ UML. Đó là lỗi thời, nhưng ai quan tâm? Thực tế là khá phổ biến ở một số công ty, và vẫn hoạt động tốt ở những người khác. Nó có thể là một cách tiếp cận phù hợp nếu bạn rất khéo léo, nhưng tất cả các thành viên khác trong nhóm của bạn đều là những lập trình viên mới bắt đầu: họ chỉ đơn giản là không có đủ kinh nghiệm để tự thiết kế phù hợp và bạn ở vị trí rất tốt để giúp đỡ họ

Nếu tôi là bạn, tôi sẽ bắt đầu bằng cách nói chuyện với người quản lý của bạn, để xác định xem đó có thực sự là điều mà anh ấy có trong đầu không. Nếu có, chơi trò chơi và thử phương pháp này trong một hoặc hai tuần . Điều gì có thể xảy ra?

Hoặc bạn sẽ khám phá ra rằng phương pháp này hoạt động tốt cho nhóm của bạn, trong trường hợp đó, cảm ơn người quản lý của bạn vì sự sáng suốt của anh ấy, hoặc cách tiếp cận sẽ không hiệu quả.

Trong trường hợp này, trước tiên hãy nói chuyện với nhóm của bạn, để xác định tất cả cùng nhau tại sao nó không hoạt động và phải làm gì để cải thiện quy trình (nói cách khác, hãy thực hiện hồi cứu). Sau đó, hoặc thực hiện các thay đổi cho quy trình nếu bạn đang ở vị trí để thực hiện hoặc đến thăm người quản lý của bạn và thảo luận với anh ấy.

Sau đó lặp lại. Cứ hai tuần một lần (hoặc những gì có vẻ phù hợp trong bối cảnh của bạn).

Lý tưởng nhất, Kiến trúc sư phần mềm là một thuật ngữ khác của Kỹ sư phần mềm cao cấp , có thể với một số trách nhiệm bổ sung hoặc như một cách để cung cấp một số nhận thức chung về người đó rằng họ là điểm tiếp xúc chính thức về các vấn đề kỹ thuật với các hệ thống mà họ làm việc với, hoặc các thành viên ít quen thuộc hơn trong nhóm phát triển có thể dựa vào họ khi họ không biết tại sao một số phần của hệ thống được thiết kế theo một cách cụ thể. hoặc đang vật lộn với một vấn đề khi họ không thể tìm ra giải pháp tốt / chấp nhận được cho một vấn đề.

Theo tôi, Kiến trúc sư phần mềm không nên là người làm việc trong một 'tháp ngà' tục ngữ tạo ra các thiết kế hoặc đưa ra quyết định đơn phương cho các nhà phát triển khác; Các quyết định thiết kế vẫn phải được điều khiển bởi những người tích cực tham gia viết và duy trì mã, và các nhóm phát triển phải có trách nhiệm tập thể, với các nhà phát triển cá nhân chịu trách nhiệm về chất lượng mã của chính họ, để hiểu thiết kế của hệ thống và không đưa ra bất kỳ thay đổi nào "phá vỡ" kiến ​​trúc hoặc đưa ra mức nợ kỹ thuật không thể chấp nhận được.

Mặc dù đôi khi có thể có giá trị để nắm bắt thiết kế cấp cao của hệ thống như một phương tiện giúp nhóm phần mềm truyền đạt ý tưởng và chia sẻ kiến ​​thức (đặc biệt cho người mới và nhà phát triển thiếu kinh nghiệm), hoạt động chính của thiết kế là tự viết mã (bao gồm các bài kiểm tra tự động); Sẽ rất hợp lý khi Kiến trúc sư phần mềm nhận 'quyền sở hữu' tài liệu thiết kế, mặc dù điều đó không giống với việc họ là những người viết nó; hơn nữa họ đảm bảo nhóm tạo ra tài liệu cần thiết và đầy đủ, và có sẵn để xem xét nó cho chính xác.

Đối với tất cả các mục đích thực tế, có rất ít hoặc không có giá trị nào khi cố gắng tách biệt vai trò của thiết kế phần mềm khỏi sự phát triển vì về cơ bản chúng giống nhau - thực tế thực tế thường khá có hại vì nó có xu hướng dẫn đến tâm lý theo đó các nhà phát triển được coi là "khỉ mã" dây chuyền sản xuất bị cấm tự suy nghĩ.

Theo mô tả của bạn, có vẻ như người quản lý của bạn muốn bạn đảm nhận vị trí lãnh đạo và không biết cách nói rõ điều này

Anh ấy thăng chức cho bạn và muốn bạn thiết kế phần mềm và phân chia nhiệm vụ. Sự nhầm lẫn của anh ấy về cách phát âm là tự nhiên. Anh ấy đang đặt bạn vào vị trí lãnh đạo có thể dễ bị nhầm lẫn với vai trò là người quản lý.

Các nhóm phát triển truyền thống có một người quản lý duy nhất được phân chia giữa các hoạt động bên ngoài (tìm kiếm tài trợ, chính trị, tài năng săn đầu người, bán ý tưởng và sản phẩm, v.v.) và các hoạt động nội bộ (điều phối sự phát triển). Nhưng hoạt động này là xung đột và đòi hỏi các bộ kỹ năng khác nhau. Thông thường "người quản lý" là tốt trong các hoạt động bên ngoài và xấu về nội bộ.

Vai trò này có thể được tách ra. Trên thực tế là một trong những đặc điểm chính của Phương pháp Scrum. Các nhóm thành công và hiệu quả mà tôi biết đã tách các vai trò đó. Và hầu hết thậm chí không biết họ đang làm điều đó: một trong những lập trình viên bắt đầu tổ chức nhóm và người quản lý cho phép.

Điều này chỉ hoạt động nếu có sự ràng buộc giữa "người quản lý" và "nhà phát triển chính". Nhiều đội thất bại. Là một trong những nhà phát triển nắm quyền lãnh đạo, người quản lý có thể cảm thấy bị đe dọa hoặc ghen tị. Nhóm có thể mất sự tôn trọng của người quản lý vì anh ta hoặc cô ta luôn ở ngoài và họ không hiểu tầm quan trọng của các hoạt động bên ngoài. Điều quan trọng là phải nhận thức được điều đó và tránh những vấn đề đó.

Cách phân chia nhiệm vụ

Để phân chia các nhiệm vụ bạn không cần phải làm theo ví dụ của anh ấy.

Điều quan trọng là lạm dụng bằng chứng về các khái niệm, các nguyên mẫu khám phá chức năng để làm cho tiến trình của nhóm trở nên rõ ràng hơn với anh ta. Điều quan trọng là anh ấy cảm thấy rằng sự phát triển đang tiến triển.

Một cách để đạt được điều đó là tạo ra một nguyên mẫu chỉ có sql. Tạo các bảng, điền dữ liệu, tạo các trường hợp thử nghiệm chỉ dành cho sql thực thi các truy vấn mà màn hình chính và thói quen sẽ làm. Khi bạn tự tin rằng mô phỏng là tốt, hãy phân chia công việc giữa các nhà phát triển cơ sở của bạn để xây dựng màn hình và thói quen. Trong khi các nhà phát triển cơ sở của bạn đang làm việc, bạn đang tạo các nguyên mẫu cho chu kỳ phát triển tiếp theo.

Mọi người đều bận rộn, năng suất cao, người quản lý hạnh phúc.

Hãy thử một vài lần chạy nước rút nhưng bạn sẽ làm phiền nghiêm trọng các nhà phát triển mà bạn đang quản lý và họ sẽ lần lượt rên rỉ với bất cứ ai đang lắng nghe.

Tôi sẽ đi với giả định rằng bạn đang thiết lập các quyết định kiến ​​trúc chung (đẩy so với kéo; các mẫu thông báo; nên dịch vụ x là DDD hoặc là CRUD tốt) cho nhóm; sau đó sử dụng quy trình xem xét mã và ghép nối để giữ cho mọi người theo dõi và giúp đỡ họ nếu họ gặp khó khăn.

Nó thực sự không cần phải từ trên xuống, chết bởi UML. Những gì bạn đang tìm kiếm là các lớp ở sai vị trí; logic kinh doanh không phải là nơi bạn mong đợi và như vậy.

Đừng quá khó khăn với đội nếu họ đang học một cái gì đó đã biết, trước tiên hãy thực hiện bất kỳ nguyên tắc mới nào sau đó dọn sạch mọi thực hành xấu còn sót lại.