Vai trò của Kiến trúc sư phần mềm trong quy trình Phát triển dựa trên thử nghiệm là gì?

Theo tôi hiểu, Phát triển dựa trên thử nghiệm là về viết thử nghiệm để xác định các thông số kỹ thuật của chương trình (bạn có thể sửa tôi nếu tôi sai).

Nếu có ai đó chịu trách nhiệm viết các thông số kỹ thuật (bao gồm API công khai) cho phần mềm (hãy gọi anh ta là Kiến trúc sư phần mềm), điều đó có nghĩa là Kiến trúc sư phần mềm phải viết tất cả các bài kiểm tra?

Hoặc Kiến trúc sư phần mềm viết các thông số kỹ thuật, và sau đó bàn giao chúng cho các nhà phát triển để viết các bài kiểm tra chống lại?

Hoặc bạn có cho phép các thông số kỹ thuật phát triển một cách hữu cơ bằng cách cho phép tất cả các nhà phát triển viết bài kiểm tra của riêng họ và quên đi việc có Kiến trúc sư phần mềm không?

architecture tdd

— Robert Harvey
nguồn

Có một số cuộc tranh luận về trên english.se vào những gì bạn có nghĩa là bởi "tăng trưởng hữu cơ" - english.stackexchange.com/questions/17853/... - Bạn muốn xác nhận :)

— JoseK

@Jose: Câu cuối cùng trong OP của tôi có nghĩa là hơi khó nói, vì dường như rõ ràng với tôi rằng một chương trình phải luôn có thông số kỹ thuật chi tiết từ khách hàng. Nhưng khách hàng không luôn biết chính xác những gì họ muốn, đó là lý do tại sao các quy trình phát triển phần mềm lặp lại tồn tại. Xem ở đây để biết thêm thông tin về phép ẩn dụ "phần mềm đang phát triển".

— Robert Harvey

Câu trả lời:

Test-Driven Development là về viết thử nghiệm để xác định các thông số kỹ thuật của chương trình

Bạn không viết các bài kiểm tra để xác định đặc điểm kỹ thuật, mô tả kiểm tra, câu chuyện của người dùng và mô tả tính năng là đặc điểm kỹ thuật, theo nghĩa 'cây chết'.

Để xem xét, quy trình TDD một cách ngắn gọn là:

định nghĩa một dự án về các tính năng
mô tả các bên liên quan, hành vi và mục tiêu của từng tính năng bằng cách sử dụng các câu chuyện của người dùng
chỉ định các quà tặng dự kiến, kích hoạt các sự kiện / điều kiện và hành vi / kết quả liên quan đến câu chuyện của người dùng bằng cách sử dụng các mô tả thử nghiệm [và điều này hoàn thành 'đặc tả']
chọn một bộ tính năng cho mỗi lần lặp; các lần lặp lại nên ngắn gọn [tôi đang bỏ qua các bước lập kế hoạch và ước tính cho ngắn gọn]
- mã hóa thử nghiệm cho một tính năng (nó sẽ thất bại, nhưng bạn phải đưa ra quyết định API để mã hóa thử nghiệm)
- thực hiện đủ các tính năng để thử nghiệm vượt qua
- cấu trúc lại mã nếu cần thiết
- lặp lại với thử nghiệm tiếp theo cho đến khi tính năng được hoàn thành
- lặp lại với tính năng tiếp theo cho đến khi lặp lại hoàn thành
lặp lại với lần lặp tiếp theo cho đến khi dự án hoàn thành

bao nhiêu thiết kế, kiến trúc, tài liệu hỗ trợ, et al bạn chọn làm không phải là một phần của TDD. Có một số 'thực tiễn tốt nhất' thực tế mà bạn có thể đọc, nhưng hãy nhớ rằng đó là những thực tiễn 'tốt nhất' trong hội thảo của người khác , không phải của bạn.

lưu ý rằng vấn đề là để khách hàng và nhà phát triển đưa ra các tính năng và viết các câu chuyện và mô tả thử nghiệm cùng nhau , để hiểu lẫn nhau

