Làm thế nào để tốt hơn trong việc kiểm tra mã của riêng bạn

Tôi là một nhà phát triển phần mềm tương đối mới và một trong những điều tôi nghĩ tôi nên cải thiện là khả năng kiểm tra mã của riêng tôi. Bất cứ khi nào tôi phát triển một chức năng mới, tôi thấy thực sự khó khăn khi đi theo tất cả các đường dẫn có thể để tôi có thể tìm thấy lỗi. Tôi có xu hướng đi theo con đường nơi mọi thứ hoạt động. Tôi biết đây là một vấn đề nổi tiếng mà các lập trình viên gặp phải, nhưng chúng tôi không có người kiểm tra tại nhà tuyển dụng hiện tại của tôi và các đồng nghiệp của tôi dường như khá giỏi trong việc này.

Tại tổ chức của tôi, chúng tôi không phát triển dựa trên thử nghiệm cũng như thử nghiệm đơn vị. Nó sẽ giúp tôi rất nhiều nhưng không có khả năng điều này sẽ thay đổi.

Các bạn nghĩ tôi có thể làm gì để vượt qua điều này? Cách tiếp cận nào bạn sử dụng khi kiểm tra mã của riêng bạn?

Công việc của một lập trình viên là xây dựng mọi thứ.

Công việc của một người thử nghiệm là phá vỡ mọi thứ.

Khó khăn nhất là phá vỡ những thứ bạn vừa xây dựng. Bạn sẽ thành công chỉ bằng cách vượt qua rào cản tâm lý này.

Franciso, tôi sẽ đưa ra một số giả định ở đây, dựa trên những gì bạn đã nói:

"Chúng tôi không làm thử nghiệm TDD hay đơn vị. Nó sẽ giúp tôi rất nhiều nhưng không có khả năng điều này sẽ thay đổi."

Từ điều này, tôi nghi ngờ nhóm của bạn không đặt nhiều giá trị vào thử nghiệm hoặc quản lý sẽ không dành thời gian ngân sách để nhóm thử và dọn dẹp mã hiện có và giữ nợ kỹ thuật ở mức tối thiểu.

Đầu tiên, bạn cần thuyết phục nhóm / quản lý của mình về giá trị của thử nghiệm. Hãy ngoại giao. Nếu quản lý giữ cho nhóm của bạn tiến lên phía trước, bạn cần cho họ thấy một số sự thật, chẳng hạn như tỷ lệ lỗi cho mỗi bản phát hành. Thời gian dành cho việc sửa chữa các khiếm khuyết có thể được dành tốt hơn cho những thứ khác, chẳng hạn như cải thiện ứng dụng và làm cho nó thích ứng hơn với các yêu cầu trong tương lai.

Nếu nhóm và quản lý nói chung thờ ơ với việc sửa mã và bạn cảm thấy không hài lòng về nó, bạn có thể cần tìm một nơi khác để làm việc, trừ khi bạn có thể thuyết phục họ như tôi đã nói. Tôi đã gặp vấn đề này ở các mức độ khác nhau ở tất cả những nơi tôi đã làm việc. Nó có thể là bất cứ điều gì, từ việc thiếu một mô hình miền thích hợp, cho đến giao tiếp kém trong nhóm.

Quan tâm đến mã của bạn và chất lượng sản phẩm bạn phát triển là một thuộc tính tốt và bạn luôn muốn khuyến khích người khác.

Nếu bạn viết mã bằng C, Objective-C hoặc C ++, bạn có thể sử dụng Trình phân tích tĩnh CLang để phê bình nguồn của mình mà không thực sự chạy nó.

Có một số công cụ gỡ lỗi bộ nhớ có sẵn: ValGrind, Guard Malloc trên Mac OS X, Hàng rào điện trên * NIX.

Một số môi trường phát triển cung cấp tùy chọn sử dụng bộ cấp phát bộ nhớ gỡ lỗi, những thứ như lấp đầy các trang mới được phân bổ và các trang mới được giải phóng với rác, phát hiện giải phóng các con trỏ chưa được phân bổ và viết một số dữ liệu trước và sau mỗi khối heap, với trình gỡ lỗi được gọi nếu mẫu đã biết của dữ liệu đó thay đổi.

