Là một kiến ​​trúc sư phần mềm, tôi có nên tập trung nhiều vào việc phân tích các bản ghi và sửa các lỗi khác không?

Kể từ khi tốt nghiệp (cuối năm 2005), tôi đã làm việc cho cùng một công ty với tư cách là một kỹ sư phần mềm c ​​++. Một năm trước tôi đã được thăng chức như một kiến ​​trúc sư phần mềm nhưng tôi thấy mình ngày càng tham gia nhiều hơn vào trình độ chuyên môn và sửa lỗi, hỗ trợ cấp 2.

50% thời gian của tôi dành cho Notepad ++ để phân tích nhật ký phần mềm và cố gắng tìm ra điều gì sai. 30% sửa các lỗi khác và phần còn lại (nếu có) xem xét mã spaghetti của nhà phát triển.

Tôi bắt đầu ghét sản phẩm này và nghĩ về một chiến lược rút lui khỏi công ty này.

Bạn nghĩ tôi có thể làm gì trong tình huống này? Bạn có kiến ​​trúc sư phần mềm khác vẫn sửa lỗi trong mã không?

Hầu hết mọi người thường đồng ý rằng Kiến trúc sư phần mềm nên chủ yếu tham gia vào thiết kế cấp cao, thiết lập các tiêu chuẩn, chọn công cụ hoặc khung, đánh giá sản phẩm, triển khai các nguyên mẫu và Proof Of Conception, và đào tạo và tư vấn cho các nhà phát triển

Tuy nhiên, thực tế là tiêu đề thường có thể là một cuộc hẹn chính trị cho một nhà phát triển, một danh hiệu đặc biệt được trao cho các nhà phát triển dự án, hoặc thậm chí đơn giản như một cách giải quyết quản lý nhân sự để thuê một nhà phát triển cần thiết với mức lương hoặc tỷ lệ Quản lý nhân sự hoặc cấp trên sẽ không thể chấp nhận được danh hiệu Nhà phát triển phần mềm hoặc Kỹ sư phần mềm.

Nói cách khác, tiêu đề chủ yếu là vô nghĩa.

Bài viết Wikipedia định nghĩa kiến trúc sư phần mềm là:

một lập trình viên máy tính người làm cho sự lựa chọn cao cấp thiết kế và mệnh lệnh tiêu chuẩn kỹ thuật , bao gồm cả phần mềm mã hóa tiêu chuẩn, công cụ, hoặc các nền tảng ...

Đưa ra ở trên, ước tính của bạn "50% thời gian của tôi dành ... phân tích nhật ký phần mềm ... 30% sửa các lỗi khác" khiến bạn bỏ xa những gì kiến ​​trúc sư phần mềm thường làm.

• Tôi sẽ nói ở trên làm cho tiêu đề họ đưa cho bạn về 50+30=80%giả mạo.

Lưu ý rằng mỗi lần, các hoạt động như phân tích nhật ký hoặc sửa lỗi của người khác có thể chiếm một phần hợp pháp thời gian của kiến ​​trúc sư - miễn là chúng phục vụ mục đích chính của vai trò này - đó là lựa chọn thiết kế cấp cao và thiết lập các tiêu chuẩn kỹ thuật. Trên thực tế, đây là trường hợp cho bất kỳ loại hoạt động phát triển / bảo trì / kiểm thử phần mềm nào.

Ví dụ, nếu phân tích nhật ký dẫn bạn đến một cái nhìn sâu sắc về cách làm cho nó dễ dàng hơn - bằng cách cải thiện thiết kế, hoặc công cụ hoặc tiêu chuẩn mã hóa - đây sẽ là nỗ lực hoàn toàn chính đáng cho một kiến ​​trúc sư. Tương tự như vậy, kiến ​​trúc sư có thể hoàn toàn ổn khi xử lý các lỗi cụ thể của họ - miễn là điều này sẽ dẫn đến cải tiến thiết kế / quy trình cụ thể dẫn đến tỷ lệ lỗi thấp hơn, v.v.