Vì vậy, với cách đó, câu hỏi ban đầu là:

vai trò của kiến trúc sư phần mềm trong TDD là gì?

Và câu trả lời ngắn gọn là:

Giống như nó đã từng, giống như nó đã từng. --David Byrne

EDIT: Câu trả lời dài là: kiến trúc sư đóng vai trò tầm nhìn / điều tra viên / gây khó chịu / hỗ trợ / hỗ trợ / hỗ trợ thông thường trong toàn bộ quá trình, khi cần thiết.

EDIT 2: xin lỗi tôi đã bỏ lỡ điểm của các câu hỏi phụ! Mọi người có trách nhiệm viết các thông số kỹ thuật; tất cả các nhà phát triển bao gồm kiến trúc sư nếu / khi thích hợp cộng với khách hàng . Các nhà phát triển cũng mã hóa các bài kiểm tra.

— Steven A. Lowe
nguồn

Điều đó có ý nghĩa, nhưng các bước duy nhất tôi từng nghe mọi người nói đến trong bối cảnh TDD là năm bước trong năm viên đạn bên trong của bạn (mô tả quá trình tái cấu trúc màu đỏ-xanh lá cây). Những viên đạn còn lại có thực sự là một phần của TDD đúng không, hay chúng là một phần của một phương pháp bao gồm lớn hơn như Agile hay DDD?

— Robert Harvey

@Robert hmmm ... câu hỏi hay! về mặt kỹ thuật, các viên đạn khác sẽ là XP; Tôi đã học XP và TDD cùng một lúc và không bao giờ nghĩ sẽ tách chúng ra. Cho đến bây giờ ;-)

— Steven A. Lowe

@Robert đã làm một số đọc lại; xem các chỉnh sửa (FYI sử dụng XP ref extremeprogramming.org và TDD ref agiledata.org/essays/tdd.html#WhatIsTDD )

— Steven A. Lowe

Hmm, liên kết bạn cung cấp cho TDD nói rằng TDD thực sự là Thiết kế hướng thử nghiệm . Bây giờ tôi trở lại nơi tôi bắt đầu. "Bạn thiết kế hữu cơ, với mã chạy cung cấp phản hồi giữa các quyết định."

— Robert Harvey

@Robert các chỉnh sửa chắc chắn đã giúp tôi hiểu câu hỏi tốt hơn. Tôi lấy D làm Phát triển và diễn giải nó như toàn bộ vòng đời, không chỉ là phần mã hóa. TDDev là một cách tốt để học các kỹ năng kiến trúc - tái cấu trúc có xu hướng đẩy một người theo hướng đó

— Steven A. Lowe

Kiến trúc sư phần mềm không viết tất cả các bài kiểm tra. Điều đó sẽ đặt quá nhiều lên vai một người trong tâm trí tôi.

Kiến trúc sư phần mềm sẽ có thể phác thảo một biểu mẫu ban đầu cho API mà các nhà phát triển sau đó viết các bài kiểm tra cho điều đó và sau đó xây dựng API. Tuy nhiên, Kiến trúc sư phần mềm có thể có các tiêu chuẩn mã khác nhau mà không nhất thiết phải kiểm tra được, ví dụ như tài liệu hoặc quy ước đặt tên. Cũng có khả năng API ban đầu bị thiếu một số cuộc gọi mà khi triển khai được thực hiện, các cuộc gọi mới sẽ được thêm vào API. Do đó, sẽ có một số tăng trưởng hữu cơ cho API khi cơ sở mã phát triển nhưng vai trò của Kiến trúc sư là cung cấp các hướng dẫn cấp cao và cố gắng đảm bảo chúng được tuân theo.

Chắc chắn có thể có trường hợp một nhóm có thể quyết định không có Kiến trúc sư phần mềm nhưng tùy thuộc vào quy mô của API và công ty có liên quan, điều này có thể hoặc không phải là một ý tưởng hay.

— Vua JB
nguồn