Một số anh chàng trên Slashdot nói rằng anh ta nhận được rất nhiều giá trị từ một bước nguồn mới trong một trình gỡ lỗi. "Đó là nó", ông nói. Tôi không luôn làm theo lời khuyên của anh ấy, nhưng khi tôi có nó thì nó rất hữu ích với tôi. Ngay cả khi bạn không có trường hợp thử nghiệm kích thích đường dẫn mã không phổ biến, bạn có thể xoay vòng một biến trong trình gỡ lỗi của mình để thực hiện các đường dẫn đó, bằng cách phân bổ một số bộ nhớ, sau đó sử dụng trình gỡ lỗi để đặt con trỏ mới của bạn thành NULL thay vì địa chỉ bộ nhớ, sau đó bước qua xử lý thất bại phân bổ.

Sử dụng các xác nhận - macro khẳng định () trong C, C ++ và Objective-C. Nếu ngôn ngữ của bạn không cung cấp chức năng khẳng định, hãy tự viết.

Sử dụng các xác nhận một cách tự do, sau đó để chúng trong mã của bạn. Tôi gọi khẳng định () "Bài kiểm tra tiếp tục kiểm tra". Tôi sử dụng chúng phổ biến nhất để kiểm tra các điều kiện tiên quyết tại điểm vào của hầu hết các chức năng của tôi. Đó là một phần của "Lập trình theo hợp đồng", được tích hợp vào ngôn ngữ lập trình Eiffel. Phần khác là postconditions, nghĩa là sử dụng assert () tại các điểm trả về hàm, nhưng tôi thấy rằng tôi không nhận được nhiều dặm như điều kiện tiên quyết.

Bạn cũng có thể sử dụng assert để kiểm tra các bất biến lớp. Mặc dù không có lớp nào được yêu cầu nghiêm ngặt để có bất kỳ sự bất biến nào, nhưng hầu hết các lớp được thiết kế hợp lý đều có chúng. Một bất biến lớp là một số điều kiện luôn luôn đúng ngoài các hàm thành viên có thể tạm thời đặt đối tượng của bạn vào trạng thái không nhất quán. Các chức năng như vậy luôn phải khôi phục tính nhất quán trước khi chúng trở lại.

Do đó, mọi hàm thành viên có thể kiểm tra bất biến khi vào và ra và lớp có thể định nghĩa một hàm có tên là CheckInvariant mà bất kỳ mã nào khác có thể gọi bất cứ lúc nào.

Sử dụng một công cụ bao phủ mã để kiểm tra các dòng nào trong nguồn của bạn đang thực sự được kiểm tra, sau đó thiết kế các kiểm tra kích thích các dòng chưa được kiểm tra. Ví dụ: bạn có thể kiểm tra các trình xử lý bộ nhớ thấp bằng cách chạy ứng dụng của mình bên trong máy ảo được cấu hình với ít bộ nhớ vật lý và không có tệp hoán đổi hoặc một tệp rất nhỏ.

(Vì một số lý do mà tôi chưa bao giờ biết, trong khi BeOS có thể chạy mà không cần tệp hoán đổi, thì nó rất không ổn định theo cách đó. Dominic Giampaolo, người đã viết hệ thống tập tin BFS, đã thúc giục tôi đừng bao giờ chạy BeOS mà không trao đổi. xem tại sao điều đó lại quan trọng, nhưng nó phải là một loại tạo tác thực hiện.)

Bạn cũng nên kiểm tra phản hồi của mã đối với các lỗi I / O. Hãy thử lưu trữ tất cả các tệp của bạn trên một chia sẻ mạng, sau đó ngắt kết nối cáp mạng của bạn trong khi ứng dụng của bạn có khối lượng công việc lớn. Tương tự ngắt kết nối cáp - hoặc tắt mạng không dây của bạn - nếu bạn đang liên lạc qua mạng.

Một điều mà tôi thấy đặc biệt khó chịu là các trang web không có mã Javascript mạnh mẽ. Các trang của Facebook tải hàng tá tệp Javascript nhỏ, nhưng nếu bất kỳ một trong số chúng không tải xuống được thì toàn bộ trang sẽ bị hỏng. Chỉ cần có một số cách để cung cấp khả năng chịu lỗi, bằng cách thử lại tải xuống hoặc cung cấp một số loại dự phòng hợp lý khi một số tập lệnh của bạn không tải xuống.

Hãy thử tắt ứng dụng của bạn bằng trình gỡ lỗi hoặc bằng "kill -9" trên * NIX trong khi nó ở ngay giữa khi viết một tệp lớn, quan trọng. Nếu ứng dụng của bạn được kiến ​​trúc tốt, toàn bộ tệp sẽ được viết hoặc hoàn toàn không được viết hoặc có thể nếu nó chỉ được viết một phần, những gì được viết sẽ không bị hỏng, với những dữ liệu được lưu hoàn toàn có thể sử dụng được các ứng dụng khi đọc lại tập tin.

