Một số thực hành tốt trước khi kiểm tra mã nguồn là gì? [đóng cửa]

Nhóm của tôi sử dụng Team Foundation Server để kiểm soát nguồn và hôm nay tôi đã sửa một số lỗi và ứng dụng kiểm tra khói trước khi tôi kiểm tra nhưng tôi quên bình luận một số mã. (Mã này làm cho UI hơi lạ một chút.)

Tôi muốn biết những thực tiễn tốt nào có trước khi kiểm tra mã - tôi không muốn mắc lỗi này nữa.

Một điều tôi có thói quen làm là luôn luôn nhìn vào sự khác biệt của mỗi tệp tôi sắp kiểm tra, ngay trước khi tôi kiểm tra chúng.

Bạn không bao giờ nên đăng ký nhận xét mã. Nếu bạn có mã cần bình luận trước khi đăng ký, bạn đang làm sai.

Đối với quy tắc:

1. Nhận sớm nhất
2. Khắc phục xung đột hợp nhất

3. Xây dựng

   3.1 Sửa lỗi xây dựng

4. Chạy thử nghiệm

   4.1 Sửa các bài kiểm tra bị hỏng

5. Chuyển đến 1 (cho đến khi không có gì mới để nhận)

Chỉ kiểm tra khi tất cả các bước hoàn tất.

Xem khiêu vũ check-in .

Thực hành tốt khác:

• Xem lại danh sách các tệp cần đăng ký để đảm bảo chúng là các tệp dự kiến.
• Xem lại các thay đổi cho từng tệp (xóa / bổ sung / khác)

Tôi không cố gắng để có quá nhiều pantsweasel ở đây, nhưng giả định trong câu hỏi này (và tất cả trừ một trong những câu trả lời) chủ yếu áp dụng cho các VCS tập trung, như TFS, SVN, Perforce, v.v ...
Đủ rồi OP đang sử dụng.

Tuy nhiên, mặt khác, khi sử dụng DVCS (như Mercurial và Git), bạn thường không nên chờ đợi để kiểm tra và hầu hết những điều được đề cập trong câu trả lời - chẳng hạn như diffs, get mới nhất, hợp nhất, v.v. - không cần thiết . Ngay cả những thứ như đánh giá mã và kiểm tra cũng tốt hơn để thực hiện sau khi đăng ký (mặc dù có lẽ trước khi đẩy, tùy thuộc ...)
Một ngoại lệ tôi thấy ở đây (cho đến nay) là liên kết với một mục công việc. Tất nhiên, nhận xét về việc đăng ký cũng tốt ...

Ba điều mà tôi không thấy trong các câu trả lời khác:

Bao gồm các tệp mới

• Tìm kiếm các tệp mới không phải là một phần của thay đổi của bạn
• Có thể cụ thể đối với các SCM như Perforce - bạn phải nói với nó mọi thứ thay đổi.

Hoàn nguyên các tệp không thay đổi

• Tôi ghét khi tôi nhìn vào những thay đổi của người khác và có một người thay đổi với chín tệp nhưng chỉ có ba trong số đó đã được sửa đổi.
• Tôi cũng hoàn nguyên các tập tin với khoảng trắng hoặc thay đổi vô nghĩa.

Kiểm tra cam kết đã gửi của bạn

• Hãy chắc chắn rằng bản dựng vẫn xanh sau khi bạn cam kết.
• Tôi đã từng có một máy thứ hai mà tôi sẽ đồng bộ hóa, xây dựng và chạy sau các cam kết của mình để nếu có sự cố, tôi có thể dễ dàng nhảy vào và sửa nó.

Hai điều khi tôi sử dụng Git:

Cam kết nguyên tử:

• Chỉ giai đoạn thay đổi chức năng cá nhân cho cam kết.
• Hãy cam kết càng nhỏ càng tốt. Làm cho chúng dễ dàng để vá, hoàn nguyên và hiểu.
• Tôi sử dụng git add --patchđể chia sự thay đổi của tôi thành nhiều phần nếu cần thiết.

