Nên có một vai trò chính thức (nội bộ hoặc bên ngoài) được gán cho các môi trường dev để kiểm soát sự phức tạp lãng phí?

Vài năm trước, tôi đã làm việc cho một công ty nhỏ đã phát triển các khung công tác nội bộ mà họ dành riêng cho nhà phát triển cao cấp nhất và kiến ​​trúc sư của họ để phát triển một khung MVC tùy chỉnh và ORM từ đầu. Hai điều này là trực giao với sản phẩm cốt lõi của họ. Thật không may, sự hỗ trợ cho cách tiếp cận dựa trên khung này đến từ đầu, và nó đã trì hoãn việc phân phối phần mềm tạo doanh thu - và các khung được sản xuất đáng chú ý là kém hơn các lựa chọn thay thế, làm chậm trễ. Công ty đã đốt tiền mặt nhanh chóng, và cuối cùng, mọi người đều bị cho nghỉ việc.

Một chủ nhân sau này đã mắc một lỗi tương tự - họ có một nhà phát triển có kỹ thuật cao - một người cầu toàn, với nền tảng vững chắc trong các mẫu thiết kế doanh nghiệp để chế tạo quá mức một giải pháp tư vấn cho một trong những khách hàng của họ, cố tình làm mất đi, với hy vọng rằng giải pháp có thể được điều chỉnh và mở rộng cho các khách hàng khác. Các dự án tràn ngập đáng kể. Nhưng không có khách hàng tiềm năng nào bit. Một sai lầm chiến lược mạ vàng có giá trị tài sản nhỏ.

Trong cả hai trường hợp, có một mức độ áp đảo đáng kể. Trong cả hai trường hợp, công ty và quản lý dự án là những người có nền tảng phân tích hoặc phân tích, thay vì nền tảng lập trình. Trong cả hai trường hợp, các kiến ​​trúc sư phần mềm đã xây dựng các giải pháp quá phức tạp để gãi ngứa và tăng cường lý lịch của họ, với một số phức tạp từ quản lý phi kỹ thuật. Trong cả hai trường hợp, các kiến ​​trúc sư không có cổ phần trong việc giảm chi phí (ngoài rủi ro mất việc nếu các công ty phá sản - điều này không có nhiều rủi ro, xem xét khả năng tuyển dụng cao của họ).

Kinh nghiệm của tôi cho thấy rằng đó không phải là một cái bẫy hiếm gặp cho các cửa hàng dev rơi vào.

Có chỗ nào trong các dự án phần mềm cho vai trò đối nghịch kỹ thuật bên trong hoặc bên ngoài chính thức - một "Công cụ khảo sát số lượng" - để sử dụng một phép tương tự tòa nhà - có thể gọi ra, hoặc ngăn chặn lãng phí quá kỹ thuật không? Ai phù hợp nhất để lấp đầy vai trò này?

"Kiểm soát sự phức tạp" là công việc của:

1. Kiến trúc sư, có nhiệm vụ đảm bảo rằng hệ thống và kiến ​​trúc doanh nghiệp phù hợp với các dự án / sản phẩm hiện tại ;

2. Nhà phát triển, có nhiệm vụ tạo ra các thiết kế và mã không chỉ đúng mà còn có thể bảo trì và cũng để xem xét mã của các nhà phát triển khác để đảm bảo rằng họ có thể hiểu được nó; và

3. Nhà phân tích doanh nghiệp / hệ thống hoặc chủ sở hữu sản phẩm, có nhiệm vụ tìm ra những gì doanh nghiệp thực sự cần ngay bây giờ , những gì có thể hoàn thành sau này hoặc những gì có thể không bao giờ thành hiện thực.

"Độ phức tạp" dù sao cũng là một khái niệm trừu tượng và cũng có thể lập luận rằng "giảm độ phức tạp" là mục đích chính của phần mềm ngay từ đầu, do đó, không có ý nghĩa gì khi đề xuất một vai trò dành riêng cho nó - đó là toàn bộ đội nên đã được làm!

Giả sử rằng một cái nhìn khó hiểu về ROI và TCO chứng minh rằng (các) giải pháp thực sự và thực sự quá sức, thì tôi rất tiếc phải nói rằng các kiến ​​trúc sư và nhà phát triển và nhà phân tích đang làm việc trên nó chỉ đơn giản là không rất giỏi trong công việc của họ. Và những người phụ trách khía cạnh đó là những người quản lý hoặc giám đốc điều hành đã thuê họ; có thể họ đã nuôi dưỡng văn hóa kỹ thuật quá mức và có một phần lỗi, hoặc có thể họ vừa nhận được lời khuyên tồi từ nhóm thực hiện.

Tôi sẽ không mạo hiểm đoán xem ai vì tôi (có lẽ) chưa từng làm việc cho công ty của bạn, nhưng tôi chắc chắn rằng bạn có thể tự mình tìm ra điều đó khá dễ dàng chỉ bằng một cuộc trò chuyện trực tiếp với một hoặc một vài nhà quản lý nói.

Ngẫu nhiên, phát triển khung trong nhà không phải lúc nào cũng là điều xấu. Chỉ là những khung đó thường phải dựa trên sự quan sát và hoàn thiện quy trình hiện tại. Các khung hoặc thư viện xuất hiện bằng cách tái cấu trúc mã hiện tại có xu hướng tồn tại lâu dài. Mặt khác, nếu mọi người chỉ cần lao vào và bắt đầu phát triển một khung không có bối cảnh nào cả, thì nó thường trở thành một trách nhiệm pháp lý và nhanh chóng.

Mọi người phải có thể nhận ra sự khác biệt giữa các quy ước (hầu hết các dự án tại một tổ chức sẽ sử dụng cùng một ngăn xếp công nghệ, với một số mã nồi hơi nhất định, nhưng điều đó không có nghĩa là kết hợp tất cả vào một "khung" là tốt ý tưởng) so với trùng lặp (mọi người thực sự giải quyết cùng một vấn đề kinh doanh hoặc kỹ thuật lặp đi lặp lại và sự không nhất quán dẫn đến thiết kế phức tạp và khiếm khuyết nghiêm trọng). Các doanh nghiệp phần mềm có thể và nên nhận ra kịch bản sau và tích cực thực hiện các bước để giảm bớt sự phức tạp. Các khung làm giảm sự phức tạp miễn là chúng không chịu khuất phục trước hiệu ứng nền tảng bên trong .

Có chỗ nào trong các dự án phần mềm cho vai trò đối nghịch kỹ thuật bên trong hoặc bên ngoài chính thức - một "Công cụ khảo sát số lượng" - để sử dụng một phép tương tự tòa nhà - có thể gọi ra, hoặc ngăn chặn lãng phí quá kỹ thuật không? Ai phù hợp nhất để lấp đầy vai trò này?

Không, thường thì không có vị trí như vậy.

Bí quyết là thuê đúng người cho công việc. Những người sẽ không quá kỹ sư, và làm những gì cần thiết.

Điều này có thể được thực hiện bằng cách sử dụng các phương pháp nhanh (như thực hiện các yêu cầu trong các lần lặp hoặc sử dụng TDD hoặc BDD). Nhưng một lần nữa, nếu kiến ​​trúc được thiết kế quá mức, nó sẽ không giúp ích gì.