11

Phát triển kết hợp: Giá trị tại giao điểm của TDD, DDD và BDD

Sự phát triển kết hợp có thể giúp bạn hoàn thành công việc đúng đắn.


Phát triển phần mềm đã bão hòa với các khuôn khổ, phương pháp luận và quy trình, hầu hết trong số đó đều đi kèm với hứa hẹn phát triển tốt hơn. Chỉ cần hỏi bất kỳ nhà phát triển nào, và họ có thể sẽ rất vui khi chia sẻ các mục yêu thích của họ hoặc đề xuất phương pháp nào bạn nên sử dụng.

Bạn đang muốn thực hiện một dự án lớn thành công? Họ có thể đề xuất một phương pháp. Bạn đang cố gắng tránh sự khác biệt giữa tài liệu thiết kế và những gì được triển khai thực tế? Họ biết một khuôn khổ hoàn hảo cho điều đó. Và nếu bạn muốn đảm bảo dự án của mình có sự hồi quy tối thiểu và có thể bảo trì theo thời gian, thì họ chắc chắn biết bạn nên tuân theo quy trình nào.

Nhưng điều gì sẽ xảy ra khi mức độ phức tạp của các dự án của bạn ngày càng tăng và sự trung thành với chỉ một phương pháp không mang lại lợi ích và giá trị mà dự án của bạn (và người dùng) xứng đáng? Như chúng ta đã học được từ đám mây lai , thường thì giải pháp tốt nhất cho một vấn đề phức tạp là sự kết hợp của một số. 

Bạn cũng có thể thích:  Phát triển theo hướng thử nghiệm kết hợp

Hôm nay, tôi sẽ chia sẻ với các bạn cách giải quyết sự phát triển khó khăn và phức tạp trong không gian linh hoạt bằng cách sử dụng không phải một phương pháp, mà là sự kết hợp lai của ba phương pháp cụ thể. 

3 phương pháp luận

Lời hứa về sự phát triển tốt hơn thông qua một giải pháp kết hợp của nhiều phương pháp sẽ hoạt động, nhưng bạn không thể chỉ sử dụng bất kỳ ba phương pháp nào. Họ cần phải được bổ sung, họ cần phải phát hiện ra chỗ khác thiếu hụt và tất cả đều cần cung cấp giá trị duy nhất của mình để đảm bảo kết quả có thể dự đoán và hiệu quả. Tóm lại, sự kết hợp hoàn hảo là TDD, DDD và BDD. 

Phát triển kết hợp: Giá trị tại giao điểm của TDD, DDD và BDD

Test Driven Development , hay TDD, là một quá trình phát triển phần mềm trong đó một bài kiểm tra được viết trước khi viết mã. Khi điều đó được thực hiện, các nhà phát triển sẽ hướng tới việc viết mã vừa đủ để vượt qua bài kiểm tra, và sau đó bắt đầu cấu trúc lại. 

Phát triển kết hợp: Giá trị tại giao điểm của TDD, DDD và BDD


Thiết kế theo hướng miền , hoặc DDD, là một cách tiếp cận để phát triển kết nối việc triển khai với một mô hình đang phát triển, đặt trọng tâm của dự án vào miền cốt lõi (phạm vi kiến ​​thức), logic đằng sau nó và buộc sự hợp tác giữa các bên kỹ thuật và phi kỹ thuật để cải thiện mô hình. 

Phát triển kết hợp: Giá trị tại giao điểm của TDD, DDD và BDD


Phát triển theo hướng hành vi , hay BDD, là sự cải tiến của TDD và DDD nhằm mục đích hợp lý hóa sự phát triển thông qua việc thu hẹp khoảng cách giao tiếp, tạo ra sự hiểu biết tốt hơn về khách hàng và cho phép giao tiếp liên tục. Nói một cách đơn giản, BDD là một cách kết hợp các yêu cầu nghiệp vụ với mã và cho phép bạn hiểu hành vi của hệ thống từ góc độ doanh nghiệp / người dùng cuối. 

Mặc dù tất cả những framework ở trên đều là những framework độc lập và có lợi theo đúng nghĩa của chúng, như tôi đã đề cập trước đó, nhu cầu phát triển phức tạp hơn đang và đã được chứng minh là quá nhiều đối với bất kỳ một framework nào, nhưng không phải cả ba. 

Một thực hành kết hợp

Phát triển kết hợp: Giá trị tại giao điểm của TDD, DDD và BDD


Kết hợp các phương pháp luận để đạt được kết quả mong muốn dường như là một ý tưởng tuyệt vời, đặc biệt là về mặt lý thuyết. Tuy nhiên, chỉ kết hợp các phương pháp này và hy vọng điều tốt nhất là chưa đủ. Bên cạnh việc có sự tham gia của tổ chức và sự hiểu biết chung về các khái niệm này giữa các nhóm của bạn và các thành viên của nhóm, bước quan trọng nhất là hiểu khi nào và ở đâu sử dụng các khuôn khổ này để đảm bảo sản lượng tối đa. 

Vì vậy, nơi nào chúng ta bắt đầu?