cơ sở dữ liệu luôn có I / O đĩa chịu lỗi, nhưng hầu như không có loại ứng dụng nào khác làm được. Mặc dù các hệ thống tệp được ghi nhật ký ngăn chặn tham nhũng hệ thống tệp trong trường hợp mất điện hoặc gặp sự cố, chúng không làm gì cả để ngăn chặn tham nhũng hoặc mất dữ liệu của người dùng cuối. Đó là trách nhiệm của các ứng dụng người dùng, nhưng hầu như không có cơ sở dữ liệu nào khác thực hiện khả năng chịu lỗi.

Khi tôi xem xét việc kiểm tra mã của mình, tôi thường trải qua một loạt các quá trình suy nghĩ:

1. Làm thế nào để tôi chia "thứ" này thành một khối kích thước có thể kiểm tra? Làm thế nào tôi có thể cô lập những gì tôi muốn kiểm tra? Những cuống / giả nào tôi nên tạo ra?
2. Đối với mỗi đoạn: Làm cách nào để kiểm tra đoạn này để đảm bảo rằng nó phản hồi chính xác với một bộ đầu vào chính xác hợp lý?
3. Đối với mỗi đoạn: Làm cách nào để kiểm tra đoạn dữ liệu đó phản hồi chính xác với các đầu vào không chính xác (con trỏ NULL, giá trị không hợp lệ)?
4. Làm cách nào để kiểm tra các ranh giới (ví dụ: nơi các giá trị chuyển từ được ký sang không dấu, 8 bit đến 16 bit, v.v.)?
5. Làm thế nào để kiểm tra của tôi bao gồm các mã? Có điều kiện nào tôi bỏ lỡ? [Đây là một nơi tuyệt vời cho các công cụ bao phủ mã.] Nếu có mã bị bỏ sót và không bao giờ có thể được thực thi, nó có thực sự cần phải ở đó không? [Đó là một câu hỏi hoàn toàn khác!]

Cách dễ nhất tôi đã tìm thấy để làm điều này là phát triển các thử nghiệm của tôi cùng với mã của tôi. Ngay sau khi tôi đã viết ngay cả một đoạn mã, tôi muốn viết một bài kiểm tra cho nó. Cố gắng thực hiện tất cả các thử nghiệm sau khi đã mã hóa vài nghìn dòng mã với độ phức tạp mã chu kỳ không tầm thường là một cơn ác mộng. Thêm một hoặc hai bài kiểm tra nữa sau khi thêm một vài dòng mã thực sự dễ dàng.

BTW, chỉ vì công ty bạn làm việc và / hoặc đồng nghiệp của bạn không thực hiện Kiểm tra đơn vị hoặc TDD, không có nghĩa là bạn không thể thử chúng, trừ khi chúng bị cấm đặc biệt. Có lẽ sử dụng chúng để tạo mã mạnh mẽ sẽ là một ví dụ tốt cho những người khác.

Ngoài lời khuyên được đưa ra trong các câu trả lời khác, tôi khuyên bạn nên sử dụng các công cụ phân tích tĩnh (Wikipedia có danh sách một số công cụ phân tích tĩnh cho các ngôn ngữ khác nhau ) để tìm lỗi tiềm ẩn trước khi bắt đầu thử nghiệm cũng như theo dõi một số số liệu liên quan đến testability mã, chẳng hạn như độ phức tạp cyclomatic , các biện pháp phức tạp Halstead , và sự gắn kết và khớp nối (bạn có thể đo những điều này với người hâm mộ trong và quạt-out).

Việc tìm kiếm mã khó để kiểm tra và làm cho việc kiểm tra dễ dàng hơn, tốt hơn, giúp bạn dễ dàng viết các trường hợp kiểm thử hơn. Ngoài ra, việc bắt lỗi sớm sẽ tăng thêm giá trị cho toàn bộ hoạt động đảm bảo chất lượng của bạn (bao gồm kiểm tra). Từ đây, làm quen với các công cụ kiểm tra đơn vị và công cụ mô phỏng sẽ giúp bạn thực hiện thử nghiệm dễ dàng hơn.