_{Nói một cách tích cực hơn, câu hỏi của bạn thể hiện ít nhất một kỹ năng khá quan trọng đối với kiến ​​trúc sư: khả năng phân loại các hoạt động loại khác nhau và theo dõi các nỗ lực dành cho những điều này. Xem xét thêm vào các kỹ năng bổ sung "hộp công cụ" của bạn để tóm tắt các quan sát và ước tính của bạn và truyền đạt rõ ràng những điều này, đặc biệt là lên thang quản lý. :)}

Là một kiến ​​trúc sư phần mềm, tôi có nên tập trung nhiều vào việc phân tích các bản ghi và sửa các lỗi khác không?

Giả sử? có và không. Bạn chịu trách nhiệm về toàn bộ chất lượng sản phẩm và con đường tiến hóa - làm cho nó hoạt động vào ngày mai, nhưng cũng làm cho nó hoạt động vào năm tới.
Điều đó có nghĩa là cho vay một bàn tay giúp đỡ để giải quyết các vấn đề khó khăn? Hoàn toàn - ít nhất là tôi làm. Bạn không thể làm cho sản phẩm hoạt động vào ngày mai nếu khách hàng rời bỏ bạn.
Điều đó có nghĩa là bạn nên dành TẤT CẢ thời gian của mình cho điều đó? Tuyệt đối không. Bạn chịu trách nhiệm về TỔNG SỐ chất lượng và sự phát triển. Dành nhiều thời gian để theo đuổi các vấn đề là phản tác dụng.

Bạn được cho là chủ động:

1. Bắt đầu các kế hoạch giáo dục để những người khác (dev / hỗ trợ) có thể nâng tải. "dạy một người đàn ông câu cá" và tất cả những gì jazz.
2. Phát minh ra các cách và phát triển các công cụ để hỗ trợ phân tích lỗi nhanh hơn và dễ dàng hơn và cách ly nguyên nhân gốc rễ. Nếu bạn thấy điều này nhàm chán, các nhà phát triển khác, có thể kém tài năng hoặc có kinh nghiệm thấy điều này không chỉ nhàm chán, mà còn khó khăn và thậm chí có thể nản chí. Giúp họ khắc phục điều này bằng công nghệ.
3. Bắt đầu một nỗ lực để nâng cao chất lượng sản phẩm - đơn giản hóa, mô đun hóa, tạo khung thử nghiệm - dẫn đầu bằng ví dụ, không phải bằng cách than vãn và đe dọa bỏ thuốc lá.
4. Đảm bảo nhà phát triển biết bạn đang làm gì - mà cả người quản lý của bạn. Một vai trò kiến ​​trúc sư là nhiều hơn về mối quan hệ với những người khác sau đó là về mã hóa và phân tích. Nhiều như bạn có thể ghét điều này, chính trị đóng một chìa khóa ở đây. Đảm bảo rằng đồng nghiệp của bạn nhìn thấy thành quả của bạn giúp dễ dàng thuyết phục họ sau này rằng bạn đúng. Nếu bạn chưa có, hãy quay lại yêu cầu của bạn bằng nghiên cứu và POC.
5. Nếu vẫn thất bại, và chỉ sau khi dành thời gian để cố gắng làm cho mọi thứ tốt hơn, hãy nói chuyện với người quản lý của bạn. Nói rằng các kỹ năng của bạn được sử dụng tốt hơn trong các giai đoạn lập kế hoạch và thiết kế và xem những gì có thể được thực hiện để thay đổi tình hình hiện tại. Sản phẩm của bạn có thể gặp khó khăn và câu trả lời của người quản lý của bạn có thể là "chúng tôi cần bạn cho điều này ngay tại đây, ngay bây giờ". Tôi sẽ nhấn mạnh vào một kế hoạch dài hạn mặc dù - chúng ta sẽ thay đổi tình hình hiện tại như thế nào.

