Pair progamming là hiệu quả khi học một thực tế mới đặc biệt là TDD
Vì vậy, bạn có thể có cả hai với một thỏa hiệp. Làm điều này một cách nhanh nhẹn, từng bước. Thực hiện lập trình cặp đầu tiên. Nó là dễ dàng hơn trong hai. Tất cả các thực hành sau khi lập trình cặp sẽ trở nên dễ học hơn và sẽ được nhóm thông qua nhanh hơn và phù hợp hơn. Lập trình ghép đôi là một trong những chương trình đầu tiên nếu không phải là phương pháp rèn luyện động cơ đầu tiên cần được áp dụng. Hãy chắc chắn rằng nó được thực hiện một cách hiệu quả. Dưới đây là mô tả về cách lập trình ghép nối.
Lập trình được ghép nối là một trong những phương pháp hiệu quả nhất mà nhóm phát triển có thể sử dụng khi phát triển phần mềm. Ghép nối xảy ra với hai nhà phát triển tích cực phát triển thẻ truyện sử dụng một máy tính và bàn phím. Các nhà quản lý lo lắng rằng việc sử dụng lập trình được ghép nối sẽ tăng gấp đôi chi phí lập trình của họ. Thoạt nhìn, có thể hiểu được lý do tại sao họ có thể nghĩ rằng - sau khi tất cả - các nhà phát triển hai bước đang được yêu cầu làm việc cùng nhau trên cùng một nhiệm vụ. Tuy nhiên, trong thực tế, các nhóm Agile sử dụng kỹ thuật phát triển này đã phát hiện ra rằng sự gia tăng nhẹ về chi phí cho sự phát triển ban đầu (15% theo nghiên cứu của Đại học Utah) được bù đắp bằng cách giảm thiểu các khuyết tật, một thử nghiệm ngắn hơn và ít tốn kém hơn chu kỳ và giảm nhu cầu hỗ trợ sản xuất.Có thể có một số lý do tại sao kỹ thuật này thực sự hoạt động (Hãy suy nghĩ về câu nói cũ, "Hai đầu là tốt hơn một"). Đây là lý do tại sao :
- Chất lượng được cải thiện - Ghép nối khuyến khích xem xét mã. Nhiều sai lầm bị bắt khi chúng được đánh máy. Chương trình ghép nối có nghĩa là việc xem xét mã liên tục được thực hiện bởi hai người cam kết chất lượng của mã và đang làm việc cùng nhau để xác định và sửa lỗi mọi lúc. Một nghiên cứu được thực hiện bởi Đại học Utah đã phát hiện ra rằng số lỗi cuối cùng được tìm thấy trong mã đã được giảm trung bình 15% đối với mã được viết bởi các cặp.
- Ít thời gian hơn "Stuck" - Lập trình rất khó. Thường thì các nhà phát triển đấu tranh để tìm một giải pháp và dành nhiều thời gian hơn họ nên "mắc kẹt". Có một đối tác để suy nghĩ về ý tưởng và đồng ý tìm kiếm sự trợ giúp nếu cần thiết làm giảm lượng thời gian không hiệu quả dành cho việc cố gắng tìm một giải pháp.
- Ít thời gian hơn để phân tâm - Một nhà phát triển ít có khả năng dành thời gian cho các cuộc gọi điện thoại cá nhân hoặc lướt web hoặc email nghỉ khi họ đang làm việc với đối tác.
- Hai quan điểm được áp dụng cho vấn đề - Mức độ trải nghiệm khác nhau, các kiểu giải quyết vấn đề khác nhau, các kỹ năng phụ trợ khác nhau đều làm tăng cơ hội giải quyết vấn đề nhanh hơn. Nghiên cứu được thực hiện bởi Đại học Utah cũng xác định thiết kế tổng thể tốt hơn và độ dài mã ngắn hơn cho phần mềm được viết bởi các cặp.
- Ít sợ hãi của không xác định - Khi ghép nối với một nhà phát triển khác, việc giải quyết vấn đề hoặc cố gắng nắm bắt công nghệ mới dễ dàng hơn là khi làm việc một mình. Họ cũng đạt được, theo thời gian, một sự hiểu biết tốt hơn nhiều về toàn bộ ứng dụng. Cuối cùng, dự án kết thúc với nhiều người hiểu từng phần của hệ thống là kết quả của việc ghép nối.
- Ít có khả năng xây dựng trong Phạm vi - Thường thì nhà phát triển sẵn sàng thêm chức năng không được giải quyết trong các yêu cầu. Khi làm việc với một cặp, nhà phát triển thứ hai có nhiều khả năng giữ cho đối tác của anh ấy/cô ấy thực hiện nhiệm vụ.
- Cải tiến nhóm động lực - Do cách tiếp cận được ghép nối, mọi người học cách làm việc cùng nhau. Họ nói chuyện thường xuyên hơn và trải nghiệm một luồng thông tin tốt hơn. Động lực nhóm cải thiện kết quả. Trên thực tế, chúng tôi nhận thấy rằng trải nghiệm xây dựng đội ngũ tốt nhất xung quanh đang làm việc cùng nhau để sản xuất phần mềm mà khách hàng của bạn phấn khích. Mọi người đều thích là một phần của một đội thành công.
- Loại bỏ các kiến thức về kiến thức - Kiến thức tên miền, kiến thức về mã hoặc thực hành được truyền nhanh chóng thông qua nhóm và nhà phát triển với nhau trên cơ sở xoay vòng.
Sau khi nhóm bị nhầm lẫn với ghép nối, hãy đảm nhận TDD. Một mệnh đề sau:
Phát triển theo hướng thử nghiệm (TDD) là một kỹ thuật phát triển phần mềm bao gồm phát triển ngắn, trong đó trường hợp thử nghiệm mới bao gồm cải thiện mong muốn hoặc chức năng mới được viết trước, sau đó mã sản xuất cần thiết để vượt qua thử nghiệm được thực hiện, và cuối cùng phần mềm được tái cấu trúc để thích ứng với các thay đổi. Sự sẵn có của các bài kiểm tra trước khi phát triển thực tế đảm bảo phản hồi nhanh chóng sau bất kỳ thay đổi nào. Các học viên nhấn mạnh rằng phát triển theo hướng thử nghiệm là một phương pháp thiết kế phần mềm, không chỉ đơn thuần là một phương pháp thử nghiệm. Phát triển theo thử nghiệm là một thực hành mạnh mẽ và là một đóng góp chính cho việc giảm các khuyết tật được tìm thấy sau này trong vòng đời. Một nhóm mới được khuyến khích mạnh mẽ ghép nối với một chuyên gia TDD kinh nghiệm hoặc nếu không nhận được huấn luyện TDD.e
Phát triển theo hướng thử nghiệm yêu cầu kiểm tra đơn vị tự động, xác định các yêu cầu của mã, được viết trước mỗi khía cạnh của chính mã đó .Các thử nghiệm này chứa các xác nhận đúng hoặc sai. Chạy thử nghiệm cho phép xác nhận nhanh chóng hành vi chính xác khi mã phát triển và được tái cấu trúc. Các khuôn khổ thử nghiệm dựa trên khái niệm xUnit cung cấp một cơ chế để tạo và chạy bộ các trường hợp thử nghiệm tự động. Chu kỳ phát triển theo hướng thử nghiệm: Trình tự sau đây dựa trên cuốn sách Phát triển theo hướng thử nghiệm theo Ví dụ, mà nhiều người coi là văn bản nguồn kinh điển về khái niệm ở dạng hiện đại của nó.
- Viết thử nghiệm. Trong quá trình phát triển thử nghiệm, mỗi câu chuyện mới bắt đầu bằng cách viết một bài kiểm tra. Thử nghiệm này sẽ thất bại vì nó được viết trước khi tính năng được triển khai. Để viết bài kiểm tra, nhà phát triển phải hiểu rõ đặc điểm kỹ thuật và các yêu cầu của đối tượng địa lý một cách rõ ràng. Điều này có thể được thực hiện thông qua Thẻ Story với các tiêu chí chấp nhận để xác định khi nào các yêu cầu đã được đáp ứng. Điều này cũng có thể ngụ ý một bất biến, hoặc sửa đổi của một thử nghiệm hiện có. Đây là một tính năng khác biệt của phát triển theo hướng thử nghiệm so với các bài kiểm tra đơn vị viết sau khi viết mã: nó làm cho nhà phát triển tập trung vào các yêu cầu trước khi viết mã, một sự khác biệt tinh tế nhưng quan trọng.
- Chạy tất cả các thử nghiệm và xem thử nghiệm mới có bị lỗi hay không. Điều này xác nhận rằng việc khai thác thử nghiệm đang hoạt động chính xác và kiểm tra mới không vượt qua một cách sai lầm mà không yêu cầu bất kỳ mã mới nào. Các thử nghiệm mới cũng nên thất bại vì lý do dự kiến. Bước này kiểm tra bản thân bài kiểm tra, trong tiêu cực: nó loại trừ khả năng bài kiểm tra mới sẽ luôn vượt qua, và do đó vô giá trị.
- Viết một số mã. Bước tiếp theo là viết một số mã sẽ làm cho bài thi vượt qua. Mã mới được viết ở giai đoạn này sẽ không hoàn hảo và có thể, ví dụ, vượt qua bài kiểm tra một cách không phù hợp. Điều đó có thể chấp nhận được vì các bước sau sẽ cải thiện và trau dồi nó. Điều quan trọng là mã được viết chỉ được thiết kế để vượt qua bài kiểm tra; không có thêm (và do đó chưa được kiểm tra) chức năng nên được dự đoán và 'cho phép' ở bất kỳ giai đoạn nào.
- Chạy thử nghiệm tự động và xem chúng thành công. Nếu tất cả các trường hợp thử nghiệm bây giờ vượt qua, lập trình viên có thể tự tin rằng mã đáp ứng tất cả các yêu cầu được kiểm tra. Đây là một điểm tốt để bắt đầu bước cuối cùng của chu trình.
- Mã Refactor. Bây giờ mã có thể được dọn sạch khi cần thiết. Bằng cách chạy lại các trường hợp thử nghiệm, nhà phát triển có thể tự tin rằng việc tái cấu trúc không làm hỏng bất kỳ chức năng hiện có nào. Khái niệm loại bỏ trùng lặp là một khía cạnh quan trọng của bất kỳ thiết kế phần mềm nào. Tuy nhiên, trong trường hợp này, nó cũng áp dụng để loại bỏ bất kỳ sự trùng lặp nào giữa mã thử nghiệm và mã sản xuất - ví dụ như số ma thuật hoặc chuỗi được lặp lại trong cả hai, để thực hiện kiểm tra ở bước 3.
Lặp lại
Bắt đầu với một thử nghiệm mới khác, chu trình này sau đó được lặp lại để đẩy về phía trước chức năng. Kích thước của các bước có thể nhỏ như nhà phát triển thích hoặc trở nên lớn hơn nếu người đó cảm thấy tự tin hơn. Nếu mã được viết để đáp ứng một bài kiểm tra không nhanh chóng làm như vậy, thì kích thước bước có thể quá lớn và có thể các bước thử nghiệm nhỏ hơn sẽ được sử dụng thay thế. Khi sử dụng các thư viện bên ngoài, điều quan trọng là không làm tăng số lượng quá nhỏ để kiểm tra thư viện một cách hiệu quả, trừ khi có một số lý do để tin rằng thư viện bị lỗi hoặc không đầy đủ tính năng để phục vụ mọi nhu cầu của chương trình chính được viết.
Phong cách phát triển Có nhiều khía cạnh khác nhau để sử dụng phát triển theo hướng thử nghiệm, ví dụ như nguyên tắc "Keep It Simple, Stupid" (KISS) và "You Ain't Gonna Need It" (YAGNI). Bằng cách chỉ tập trung vào việc viết mã cần thiết để vượt qua các bài kiểm tra, các thiết kế có thể sạch hơn và rõ ràng hơn so với các phương pháp khác thường đạt được. Phát triển theo hướng thử nghiệm yêu cầu người lập trình phải thất bại trước tiên trong các trường hợp thử nghiệm. Ý tưởng là để đảm bảo rằng thử nghiệm thực sự hoạt động và có thể bắt lỗi. Khi điều này được hiển thị, chu kỳ bình thường sẽ bắt đầu.Điều này đã được đặt ra là "Mantra phát triển theo hướng thử nghiệm", được gọi là red/green/refactor, nơi màu đỏ có nghĩa là không thành công và màu xanh lá cây được truyền đi. Phát triển theo hướng thử nghiệm liên tục lặp lại các bước thêm trường hợp thử nghiệm không thành công, chuyển chúng và tái cấu trúc. Nhận kết quả kiểm tra dự kiến ở mỗi giai đoạn củng cố mô hình tinh thần của lập trình viên, tăng sự tự tin và tăng năng suất
Lập trình ghép đôi = Xem lại mã liên tục. Đồng thời cặp lập trình không phải là một thực hành tốn kém để áp dụng - nhưng tôi khuyên bạn nên chống lại ghép nối 2 người mới bắt đầu/người mới bắt đầu. Một cặp nên luôn luôn chứa một người chuyên nghiệp trung gian, những người biết khu vực đang được sửa đổi khá tốt. Mặt khác, TDD là rất khó để làm chủ .. mất thời gian của bạn .. không phát nổ. Thử nghiệm xấu tồi tệ hơn không có xét nghiệm. – Gishu