Xem khác biệt trong khi tóm tắt

• Tôi luôn đăng ký git commit --verboseđể tôi có thể thấy sự khác biệt về sự thay đổi của mình trong khi tôi đang gõ tin nhắn cam kết của mình. (Hoặc tôi sử dụng git-vim đã vá của mình để hiển thị khác.)
• Điều này làm cho nó dễ dàng hơn nhiều để trải qua các thay đổi của bạn và mô tả toàn bộ cam kết. Thỉnh thoảng, tôi bắt gặp những thay đổi ngoài ý muốn ở giai đoạn này. (Mô tả sự thay đổi của bạn giúp bạn suy nghĩ về nó.)

Một vài mục 'thực hành tốt' mà tôi thi hành trên các máy chủ của nhóm tôi khá dễ dàng. Đầu tiên, trước khi bạn đăng ký, bạn phải luôn nhận được bản mới nhất và chạy bản dựng cục bộ, để đảm bảo rằng không có ai khác kiểm tra bất cứ thứ gì mà mã của bạn sẽ đụng độ. Ngoài ra, hãy quan tâm đến bất kỳ xung đột mã nào trên máy cục bộ của bạn chứ không phải máy chủ. Khi mã của bạn, với mã mới nhất được tải xuống, đã được xác nhận để xây dựng và hoạt động đúng, bạn đã sẵn sàng cho bước tiếp theo. Chạy bất kỳ kiểm tra tự động nào sau đó bắt đầu đăng ký của bạn để đảm bảo chúng vẫn hoạt động bình thường. Sau đó, chỉ để chắc chắn, nhận được mới nhất một lần nữa.

Với tư cách là Quản trị viên TFS, có thể thực thi nhận xét về tất cả các đăng ký. Tôi khuyên bạn nên luôn luôn đưa ra nhận xét đăng ký cho công việc của mình bất kể nó có được thi hành hay không. Nếu bạn có tùy chọn để làm như vậy, thực thi nó. Ít nhất hãy chắc chắn rằng các nhận xét là một bản tóm tắt chung về những gì bạn đã thay đổi kể từ lần cuối cùng bạn kiểm tra mã của mình. Bằng cách đó, nếu có sự cố, bạn có thể xem qua các đăng ký và xem, đại khái, những gì đã được đã thay đổi trong đăng ký đó. Nó làm cho việc gỡ lỗi một bản dựng bị hỏng dễ dàng hơn nhiều.

Ngoài ra, nếu bạn có đặc quyền Quản trị viên TFS, hãy thực thi các bản dựng khi đăng ký (để đảm bảo mọi người khác biết ngay nếu đăng ký của họ phá vỡ thứ gì đó) và bạn có thể thiết lập máy chủ để thực hiện đăng ký kiểm soát ( nếu mã được kiểm tra phá vỡ bản dựng, máy chủ sẽ từ chối nó) hoặc đơn giản là bạn có thể yêu cầu nó tạo ra một lỗi và gán nó cho bất kỳ ai phá vỡ bản dựng.

Có một vài tùy chọn khác mà bạn có thể bật hoặc tắt để giữ mọi thứ theo thứ tự tốt hoặc đề xuất với Quản trị viên TFS của bạn để bật để giữ mọi thứ tốt đẹp và sạch sẽ ... nhưng chúng chủ yếu là ưu tiên

Tìm kiếm và thay thế các từ chửi rủa ;-)

Nếu bạn đang kiểm tra từ Windows, hãy kiểm tra xem mã của bạn không có các ký tự ^ M vô hình đó - các trình soạn thảo trong UNIX thường đưa ra lỗi / cảnh báo vì nguyên nhân đó.

Ngoài ra, hãy thử và thay thế các tab - những người dùng khác nhau cuối cùng sẽ thấy các tab khác nhau một số có 4 khoảng trắng, một số 8 và không tốt cho khả năng đọc mã.