Tôi thấy vai trò của một kiến ​​trúc sư là một đặc quyền. Bạn có thể gây ảnh hưởng đến sản phẩm theo cách mà không nhiều người khác có thể - người duy nhất có ảnh hưởng về mặt lý thuyết hơn bạn là người quản lý R & D sản phẩm (và có thể là tiếp thị) - nhưng anh ấy rất bận quản lý.

Theo truyền thống, vai trò của Kiến trúc sư phần mềm thường không giúp họ sửa lỗi. Kiến trúc sư phần mềm giúp khắc phục các sự cố thiết kế trong phần mềm, vì vậy, nếu có lỗi, ý bạn là cách cốt lõi mà phần mềm được thiết kế cho phép dễ vỡ hoặc khó mở rộng hơn thì việc SA đề xuất hoặc thiết kế lại các khía cạnh của SA phần mềm để giải quyết vấn đề đó.

Cho những gì bạn nói:

50% thời gian của tôi dành cho Notepad ++ để phân tích nhật ký phần mềm và cố gắng tìm ra điều gì sai. 30% sửa các lỗi khác và phần còn lại (nếu có) xem xét mã spaghetti của nhà phát triển.

Đó không phải là vai trò của một SA thực sự và thay vào đó là nhiều hơn những gì tôi sẽ có các lập trình viên cấp 1 và nhà phát triển cấp 2 của chúng tôi bắt đầu cùng với một nhà phát triển cao cấp. Tôi nói điều đó đặc biệt bởi vì tôi thấy nó thực sự giúp các nhà phát triển mới trong công ty chúng tôi tham gia vào sản phẩm và mã bằng cách làm việc ở cấp độ đó về các vấn đề về chất lượng mã. Bạn có phải là một SA mới trong công ty của bạn và họ đang yêu cầu bạn thực hiện công việc này để vào hệ thống? Nếu vậy thì có lẽ đó là OK trong một thời gian ngắn. Nếu đây là công việc hàng ngày của bạn và đã được hơn một năm, thì có lẽ đã đến lúc tìm kiếm một vai trò khác.

Tôi hiểu sự thất vọng của bạn, nhưng hiểu nếu bạn đã viết mã hoặc là người cuối cùng chạm vào nó, thời gian rất ngắn và họ có thể tiếp cận bạn, nhiều người quản lý sẽ tìm đến bạn để sửa nó, bất kể tiêu đề của bạn là gì.

Hình dung rằng bạn vẫn còn bạn bè trong nhóm phát triển đang gặp khủng hoảng, bạn sẽ giúp đỡ. Vấn đề là khi họ, và quan trọng hơn là quản lý của họ quen với việc bạn giúp đỡ, họ tiếp tục quay lại. Như câu nói "không có hành động tốt nào không bị trừng phạt. Nếu họ có thể tin tưởng vào bạn để khắc phục các vấn đề, bất kể tiêu đề của bạn là gì, bạn chỉ là một nhà phát triển khác và họ có thể sử dụng người khác.

Đó là một vấn đề khó giải quyết, nhưng lời khuyên của tôi là:

1. Yêu cầu số phí cho dự án thời gian dự án kiến ​​trúc sư không phải phần mềm này. Tôi thấy các nhà quản lý dự án không muốn hỏi về thời gian của bạn, nếu họ phải chịu trách nhiệm cho việc đó.

2. Nói với người quản lý của bạn về thời gian bị mất và các nhóm hoặc dự án. Người quản lý của bạn có thể bảo bạn đừng giúp đỡ họ, và tập trung vào các dự án của anh ấy. Nếu vậy, sau đó nhóm khác đến và yêu cầu giúp đỡ, bạn nói với họ rằng ông chủ của bạn nói không quá.

3. Sắp xếp công việc của bạn, giữ cho các ưu tiên của bạn rõ ràng và không phản ứng nhanh với bên ngoài các dự án kiến ​​trúc của bạn.

