Giả sử bạn mới bắt đầu làm việc trong một nhóm rất nhỏ trong dự án {hiện tại tương đối nhỏ, mặc dù hy vọng sẽ lớn hơn sau này}. Lưu ý rằng đây là một dự án thực tế dự định sẽ được sử dụng bởi các nhà phát triển khác trong thế giới thực, chứ không phải một dự án học thuật nào đó có nghĩa là bị loại bỏ vào cuối học kỳ.
Tuy nhiên, mã chưa được phát hành cho người khác, vì vậy chưa có quyết định nào được đưa ra.
Phương pháp luận
Một trong hai bạn thích bắt đầu mã hóa và làm cho các mảnh khớp với nhau khi bạn đi trước khi bạn nhất thiết phải có một ý tưởng rõ ràng về cách chính xác tất cả các thành phần sẽ tương tác (thiết kế từ dưới lên). Một trong những bạn thích làm toàn bộ thiết kế trước tiên và tìm hiểu chi tiết về tất cả các thành phần và giao tiếp trước khi mã hóa một giải pháp.
Giả sử rằng bạn đang làm việc trên một hệ thống mới thay vì bắt chước các hệ thống hiện có, và do đó không phải lúc nào cũng rõ ràng thiết kế cuối phải như thế nào. Vì vậy, trong nhóm của bạn, các thành viên khác trong nhóm đôi khi có những ý tưởng khác nhau về những yêu cầu nào thậm chí cần thiết cho sản phẩm cuối cùng, chứ đừng nói đến việc làm thế nào để thiết kế nó.
Khi nhà phát triển từ dưới lên viết một số mã, nhà phát triển từ trên xuống từ chối vì các vấn đề tiềm ẩn trong tương lai được hình dung trong thiết kế mặc dù thực tế là mã có thể giải quyết vấn đề trong tay, tin rằng điều quan trọng hơn là phải thiết kế đúng trước khi thử mã hóa giải pháp cho vấn đề.
Khi nhà phát triển từ trên xuống cố gắng thiết kế đầy đủ và các vấn đề được hình dung trước khi bắt đầu viết mã, nhà phát triển từ dưới lên sẽ từ chối vì nhà phát triển từ dưới lên không nghĩ rằng một số vấn đề sẽ thực sự phát sinh trong thực tế và nghĩ rằng thiết kế có thể cần phải được thay đổi trong tương lai khi các yêu cầu và ràng buộc trở nên rõ ràng hơn.
Vấn đề
Vấn đề mà điều này dẫn đến là nhà phát triển từ dưới lên kết thúc lãng phí thời gian vì nhà phát triển từ trên xuống thường xuyên quyết định giải pháp mà nhà phát triển từ dưới lên đã viết nên bị loại bỏ do lỗi thiết kế, dẫn đến cần phải làm lại -viết mã.
Nhà phát triển từ trên xuống kết thúc lãng phí thời gian vì thay vì song song công việc, nhà phát triển từ trên xuống thường xuyên ngồi xuống để thiết kế chính xác với nhà phát triển từ dưới lên, nối tiếp hai đến điểm thậm chí có thể nhanh hơn cho 1 người làm việc hơn 2.
Cả hai nhà phát triển đều muốn tiếp tục làm việc cùng nhau, nhưng dường như sự kết hợp này thực sự giúp ích cho cả hai trong thực tế.
Mục tiêu
Các mục tiêu chung rõ ràng là để tối đa hóa hiệu quả mã hóa (tức là giảm thiểu lãng phí thời gian) và viết phần mềm hữu ích.
Câu hỏi
Nói một cách đơn giản, làm thế nào để bạn giải quyết vấn đề này và đối phó với tình huống này?
Giải pháp hiệu quả duy nhất tôi có thể nghĩ đến mà không lãng phí thời gian là để mỗi nhà phát triển làm theo phong cách riêng của họ cho thiết kế. Nhưng điều này khó hơn âm thanh khi bạn xem xét mã và thực sự cần phê duyệt các thay đổi của nhau và khi bạn đang cố gắng thiết kế một khung thống nhất cho người khác sử dụng.
Có cách nào tốt hơn?