Cách tiếp cận tốt nhất IMHO là có một tập lệnh được xác định trước kiểm tra mã của bạn theo các nguyên tắc mã hóa của tổ chức của bạn. Tải các hệ thống kiểm soát nguồn có chức năng này.

Tại công ty của tôi, chúng tôi sử dụng đánh giá đăng ký. Chúng không cần phải chi tiết, nhưng chỉ cần cho ai đó thấy sự khác biệt trong sự thay đổi của bạn và nói chuyện với họ đôi khi sẽ làm nổi bật lỗi đánh máy kỳ lạ mà bạn đã bỏ qua trong bài kiểm tra.

Máy chủ kiểm soát nguồn của chúng tôi sẽ không cho phép bạn đăng nhập trừ khi bạn ghi chú tên của người đánh giá trong các nhận xét (dưới dạng! Tên viết tắt, ví dụ! BW nếu Bruce Wayne đã đánh giá của bạn). Người đánh giá nhận được một email lưu ý rằng họ đã giúp xem xét. Điều này là mở để khai thác rõ ràng nhưng dường như hoạt động khá tốt.

Bất cứ khi nào có thể, tôi muốn liên kết một đăng ký với một mục công việc. Điều này cung cấp cho bạn một số thông tin theo ngữ cảnh về TẠI SAO điều này đã được thay đổi, không chỉ là CÁI GÌ đã được thay đổi. TFS có một hệ thống theo dõi mục công việc khá tốt, vì vậy việc này khá đơn giản để làm tại thời điểm nhận phòng.

(điều này ngoài việc xem xét sự khác biệt của những thay đổi của tôi)

Một điều nhỏ tôi làm là không kiểm tra các tập tin chưa thực sự thay đổi. Những tập tin này có thể đã được sửa đổi một cách vô tình, hoặc có thể có liên quan đến việc tái cấu trúc đã được khôi phục hoặc được thực hiện bằng cách khác.

Bằng cách này, tập thay đổi của bạn (được liên kết với một mục công việc) chứa chính xác các tệp cần thiết để đáp ứng mục công việc.

Để kết hợp tất cả các câu trả lời ở đây và đưa ra một danh sách kiểm tra đầy đủ

1. [check in / check out] bạn không nên đăng nhập trực tiếp vào luồng mà người khác đang làm việc. Bạn nên có chiến lược truyền phát: ví dụ: mỗi nhà phát triển một luồng mà bạn có thể đăng ký và kiểm tra độc lập mà không làm phiền người khác: công việc của bạn sẽ được an toàn nhưng trong luồng phát triển của riêng bạn vì vậy [chỉ trong luồng phát triển của riêng bạn]. Với mỗi kiểm tra, bạn liên kết nó với một bản ghi thay đổi để các thay đổi của bạn là nguyên tử chống lại thay đổi đó được gọi là bộ thay đổi (để bạn có thể phân phối các lỗi / rfc riêng lẻ, v.v ... mà không phải cung cấp 'mọi thứ').

2. [sau đó rebase với luồng nhóm của bạn] có nghĩa là bạn nhận được các thay đổi từ những người khác trong luồng của riêng bạn. Trong quá trình hoạt động đó, bạn có thể thấy trong hộp thoại hợp nhất tất cả các "khác biệt" và đi qua chúng hoặc ... nếu có hàng ngàn và / hoặc bạn đang sử dụng không phải mã mà còn ví dụ như các mô hình dữ liệu / dự án siebel, v.v ... sáp nhập không tầm thường, sáp nhập thủ công tầm thường và tự động tầm thường, loại cuối cùng chứa những khó khăn. Hãy nhớ rằng bạn vẫn đang làm việc trong luồng của riêng bạn.

3. [rebase hoàn thành] Nếu tất cả đều ổn thì hãy kiểm tra tất cả các thay đổi bạn vừa nhận được từ luồng nhóm: luồng của riêng bạn hiện đã được cập nhật