4. Hành động như một kiến ​​trúc sư, khiến đồng nghiệp của bạn thấy bạn là một kiến ​​trúc sư, không phải là nhà phát triển giống như bạn trong suốt những năm qua. Bạn đã phá vỡ thói quen coi bạn là nhà phát triển.

Chúc may mắn.

Không, bạn ở đây để quản lý bức tranh lớn.

Bạn có một vấn đề về quản lý: sửa lỗi và cải thiện chất lượng mã là công việc của các nhà phát triển, với tư cách là một kiến ​​trúc sư, bạn nên ban hành các hướng dẫn và kiến ​​trúc thực tế (UML hoặc bất cứ điều gì làm nổi thuyền của bạn), sau đó đưa ra các đánh giá mã thường xuyên để đảm bảo các hướng dẫn này được tuân thủ chính xác .

Tuy nhiên, bạn có thể triển khai và sửa các lỗi trên kiến ​​trúc cốt lõi.

Ví dụ: bạn sẽ làm việc trên PRISM, MEF, v.v. trong dự án WPF / C #, nhưng bạn sẽ không làm việc trên XAML để hiển thị màn hình giật gân.

Bạn sẽ làm việc trên thiết kế DB nhưng bạn sẽ không viết các thủ tục được lưu trữ cho các hoạt động CRUD.

Vân vân.

Một phần của câu trả lời sẽ là tìm một kỹ sư sẵn sàng đảm nhận tải trọng này.

Tất nhiên, lý do đây là một vấn đề là bạn thấy công việc này không mong muốn, điều này không gửi thông điệp rằng nó hấp dẫn với các kỹ sư khác, vì vậy họ cũng không muốn nhận nó.

Tôi thấy hai khả năng.

1. Bạn đã được trao vị trí của kiến ​​trúc sư để bạn có thể làm việc trên các mục hình ảnh lớn hơn.
   Trong trường hợp này, bạn nên đề cập với ban quản lý rằng bạn không thể làm việc với các mục hình ảnh lớn hơn này vì không ai đã từng bước đảm nhận vai trò hỗ trợ cấp thấp hơn. Đó là vấn đề của họ để giải quyết.

2. Tiêu đề chủ yếu là nghi lễ - một khúc xương ném cho bạn để giữ bạn xung quanh.

Trong trường hợp này, quản lý có thể không quan tâm khủng khiếp đến việc giảm tải hỗ trợ của bạn.

-

Một điều chắc chắn sẽ không hữu ích cho mục tiêu của bạn là áp dụng thái độ khinh miệt đối với các nhà phát triển và kỹ sư khác mà tôi thấy bị rò rỉ trong câu hỏi của bạn. Bạn muốn những người này bước lên và tự tin xử lý những vấn đề này để bạn không phải (có thể mắc một số sai lầm trên đường đi). Nếu họ biết rằng bạn sẽ chỉ giải quyết vấn đề của họ và sửa nó cho họ sau đó, có lẽ họ sẽ không bao giờ bước lên.

50% thời gian của tôi dành cho Notepad ++ để phân tích nhật ký phần mềm và cố gắng tìm ra điều gì sai. 30% sửa các lỗi khác và phần còn lại (nếu có) xem xét mã spaghetti của nhà phát triển.

Đây chắc chắn là một loại công việc mà bạn KHÔNG phải làm, cho vai trò này. Theo kinh nghiệm / quan sát của tôi, kiến trúc sư phải tham gia vào thiết kế ứng dụng, cải tiến, làm rõ yêu cầu kỹ thuật và các vấn đề hiệu suất tiềm năng (không kiểm tra nhật ký hàng ngày, mà chủ yếu là phân tích các vấn đề / lỗi nghiêm trọng) cần được giải quyết hoặc tránh.

