Làm thế nào tốt nhất để liên quan đến nhà phát triển cơ sở trong việc thiết kế một ứng dụng từ đầu? [đóng cửa]

Chúng tôi là một nhóm gồm 3 nhà phát triển (2 nhà phát triển có kinh nghiệm và một thiếu niên).

Chúng tôi chỉ bắt đầu một dự án hoàn toàn mới. Chúng tôi đã thiết kế ứng dụng, tập trung nỗ lực vào việc chọn kiến ​​trúc phù hợp và bây giờ chúng tôi đang đặt những dòng mã đầu tiên. Chúng tôi đang viết cốt lõi của nó, những gì sẽ là nền tảng của toàn bộ ứng dụng.

Đây cũng không phải là ứng dụng dễ dàng. Yêu cầu hiệu suất cứng, phân phối ồ ạt, mô hình thực thể phức tạp, v.v.

Tất cả chúng ta đều ra khỏi vùng thoải mái của mình, đặc biệt là đàn em. Anh ta không có kinh nghiệm để tạo ra một thiết kế tốt. Mặc dù đó không phải là vấn đề vì tôi và các nhà phát triển khác có mặt để giúp đỡ và cả hai chúng tôi đều tin tưởng vào việc cố vấn và xây dựng đội ngũ, nhưng ... chúng tôi không biết chính xác cách tốt nhất để làm điều đó là gì để anh ấy có được một trải nghiệm thú vị và học được số lượng kỹ năng tối đa.

Cả hai chúng tôi đều nhận ra rằng chúng tôi không có đàn em trong các dự án mới, chỉ trên những dự án hiện có, nơi dễ dàng hơn với đàn em vì anh ấy có toàn bộ cơ sở mã để học hỏi và truyền cảm hứng. Nhưng đối với ứng dụng này, chúng tôi gần như không có mã. Chúng tôi chỉ mới bắt đầu.

Chúng tôi đã suy nghĩ theo một vài cách tiếp cận:

• Để anh ta tự mình thử một vài ngày sau đó can thiệp và cấu trúc lại mã cùng với anh ta, điều khiển anh ta đi đúng hướng sau đó lặp lại => Có thể không phải là một kinh nghiệm thú vị cho anh ta vì chúng tôi sẽ chỉ ra lỗi của anh ta trên mỗi người tái cấu trúc ;
• bắt anh ta lập trình với một trong số chúng tôi => anh ta có thể trở thành "người ngoài cuộc" và đồng ý với mọi thứ chúng tôi làm, mà không thực sự học được nhiều hoặc tiêu hóa nhiều thông tin;
• để chúng tôi xây dựng bộ xương của mỗi mô-đun, với một thiết kế chắc chắn và sau đó đưa mô-đun cho anh ấy để thêm các phần còn thiếu => có thể không vui khi nhận sau chúng tôi và có nguy cơ anh ấy chỉ chú ý đến việc lấp đầy các khoảng trống và không cho toàn bộ thiết kế.

Làm thế nào chúng ta có thể lôi kéo anh ta vào thiết kế để anh ta không cảm thấy bị bỏ lại bên ngoài nó và để anh ta học hỏi được nhiều kinh nghiệm và có đủ tự tin để tự mình thử nó?

Tôi đề nghị các hướng dẫn sau:

• Thu hút nhà phát triển cơ sở trong các cuộc họp thiết kế của bạn và thu hút đầu vào của anh ấy. Điều này sẽ khiến anh ấy suy nghĩ về bức tranh lớn, ngay cả khi anh ấy chưa sẵn sàng tự mình thực hiện thiết kế cấp cao.
• Cố gắng cô lập và xác định rõ một mô-đun của ứng dụng để gán cho nhà phát triển cơ sở. Mô tả bằng văn bản các đầu vào / đầu ra và các yêu cầu khác của mô-đun là gì. Tránh chỉ định cho anh ta một mô-đun không thể dễ dàng kiểm tra hoặc chỉ có thể được kiểm tra khi được tích hợp với các mô-đun chưa được viết khác.
• Có lẽ nhà phát triển cơ sở có thể giúp theo những cách khác ngoài mã hóa ứng dụng cốt lõi. Ví dụ, anh ta có thể viết mã kiểm tra. Khác xa với công việc mang tính chất đàn ông, viết kịch bản thử nghiệm tốt đóng góp giá trị cho dự án và cũng giúp nhà phát triển cơ sở hiểu biết vững chắc về dự án.

Tôi nghĩ nó phụ thuộc vào lĩnh vực mà bạn muốn nhà phát triển cơ sở đó cải thiện. Khi tôi còn (rất) thiếu niên, họ thường đưa cho tôi API mà tôi cần xây dựng một thứ hạn chế cụ thể, chẳng hạn như:

• Hàm này cho N số lượng nhân từ bảng Nhân sự
• chức năng này cung cấp số liệu thống kê nhân sự cho id của nhân viên

->

Nhiệm vụ: xây dựng một trang với danh sách các nhân vật hiển thị số liệu thống kê của anh ấy / cô ấy khi nhấp vào hồ sơ nhân sự. Đây là một trang mẫu đơn giản được xây dựng trước trong dự án.

Khía cạnh quan trọng nhất của nhiệm vụ nhất định là có thể giải quyết được chỉ bằng tài nguyên đã cho đó và không yêu cầu bất kỳ thay đổi nào trong chúng.

Cả 3 cách đều tốt với tôi. Trên thực tế, việc thử 10 cách nhanh nhẹn khác nhau cùng một lúc sẽ cho bạn kết quả tốt, ít nhất bạn sẽ biết cách nào hoạt động và cách nào không (cách nào sẽ hiệu quả nhất phụ thuộc rất nhiều vào tính cách của người chơi).

Vấn đề lập trình cặp sẽ không xảy ra nếu bạn tuân thủ quy trình với việc gõ / suy nghĩ chuyển đổi cứ sau 10 phút (hoặc hơn), không ngoại lệ, theo quy trình được mô tả ban đầu bởi Kent Beck (Tôi không nhớ là ở đâu)

Đối với việc liên quan đến những người khác trong thiết kế - điều chúng tôi thấy có ích là nếu trong giai đoạn thiết kế, một số tài liệu thiết kế (với một số mô hình UML) được tạo ra. Những người khác (đàn em của bạn) sau đó có thể chứng minh đọc chúng, xem xét chúng, chơi trò bênh vực của quỷ. Vai trò này của một bên thứ 3 độc lập có thể thực sự rất có lợi, ví dụ như để thử nghiệm khám phá - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditable-testing-ienaries