4. [phân phối] bây giờ giao công việc của bạn cho luồng nhóm. NẾU bạn không muốn phân phối mọi thứ, bạn cũng có thể chọn, ví dụ 1 RFC cụ thể với các phiên bản tệp cụ thể đó hoặc một tập hợp / lỗi của RFC đã được giải quyết.

5. [phân phối thử nghiệm] sẽ ổn thôi nhưng vì có thể có ai đó trong khi đó cũng đã chuyển giao: bạn có thể kiểm tra xem công việc của bạn có hoạt động với những thay đổi mới nhất trên luồng nhóm hay không. Với các hộp thoại hợp nhất cho thấy sự khác biệt.

6. [hoàn thành phân phối] hoàn thành phân phối của bạn và công việc của bạn hiện đang trong luồng nhóm.

Để làm cho nó phức tạp hơn: Vì vẫn có khả năng công việc bạn đã giao = ok NHƯNG bạn đã làm việc trên một phiên bản tiếp theo, bạn nên luôn luôn cơ sở sau khi phân phối và chỉ ra đường cơ sở nào được người dùng khác ưu tiên từ chối . Điều đó đảm bảo rằng các nhà phát triển khác nhận được một đề xuất chứ không phải phiên bản mới nhất trên luồng (nếu bạn đang làm việc trong kịch bản đó). Đó cũng là một kiểm tra ba sao cho ngay cả khi các phiên bản mới nhất trong luồng nhóm là "xấu" thì chúng vẫn không phải là phiên bản mà người khác phản đối hoặc nhìn vào và trình quản lý cấu hình của bạn có thể hợp nhất phiên bản trước với phiên bản tiếp theo để hoàn tác giao hàng của bạn.