Vâng, biết rằng bước đầu tiên để giải quyết bất kỳ vấn đề nào là thực sự hiểu vấn đề bạn đang cố gắng giải quyết, nơi hợp lý duy nhất để bắt đầu là bên ngoài. 

Suy nghĩ bên ngoài (BDD)

Trước khi một dòng mã được viết (hoặc thậm chí nghĩ đến, cho vấn đề đó), bạn cần phải bắt đầu bằng cách hiểu vấn đề bạn đang cố gắng giải quyết, cách vấn đề được tạo ra ngay từ đầu và có lẽ quan trọng nhất là giá trị nào bạn dự kiến ​​giải pháp để có. Trong giai đoạn khám phá này, cách tốt nhất là sử dụng các câu hỏi mở để xác định điểm đau cụ thể mà bạn đang cố gắng giảm bớt, ai và họ sẽ được lợi từ nó như thế nào và nó sẽ có tác động như thế nào đối với tổ chức. 

Tại thời điểm này và nếu được thực hiện đúng, bạn nên hiểu rõ tại sao sự phát triển này lại có lợi và có tầm nhìn rõ ràng về những gì cần xây dựng. Cho đến nay, BDD đã đưa chúng ta đến thời điểm này, bây giờ đã đến lúc DDD tiếp quản.

Suy nghĩ về bức tranh lớn (DDD)

Cách tốt nhất để giải quyết một dự án phát triển lớn là gì? Bạn chia nó thành các phân đoạn nhỏ hơn, dễ quản lý hơn hoặc trong trường hợp DDD - tên miền. Khi bạn chia dự án thành các miền nhỏ hơn, bạn có thể có các nhóm riêng biệt xử lý chức năng của miền end-to-end đó. Và để hiểu rõ nhất về các miền đó, bạn tranh thủ sự giúp đỡ của các chuyên gia về miền; một người hiểu vấn đề và lĩnh vực kiến ​​thức hơn bất kỳ ai khác. 

Thông thường, chuyên gia miền không phải là người chịu trách nhiệm phát triển giải pháp, thay vào đó, DDD nói chung được sử dụng để giúp thu hẹp khoảng cách kiến ​​thức thường tồn tại giữa các chuyên gia này và giải pháp đang cố gắng thành hiện thực. Thông qua các mô hình, ngữ cảnh và ngôn ngữ phổ biến, tất cả các bên liên quan phải hiểu rõ các vấn đề cụ thể là gì và cách cấu trúc của công trình tiếp theo. 

Suy nghĩ từ trong ra ngoài (TDD)

Tôi biết bạn đang nghĩ gì: "Chúng ta bắt đầu viết mã vào thời điểm nào?" Vâng, câu trả lời là bây giờ, nhưng trước khi làm, bạn cần phải viết một bài kiểm tra.

Như đã thảo luận trước đây, TDD là một thực hành trong đó bạn viết bài kiểm tra thất bại ban đầu trước tiên để xác định một hàm, sau đó bạn quay lại và thử và viết số lượng mã tối thiểu để bài kiểm tra vượt qua; tiếp theo là tái cấu trúc để đảm bảo các tiêu chuẩn chấp nhận được. 

Nhưng tại sao chúng ta đợi quá lâu để viết mã? Chúng ta vẫn đang nói về sự phát triển, phải không? Vâng, tất nhiên, chúng ta vẫn đang nói về phát triển, nhưng chúng ta đang nói về phát triển chất lượng, và điều đó có nghĩa là phát triển không có lỗi. Nói một cách rộng rãi, có hai loại lỗi:

  1. Những nguyên nhân khiến hệ thống của bạn gặp sự cố 
  2. Những cái hiển thị kết quả sai

Bằng cách áp dụng phương pháp kết hợp được đề cập ở trên để phát triển, bạn sẽ thấy rằng TDD giúp bạn giảm thiểu và tránh loại lỗi đầu tiên, trong đó BDD và DDD giúp bạn tránh lỗi sau - cũng là lỗi đắt nhất để sửa. 

Tiến về phía trước

Khi mức độ phức tạp của các dự án ngày càng tăng, cách duy nhất để duy trì khả năng tồn tại của công trình xây dựng và đảm bảo thành công là có các phương pháp phát triển của bạn phát triển cùng với nó. Mặc dù các thực hành riêng lẻ của TDD, DDD và BDD đều có giá trị theo nghĩa riêng của chúng, nhưng chính điểm mà chúng giao nhau sẽ cung cấp giá trị thực cho tương lai. 

Bây giờ, nếu bạn phải đối mặt với một dự án lớn yêu cầu không có sự khác biệt giữa tài liệu thiết kế và việc triển khai, yêu cầu hồi quy tối thiểu và có thể duy trì theo thời gian, bạn có thể đề xuất một cách tiếp cận cho điều đó - cụ thể hơn, một cách tiếp cận kết hợp sử dụng ba phương pháp này . 

đọc thêm

BDD là gì và nó có ý nghĩa gì đối với người kiểm tra?

TDD: Tôi hiểu sai ở đâu?

Giới thiệu về thiết kế theo hướng miền và lợi ích của nó

|