Bạn có thể xem xét cách sử dụng có thể của Bàn chân lý để giúp bạn xác định tất cả các đường dẫn tiềm năng trong mã của mình. Không thể tính đến tất cả các khả năng trong các chức năng phức tạp, nhưng một khi bạn đã xử lý xong các đường dẫn đã biết, bạn có thể thiết lập xử lý cho trường hợp khác.

Hầu hết các khả năng đặc biệt này được học bằng kinh nghiệm mặc dù. Sau khi bạn đã sử dụng một khung nhất định trong một khoảng thời gian đáng kể, bạn bắt đầu thấy các kiểu và dấu hiệu hành vi sẽ cho phép bạn xem một đoạn mã và xem một thay đổi nhỏ có thể gây ra lỗi lớn. Cách duy nhất tôi có thể nghĩ ra để tăng khả năng của bạn trong việc này là thực hành.

Nếu như bạn nói bạn không cần Kiểm thử đơn vị, tôi không thấy cách tiếp cận nào tốt hơn là cố gắng tự phá mã của mình.

Cố gắng đẩy mã của bạn đến giới hạn . Ví dụ: cố gắng truyền các biến cho một hàm vượt quá giới hạn biên. Bạn có một chức năng được cho là để lọc đầu vào của người dùng? Cố gắng nhập các kết hợp khác nhau của các ký tự.

Hãy xem xét quan điểm của người dùng . Cố gắng trở thành một trong những người dùng sẽ sử dụng ứng dụng hoặc thư viện chức năng của bạn.

nhưng chúng tôi không có người thử nghiệm tại nhà tuyển dụng hiện tại của tôi và các đồng nghiệp của tôi dường như khá giỏi về việc này

Các đồng nghiệp của bạn phải thực sự đặc biệt để không tuân theo TDD hoặc kiểm tra đơn vị và không bao giờ phát sinh lỗi vì vậy ở một mức độ nào đó tôi nghi ngờ rằng họ không tự thực hiện bất kỳ thử nghiệm đơn vị nào.

Tôi đoán rằng các đồng nghiệp của bạn đang thực hiện nhiều thử nghiệm hơn là cho phép nhưng vì thực tế này không được quản lý biết đến nên tổ chức phải chịu hậu quả vì quản lý có ấn tượng rằng thử nghiệm thực sự không được thực hiện và do đó số lượng lỗi thấp kiểm tra là không quan trọng và thời gian sẽ không được lên lịch cho nó.

Nói chuyện với các đồng nghiệp của bạn và cố gắng tìm ra loại thử nghiệm đơn vị họ đang làm và mô phỏng điều đó. Sau đó, bạn có thể tạo nguyên mẫu các cách tốt hơn để kiểm tra các thuộc tính TDD và từ từ và giới thiệu các khái niệm này cho nhóm để áp dụng dễ dàng hơn.

• Viết bài kiểm tra của bạn trước khi bạn viết mã của bạn.
• Bất cứ khi nào bạn sửa một lỗi không bị bắt bởi một bài kiểm tra, hãy viết một bài kiểm tra để bắt lỗi đó.

Bạn sẽ có thể nhận được bảo hiểm về những gì bạn viết ngay cả khi tổ chức của bạn không có bảo hiểm đầy đủ. Giống như rất nhiều thứ trong lập trình, kinh nghiệm làm đi làm lại nhiều lần là một trong những cách tốt nhất để có hiệu quả với nó.

Ngoài tất cả các ý kiến ​​khác, vì bạn nói rằng đồng nghiệp của bạn rất giỏi trong việc viết các bài kiểm tra không hạnh phúc, tại sao không yêu cầu họ ghép đôi với bạn khi viết một số bài kiểm tra.

Cách tốt nhất để học là xem cách nó được thực hiện và rút ra những gì bạn học được từ đó.

Thử nghiệm hộp đen! Bạn nên tạo các lớp / phương thức của bạn với thử nghiệm trong tâm trí. Các thử nghiệm của bạn phải dựa trên đặc điểm kỹ thuật của phần mềm và phải được xác định rõ ràng trên sơ đồ Trình tự của bạn (thông qua các trường hợp sử dụng).

Bây giờ vì bạn có thể không muốn thực hiện phát triển theo hướng thử nghiệm ...

Đặt xác nhận đầu vào trên tất cả các dữ liệu đến; đừng tin ai cả. Khung .net đã đưa ra rất nhiều trường hợp ngoại lệ dựa trên các đối số không hợp lệ, tham chiếu null và trạng thái không hợp lệ. Bạn đã nghĩ đến việc sử dụng xác nhận đầu vào trên lớp UI để nó có cùng một mẹo trong kho trung gian.