• câu trả lời từ histumness xảy ra 2 lần: ở bước 2 và 6
• câu trả lời từ Oded khi nhảy check-in: idem nhưng thêm một lớp phân phối và rebase khi check in / check out để đảm bảo bạn làm việc tách biệt và các lỗi luôn có thể dễ dàng được gỡ bỏ ngay cả trong các giai đoạn sau
• câu trả lời từ Guildsbounty đã trả lời: nhận mới nhất là bước 2. Đối với bản dựng: nó thực sự phụ thuộc vào việc bạn CÓ bản dựng ... trong thế giới của tôi, bạn có đầu vào từ mô hình dữ liệu, tài liệu từ, bảng yêu cầu, dữ liệu cấu hình từ thông tin, siebel, vv .., và cũng có mã java, mã .net, v.v ... tất cả nên hòa trộn với nhau. Vì vậy, không có "bản dựng" thực sự ở đây mà còn tích hợp cao hơn tùy thuộc vào việc bản thân đó, ví dụ bản dựng từ "mã" của bạn tích hợp với tất cả các phần còn lại vì bạn không thể biết chắc đó có phải là nội dung tích hợp hay không và tùy thuộc vào môi trường thử nghiệm của họ có thể được biên dịch công cụ là cần thiết hoặc tại các đợt giao hàng cao hơn một bản dựng khác vì nó cần thứ gì đó từ một nhóm khác.
• câu trả lời từ Guildsbounty về nhận xét và yêu cầu: tôi nghĩ mọi môi trường mà bạn không tích hợp PHIÊN BẢN và Thay đổi trong các bộ thay đổi (và loại: lỗi, RFC, hotfi) chưa trưởng thành. Tôi nghĩ rằng sự hỗn loạn của nó nếu bạn không thể tự động hóa ghi chú phát hành với số lượng lỗi và rfcs được gửi có thể nhấp qua các phiên bản chính xác được chạm vào (ví dụ: phiên bản 1 và phiên bản 3 của hello.c rất có thể được phân phối nhưng phiên bản 2 không nên được gửi vì những thứ trong đó sẽ là một phần của bản phát hành sau nhưng một số noob đã đưa nó vào) (vì vậy nó có nghĩa là một quyết định thủ công NẾU bạn cũng muốn đưa ra phiên bản 3 của lời chào. c NHƯNG lấy phiên bản 3 ra có nghĩa là bạn cũng phải loại bỏ tất cả các phiên bản khác bị RFC / khiếm khuyết đó chạm vào, do đó bạn cần có thể dễ dàng và nhanh chóng với một công cụ để loại bỏ hoàn toàn) (ngay cả khi nhiều nhà phát triển làm việc trên các phần của cùng một RFC) nhưng ít nhất bạn cần những thứ xung quanh nó để quyết định về nó, v.v ...). Tài liệu bổ sung luôn tiện dụng nhưng bằng cách liên kết các bộ thay đổi, bạn sẽ có được vòng tròn đầy đủ: một phiên bản <- một bộ thay đổi <- các mục công việc <- một vé / rfc / khiếm khuyết <- một yêu cầu. Ý nghĩa: bạn biết những yêu cầu nào được cung cấp đầy đủ hoặc hoàn toàn: một yêu cầu có nhiều lỗi RFC hoặc lỗi hoặc bất cứ điều gì. RFC có nhiều mục công việc cho nhiều người. mục công việc đó tương ứng với một tập thay đổi tồn tại của một tập hợp các phiên bản (ví dụ: phiên bản 1 và 3 của hello.c trên luồng tích hợp không phải là phiên bản 1,
• nhận xét từ luis.espinal: không phá vỡ bản dựng được kiểm tra hai lần trong rebase và phân phối vẫn ... có các bản phân phối cao hơn cho 'người quản lý phát hành và người xây dựng', những người sẽ xem các bộ thay đổi và đường cơ sở làm thông tin của họ. "Không bao giờ làm việc trực tiếp trên nhánh chính" có, cấu trúc luồng có thể lớn hoặc đơn giản nhưng về bản chất: các nhà phát triển có luồng riêng, họ phân phối đến luồng nhóm phân phối đến luồng phát hành. -> sao cho việc giao hàng từ tất cả các nhóm (ví dụ: nhóm tài liệu, nhóm yêu cầu, nhóm phát triển,

Trong ví dụ của bạn, bạn đưa ra rằng bạn quên nhận xét mã. Sai lầm xảy ra. Hệ thống quản lý cấu hình xung quanh nó sẽ chăm sóc nó. Nó thực sự có thể là một ví dụ, hàng ngàn thay đổi xuất hiện và "xây dựng" và "tích hợp" diễn ra trong một hệ thống phân cấp các luồng trên các máy chủ khác nhau được xâu chuỗi và xử lý kịp thời. Vì vậy, ngay cả sau 5 tháng, mã nhận xét của bạn đã được kiểm tra trên máy chủ tích hợp vì mã của bạn cần tích hợp với các mã và hệ thống khác, vẫn có thể gỡ bỏ bộ thay đổi của bạn và vẫn tiếp tục. Vì vậy, thực hành tốt nhất là ít nhiều ở cấp độ cao hơn. Thiết kế tổng thể của các luồng quản lý cấu hình nên chăm sóc nó. Đối với các nhà phát triển cá nhân, cách thực hành tốt nhất là xác thực / kiểm tra đơn vị. Nhưng từ bức tranh lớn đến "

Một số điều sau đây áp dụng nhiều hơn các cách khác (hoặc ở các dạng khác nhau) tùy thuộc vào SCM của bạn, vì vậy họ sẽ thực hiện:

1. Đừng phá vỡ bản dựng - chỉ kiểm tra mã biên dịch.
2. Nhận xét đăng ký của bạn (và có thể là kiểm tra của bạn nếu SCM của bạn cung cấp cho bạn tùy chọn đó.)
3. Đừng để những thứ không được kiểm tra trong thời gian dài.
4. Kiểm tra thường xuyên (vài lần một ngày nếu có thể.)
5. Nhãn có ý nghĩa.
6. Dán nhãn thường xuyên.
7. Không bao giờ làm việc trực tiếp trên chi nhánh chính.
8. Mỗi bản phát hành để sản xuất phải có nhãn riêng (và một nhánh chỉ đọc ngoài nhánh chính nếu có thể). Khi có thể làm tương tự cho các bản phát hành thử nghiệm UAT / Integration / Pre-sản xuất.
9. Bạn sẽ có thể xây dựng chính xác những gì nó được sản xuất từ ​​những gì có trong SCM của bạn và từ một nhãn hiệu.

LƯU Ý : một số mục ở trên có vẻ khá rõ ràng, nhưng bạn sẽ không tin có bao nhiêu người thực sự làm việc trên nhánh chính hoặc thay đổi sản xuất trước rồi sau đó tạo thủ công để điều khiển phiên bản ... trực tiếp trên nhánh chính. .. và với nhãn. Ngọt như mật lên men trộn với nước ép nách chưa rửa ... ừ, như thế.

Có một danh sách kiểm tra cá nhân. Bắt đầu nó trống khi bạn lộn xộn, tại một mục. Khi nó trở thành bản chất thứ hai loại bỏ nó khỏi danh sách.

Chạy thử nghiệm. Nếu họ vượt qua hãy kiểm tra nó. Nếu bạn làm hỏng và một số thứ vượt qua các bài kiểm tra, sau đó viết một bài kiểm tra.

Chúng tôi làm như sau ...

1. Kiểm tra - Chúng tôi muốn đảm bảo rằng nó hoạt động. Ít nhất, chúng tôi muốn biết rằng nó không phá vỡ bất cứ điều gì.

2. Đánh giá mã, hoặc ít nhất là kiểm tra bạn bè - Đây là một cách tuyệt vời để đảm bảo rằng kiến ​​thức được lan truyền xung quanh và mọi người luôn được cập nhật. Nó cũng giúp bắt lỗi trước khi kiểm tra mọi thứ.

3. Gửi thông báo trước - Thông báo trước được gửi đến nhóm trước khi đăng ký. Mục đích không chỉ là để cho người khác biết những tập tin hoặc khu vực nào đang thay đổi, mà nó còn giúp họ cảnh giác (nếu họ chọn thông báo) trong trường hợp những thay đổi đó dự kiến ​​sẽ ảnh hưởng đến họ.

4. Vài giờ sau khi gửi thông báo trước, việc đăng ký được thực hiện và nhóm được thông báo qua email. Mọi người trong nhóm có thể biết khi nào công việc cụ thể về lỗi hoặc tính năng được thực hiện.

5. Một bản sao của thông báo đăng ký được dán vào bản ghi sửa lỗi liên quan đến lỗi hoặc tính năng. Khi tìm kiếm thông qua các bản ghi, chúng tôi thấy rằng nó rất tiện dụng để có ý tưởng về những gì sửa chữa / tính năng đòi hỏi.

Chạy thử nghiệm đơn vị của bạn, bạn đã rất siêng năng làm việc. Màu xanh là tốt.

Đảm bảo mã của bạn được định dạng đúng (ví dụ: đối với Java: chọn mã của bạn và nhấn Ctrl-Shift-F trong Eclipse). Nhưng hãy cẩn thận làm tương tự cho toàn bộ tài liệu.

Luôn luôn, luôn luôn, luôn luôn , kiểm tra xem mọi thay đổi bạn đã thực hiện không phá vỡ bản dựng. Đặc biệt là những thay đổi nhỏ có vẻ tầm thường.

Khi tôi đã thực hiện một thay đổi rất nhỏ mà tôi không nghĩ sẽ gây ra vấn đề gì ngay trước khi tôi nghỉ làm vào cuối tuần. Chắc chắn, sự thay đổi nhỏ đó đã phá vỡ bản dựng và không có hoạt động thử nghiệm hàng đêm nào được thực hiện cho dự án của chúng tôi. Người đứng đầu Q & A không quá vui về điều đó, và đúng như vậy.

Tìm kiếm các phần của các thay đổi của bạn có thể đi theo đơn vị độc lập.

Thông thường, vào thời điểm tôi có một bản sửa lỗi làm việc hoặc nâng cao mã, có khá nhiều thay đổi. Một số trong số chúng là cụ thể cho sự thay đổi hành vi mà tôi sẽ thực hiện; những người khác là tái cấu trúc tôi đã làm để làm cho sự thay đổi đó sạch hơn.

Tôi thích kiểm tra riêng từng cấu trúc lại, với mô tả thay đổi của riêng nó, như thế này:

Tái cấu trúc: Đổi tên X thành Y

X có ý nghĩa trước đây bởi vì ... nhưng bây giờ nó phải là Y. Điều này có liên quan đến công việc cho vấn đề # 9.

Sau đó, một khi mỗi lần tái cấu trúc tốt được kiểm tra, sự thay đổi hành vi cuối cùng thường không đáng kể.

Ngoài ra, một số thay đổi ảnh hưởng đến nhiều dòng mã nhưng không thú vị lắm, trong khi các thay đổi khác rất cục bộ nhưng có tác động quan trọng. Nếu những thay đổi này được kiểm tra cùng nhau, có thể khó đọc các khác biệt. Vì vậy, tôi giữ chúng riêng biệt.

Sau này, khi ai đó đang đọc qua lịch sử thay đổi, rõ ràng mọi thứ đã đi đến tình trạng hiện tại như thế nào và tại sao họ lại theo cách này. Việc thay đổi hành vi của tôi cũng không quan trọng vì nó không bị rối với hàng tấn chỉnh sửa khác.

Làm những gì bạn sẽ làm khi trả lại một cái gì đó bạn đã mượn từ ai đó. Hãy chắc chắn rằng nó sạch sẽ và trong tình trạng tốt. Nếu bạn đã làm một mớ hỗn độn, hãy chắc chắn làm sạch trước khi trả lại mã cho chủ sở hữu của nó (trong hầu hết các trường hợp, chủ nhân của bạn).

Tôi giữ một repo hg địa phương cho công việc của tôi.

• Bất cứ khi nào tôi kiểm tra một cái gì đó, tôi nhìn qua diff và đảm bảo rằng tất cả các thay đổi đều được chấp nhận.
• Tôi cố gắng lưu ý các tính năng chính của đăng ký.
• Tôi cố gắng giữ mỗi kích thước cam kết cho một tính năng chính.

Tôi không khẳng định đây là những thứ tốt nhất, nhưng chúng làm việc cho tôi.

Khi tôi viết mã mà tôi biết không có nghĩa là phải kiểm tra, tôi thêm một dòng trước khi nó chứa "// TEMP:" và sau đó bằng "// END TEMP.". Điều này, cùng với việc thực hiện tìm khác biệt trước khi đăng ký, hứa rằng tôi sẽ không kiểm tra mã đó do nhầm lẫn.

Kiểm tra kỹ tất cả mọi thứ bạn thêm hoặc thay đổi. Hãy thử mọi trường hợp có thể bạn có thể nghĩ ra để thử. Đừng để thử nghiệm cho QA. Nếu tôi có một chiếc bánh sandwich cho mỗi lần tôi thực hiện một số thay đổi nhỏ, và sau đó thử một số trường hợp thử nghiệm để đảm bảo an toàn và ngay lập tức thấy có vấn đề, tôi sẽ có rất nhiều bánh sandwich. Tôi thường nói to với bản thân mình "Tôi thực sự rất vui vì đã thử điều đó ..."

Bạn nói UI trở nên lạ sau khi bạn thay đổi. Nếu bạn chỉ chạy chương trình và xem UI trước khi đăng nhập, bạn có nhận thấy vấn đề không?