Nói cách khác, quan điểm số 1 của tôi là - các kiến ​​trúc sư là những nhà thiết kế và tích hợp hệ thống cấp cao với kinh nghiệm thực tiễn về cách thức hoạt động bên trong của công nghệ / ứng dụng và cần được sử dụng.

Nếu bạn có cơ hội để gán và quản lý chất lượng mã thì kỹ năng quản lý công việc của bạn cần được cải thiện. Vì vậy, lập kế hoạch công việc nên là ưu tiên của bạn trong cách tiếp cận "cách thực hiện công việc".

Điểm # 2 : nếu bạn là một trong số ít nhà phát triển trên (các) ứng dụng này - thì tiêu đề này chỉ là một loại men đường khác do ban quản lý công ty giữ cho bạn trong vai trò "sửa chữa" đó với một tiêu đề mới lạ mắt .

Vai trò của Kiến trúc sư phần mềm nhiều hơn những gì bạn đang làm trong công ty hiện tại. Ông chịu trách nhiệm xác định các tiêu chuẩn thiết kế phần mềm, thiết kế mức cao, tiêu chuẩn cho mã hóa, v.v. và sửa lỗi có thể chỉ được coi là một phần nhỏ trong số đó nghĩ rằng thực tế không phải vậy. Nhưng như bạn đã nói, bạn đang làm việc trên một sản phẩm, điều đó có nghĩa là, là một kiến ​​trúc sư phần mềm, sự kỳ vọng của bạn về độ tin cậy của sản phẩm sẽ khá cao và trong trường hợp như vậy, sự tham gia của bạn vào những điều đó sẽ không chỉ giúp đỡ sản phẩm mà còn cho công ty, vì bạn khá có kinh nghiệm trong đó. Nhưng bạn cũng nên được cung cấp một số tiếp xúc với phát triển tính năng mới và các nhiệm vụ mới, điều đó sẽ thể hiện sự quan tâm của bạn đối với tổ chức hiện tại của bạn.

Là một kiến ​​trúc sư phần mềm, tôi có nên tập trung nhiều vào việc phân tích các bản ghi và sửa các lỗi khác không?

Trong một vấn đề nói, "Có".

Đây là cách tôi đủ điều kiện trả lời:

1. Theo mặc định, bạn nên để các nhà phát triển phần mềm phân tích nhật ký và sửa lỗi.
2. Tuy nhiên ... Bạn phải nhận thức được các lỗi phát sinh mất dữ liệu, yêu cầu khôi phục cơ sở dữ liệu khó khăn, mất nhiều thời gian để các nhà phát triển giải quyết hoặc yêu cầu một lời xin lỗi của khách hàng.
   1. Theo quy định, các báo cáo trực tiếp của bạn sẽ cho bạn biết về các khiếm khuyết đó.
   2. Bạn nên tạo một văn hóa trong đó các báo cáo trực tiếp của bạn cảm thấy được trao quyền để nói với bạn về những khiếm khuyết như vậy, nhưng không bắt buộc phải nói với bạn về những điều tầm thường.

Thêm về # 2:

1. Những loại khiếm khuyết nói chung ngụ ý một lỗi kiến ​​trúc. Khi họ làm, bạn phải hiểu bản chất chính xác của khiếm khuyết và kiến ​​trúc sư sửa chữa.
   1. Vì vậy, bằng cách mở rộng, bạn phải sẵn sàng, sẵn sàng và có thể sàng lọc nhật ký và sửa lỗi của người khác (ngay cả khi bạn không trực tiếp cam kết mã vào kho lưu trữ mã nguồn).

Câu trả lời có lẽ là không. Tại sao bạn dành quá nhiều thời gian để gỡ lỗi và hỗ trợ các vấn đề? Có ai đó giao việc đó cho bạn không?

Có vẻ như bạn cần phải làm rõ những gì bạn nên làm. Bạn có thể cần sửa lỗi; đó có lẽ không nên là phần lớn thời gian của bạn.