Nhưng bạn thực sự nên thực hiện một số loại thử nghiệm tự động; những thứ đó cứu mạng.

Theo kinh nghiệm của tôi

Đơn vị kiểm tra, nếu nó không hoàn toàn tự động, nó là vô dụng. Nó giống như một ông chủ tóc nhọn có thể mua. Tại sao?, Bởi vì Đơn vị kiểm tra hứa với bạn sẽ tiết kiệm thời gian (và tiền) tự động hóa một số quy trình kiểm tra. Nhưng, một số công cụ đơn vị kiểm thử làm ngược lại, nó buộc các lập trình viên phải làm việc theo một cách kỳ lạ và buộc người khác phải tạo ra thử nghiệm quá mức. Hầu hết thời gian, nó sẽ không tiết kiệm giờ làm việc mà tăng thời gian chuyển từ QA sang nhà phát triển.

UML là một thời gian khác. một bảng trắng + bút có thể làm tương tự, rẻ hơn và nhanh chóng.

BTW, Làm thế nào để giỏi mã hóa (và tránh lỗi)?

• a) tính nguyên tử. Một hàm thực hiện một thao tác đơn giản (hoặc một vài nhiệm vụ đơn lẻ). Bởi vì nó dễ hiểu, dễ theo dõi và dễ giải quyết nó.

• b) Tương đồng. Ví dụ, nếu bạn gọi một cơ sở dữ liệu bằng cách sử dụng thủ tục lưu trữ thì hãy thực hiện phần còn lại của mã.

• c) Xác định, giảm và cô lập "mã sáng tạo". Hầu hết các mã là khá nhiều bản sao và dán. Mã sáng tạo thì ngược lại, một mã mới và nó hoạt động như một nguyên mẫu, nó có thể thất bại. Mã này dễ bị lỗi logic, vì vậy điều quan trọng là phải giảm, cô lập và xác định nó.

• d) Mã "băng mỏng", là mã mà bạn biết rằng nó "không chính xác" (hoặc có khả năng gây nguy hiểm) nhưng vẫn cần, ví dụ mã không an toàn cho quy trình đa tác vụ. Tránh nếu bạn có thể.

• e) Tránh mã hộp đen, mã này bao gồm mã mà bạn không thực hiện (ví dụ khung) và biểu thức chính quy. Rất dễ bỏ sót một lỗi với loại mã này. Ví dụ, tôi đã làm việc trong một dự án sử dụng Jboss và tôi không tìm thấy một lỗi nào ngoài 10 lỗi trong Jboss (sử dụng phiên bản ổn định mới nhất), đó là Pita để tìm những lỗi đó. Tránh Hibernate đặc biệt, nó ẩn việc thực hiện, do đó các lỗi.

• f) thêm ý kiến ​​trong mã của bạn.

• g) đầu vào của người dùng như là nguồn của lỗi. xác định nó Ví dụ: SQL Injection được gây ra bởi đầu vào của người dùng.

• h) Xác định yếu tố xấu của nhóm và tách nhiệm vụ được giao. Một số lập trình viên có xu hướng vặn mã.

• i) Tránh mã không cần thiết. Nếu, ví dụ, lớp cần Giao diện thì hãy sử dụng nó, nếu không thì tránh thêm mã không liên quan.

a) và b) là chìa khóa. Ví dụ, tôi gặp sự cố với hệ thống, khi tôi nhấp vào nút (lưu), nó không lưu biểu mẫu. Sau đó, tôi đã làm một danh sách kiểm tra:

• nút hoạt động? ... có.
• cơ sở dữ liệu lưu trữ cái gì? không, do đó, lỗi là ở một bước giữa.
• Sau đó, lớp lưu trữ trong cơ sở dữ liệu hoạt động?. không <- ok, tôi tìm thấy lỗi. (nó có liên quan đến sự cho phép của cơ sở dữ liệu). Sau đó, tôi đã kiểm tra không chỉ thủ tục này mà mọi thủ tục đều làm như vậy (vì tính tương đồng của mã). Tôi mất 5 phút để theo dõi lỗi và 1 phút để giải quyết nó (và nhiều lỗi khác).

Và một sidenote

Hầu hết thời gian QA hút (như một phần riêng biệt của Dev), sẽ vô ích nếu chúng không được làm việc trong dự án. Họ làm một số thử nghiệm chung chung và không có gì khác nhiều. Họ không thể xác định hầu hết các lỗi logic. Trong trường hợp của tôi, tôi đang làm việc trong một ngân hàng có uy tín, một lập trình viên đã hoàn thành một mã sau đó gửi nó đến QA. QA đã phê duyệt mã và được đưa vào sản xuất ... sau đó mã bị lỗi (thất bại sử thi), bạn có biết ai đã bị đổ lỗi không?. vâng, lập trình viên.

Một người kiểm tra và lập trình viên phải đối mặt với vấn đề từ các góc độ khác nhau, nhưng cả hai vai trò nên kiểm tra đầy đủ chức năng và tìm lỗi. Trường hợp các vai trò khác nhau được tập trung. Một người kiểm tra cổ điển chỉ nhìn thấy ứng dụng từ bên ngoài (tức là hộp đen). Họ là những chuyên gia về các yêu cầu chức năng của ứng dụng. Một lập trình viên dự kiến ​​sẽ là một chuyên gia về cả các yêu cầu chức năng và mã (nhưng có xu hướng tập trung nhiều hơn vào mã).

(Điều này phụ thuộc vào tổ chức liệu các lập trình viên có được kỳ vọng rõ ràng là một chuyên gia về các yêu cầu hay không.

Vai trò chuyên gia kép này đang đánh thuế vào tâm trí của lập trình viên và, ngoại trừ những người có kinh nghiệm nhất, có thể làm giảm sự thành thạo trong các yêu cầu. Tôi thấy rằng tôi phải thay đổi tinh thần để xem xét người dùng của ứng dụng. Đây là những gì giúp tôi:

1. Gỡ lỗi ; đặt điểm dừng trong mã và chạy ứng dụng. Khi bạn đạt điểm dừng, hãy bước qua các dòng khi bạn tương tác với ứng dụng.
2. Kiểm tra tự động ; viết mã kiểm tra mã của bạn Điều này chỉ giúp ở các tầng bên dưới UI.
3. Nhận biết người thử nghiệm của bạn ; họ có thể biết ứng dụng tốt hơn bạn, vì vậy hãy học hỏi từ họ. Hỏi họ xem điểm yếu của ứng dụng của bạn là gì và họ sử dụng chiến thuật nào để tìm lỗi.
4. Nhận biết người dùng của bạn ; học cách đi trong giày của người dùng của bạn. Các yêu cầu chức năng là dấu vân tay của người dùng của bạn. Thường có nhiều điều người dùng của bạn biết về ứng dụng có thể không thông qua rõ ràng trong các yêu cầu chức năng. Khi bạn hiểu người dùng của mình tốt hơn - bản chất công việc của họ trong thế giới thực và cách ứng dụng của bạn có nghĩa vụ giúp đỡ họ - bạn sẽ hiểu rõ hơn ứng dụng đó là gì.

Tôi nghĩ rằng bạn muốn làm việc trên hai mặt trận. Một là chính trị, khiến tổ chức của bạn chấp nhận thử nghiệm ở một mức độ nào đó (với hy vọng theo thời gian họ sẽ áp dụng nhiều hơn). Nói chuyện với các kỹ sư QA bên ngoài nơi làm việc của bạn. Tìm danh sách các sách QA . Chọc quanh các bài viết wikipedia có liên quan . Làm quen với các nguyên tắc và thực hành QA. Học những thứ này sẽ chuẩn bị cho bạn để đưa ra trường hợp thuyết phục nhất bạn có thể trong tổ chức của mình. Các bộ phận QA tốt tồn tại và họ làm tăng giá trị đáng kể cho các tổ chức của họ.

Là một nhà phát triển cá nhân, áp dụng các chiến lược để sử dụng trong công việc của riêng bạn. Sử dụng TDD cho mình bằng cách đồng phát triển mã và kiểm tra. Giữ các xét nghiệm rõ ràng và duy trì tốt. Nếu được hỏi tại sao bạn làm điều này, bạn có thể nói rằng bạn đang ngăn chặn hồi quy và nó giữ cho quá trình suy nghĩ của bạn được tổ chức tốt hơn (cả hai điều này sẽ đúng). Có một nghệ thuật để viết mã thử nghiệm , tìm hiểu nó. Hãy là một tấm gương tốt cho các nhà phát triển đồng nghiệp của bạn.

Một phần là tôi đang giảng cho chính mình ở đây, bởi vì tôi làm ít hơn những thứ này hơn tôi biết tôi nên làm.