Khi bạn đến vào buổi sáng, bạn thấy rằng phần mềm của bạn không hoạt động nữa, mặc dù nó đã hoạt động khi bạn rời khỏi tối hôm qua.

Bạn làm nghề gì? Bạn kiểm tra cái gì trước? Bạn làm gì để hết giận dữ và bắt đầu giải quyết vấn đề của mình? Bạn có đổ lỗi cho đồng nghiệp của mình và trực tiếp đến với họ? Có thể làm gì để tránh rơi vào tình huống như vậy?

Các nghi phạm thông thường là:

• Bạn nghĩ rằng nó đã làm việc ngày hôm qua, nhưng sau một ngày làm việc, bạn đã quá mù quáng để nhận ra rằng nó không hoạt động.

• Sáng nay bạn không còn có thể tham khảo những gì trong bộ nhớ cache IDE ngày hôm qua.

• Máy trạm đã khởi động lại đêm qua hoặc hoạt động bảo trì hàng đêm đã xóa các thư mục / tmp.

• Một cái gì đó đã thay đổi trong cơ sở mã: kiểm tra xem ai đó (có thể là chính bạn) đã cam kết thay đổi giữa lần biên dịch cuối cùng của ngày hôm qua và lần biên dịch cuối cùng của bạn ngày hôm nay.

• Một cái gì đó đã thay đổi trong các thư viện hỗ trợ: kiểm tra xem các thư viện đó đã được biên dịch lại hay nâng cấp chưa. Nguyên nhân có thể nằm trong dự án cho các thư viện cụ thể hoặc bên ngoài nếu một phiên bản mới của gói độc lập rõ ràng đã được triển khai.

• Một cái gì đó đã thay đổi trong môi trường thử nghiệm: phiên bản mới của máy ảo, còn sơ khai đã được sửa đổi, thay đổi trong máy chủ cơ sở dữ liệu từ xa ...

• Một cái gì đó đã thay đổi trong chuỗi biên dịch: những thay đổi trong Makefiles, phiên bản mới của IDE, của trình biên dịch, của các thư viện tiêu chuẩn ...

1) Nếu hôm nay nó không hoạt động, nó cũng không hoạt động.

Bạn nghĩ rằng nó đã làm việc, nhưng nó không phải là.

2) Có một vấn đề, và nó phải được giải quyết .

Đừng nghĩ về người chịu trách nhiệm cho việc này hoặc đổ lỗi cho người khác.

Nếu không có gì thay đổi giữa ngày hôm qua và hôm nay (như tôi đoán là đang đọc câu hỏi của bạn), điều đó có nghĩa là bạn nên làm tốt hơn việc kiểm tra mã của mình trước khi thực sự nói rằng nó hoạt động.

Để tránh tình trạng này, bạn phải thực hiện Kiểm tra và Gỡ lỗi thích hợp .

Xác định "làm việc" và kiểm tra ranh giới của các thói quen mã của bạn.

• Cố gắng trở thành một trong những người dùng sẽ sử dụng các chức năng mã hoặc chương trình của bạn.
• Đẩy mã của bạn đến giới hạn cho phép và hơn thế nữa, và thực sự kiểm tra xem nó có bị hỏng không.

Một cách để làm điều này là có một bộ kiểm tra mở rộng tự động chạy vào ban đêm, để ngày hôm sau bạn có thể kiểm tra xem có vấn đề gì không và khắc phục sự cố.

Cố gắng tìm ai đó để vượt qua sự đổ lỗi là không có kết quả và không giải quyết được vấn đề. Đừng làm điều đó.

Nếu một cái gì đó hoạt động vào ngày hôm qua và không hoạt động ngay bây giờ, thì bạn có hành vi không xác định (như điều kiện chủng tộc) và việc nó hoạt động vào ngày hôm qua chỉ là may mắn, hoặc có gì đó đã thay đổi giữa lúc đó và bây giờ, và bạn cần tìm hiểu xem nó là gì Là.

Làm thế nào chính xác bạn tìm ra trường hợp nào và cách khắc phục tùy thuộc vào tình huống cụ thể, nhưng nó luôn giúp phương pháp loại bỏ nguyên nhân, tức là không thay đổi 5 điều cùng một lúc và ngừng tìm kiếm nếu điều đó có ích - tìm hiểu xem điều gì cụ thể gây ra sự cố và có thể viết ra cách khắc phục để bạn có thể tìm kiếm khi nó xảy ra 3 tuần nữa.

Sử dụng các công cụ chẩn đoán thích hợp (trình gỡ lỗi, trình lược tả, công cụ phân tích mạng) cũng có thể tạo ra sự khác biệt lớn.

Tôi đã làm việc với mã dường như thay đổi chỉ sau một đêm và sau một thời gian tôi đã đi đến kết luận rằng đó là do các pixie độc ​​ác bò vào codebase của tôi vào ban đêm và thay đổi mọi thứ theo cách bất chấp thực tế nó đã hoạt động vào ngày hôm qua, bây giờ nó đã hoạt động hoàn toàn không hoạt động. Thật vậy , theo phong cách Schroedinorms cổ điển , không chỉ bây giờ nó không hoạt động, rõ ràng rõ ràng rằng không có cách nào mà nó có thể có.

Theo thời gian, tôi đã nhận ra rằng thật ra có thể pixies không liên quan gì đến nó và có lẽ "thời gian để về nhà, điều đó sẽ đủ tốt", bản dựng cuối cùng không nhận được sự kiểm tra và chú ý chi tiết mà có lẽ nó xứng đáng .

Giả định đầu tiên của tôi khi tôi gặp phải điều này vào buổi sáng là có lẽ đó là lỗi của tôi vì tôi thường là người chịu trách nhiệm cho các tính năng hoặc góc của phần mềm mà tôi đang làm việc. Giả định thứ hai của tôi là bây giờ tôi cũng có thể lấy cà phê đó. Nếu đó không phải là thứ gì đó rõ ràng mà một con khỉ có thể tìm ra (mà đôi khi nó là như vậy) thì rất có thể tôi đã xoay sở trong một phiên bản cũ của một thư viện, nhầm lẫn cuộn lại một tập tin không cần phải cuộn trở lại hoặc có một cái gì đó được lưu trữ ở đâu đó đưa nó vào bản dựng mà không kiểm tra nó. Trải qua hoạt động Kiểm soát nguồn gần đây của tôi có xu hướng tiết lộ những điều tôi đã làm, việc dọn dẹp bản dựng thường loại bỏ các phiên bản được lưu trong bộ nhớ cache.

Đôi khi nó thực sự không liên quan gì đến tôi - ai đó đã cập nhật một phụ thuộc mà không đề cập đến nó, WindowsUpdate đã cài đặt một cái gì đó thay đổi môi trường để mã của tôi không hoạt động; có rất nhiều khả năng nền tảng, nhưng thường thì đó là trường hợp điều khiển và chấp nhận rằng, giống như hầu hết mọi người, về cơ bản tôi là một thằng ngốc.

Sử dụng kiểm soát phiên bản. Làm khác, hoặc sử dụng chức năng đổ lỗi của VCS của bạn.:

• diff: Mỗi VCS. Cho bạn thấy sự khác biệt của, uhm, các phiên bản khác nhau
• blame: ví dụ git. Cho bạn thấy trên cơ sở từng dòng người đã thay đổi những gì

Nếu không có kiểm soát phiên bản, ngoài việc đó là lỗi của chính bạn hoặc của sếp, bạn có thể xem ngày thay đổi của tệp và có thể xem xét các phương tiện ghi nhật ký của HĐH.

Ngoài ra: Biên dịch lại mọi thứ, đảm bảo cũng biên dịch lại các thư viện phụ trợ.

Tất nhiên: Nếu bạn đã tìm thấy nguồn gốc của lỗi, hãy bình tĩnh, hỏi tại sao một thay đổi được thực hiện, giải thích vấn đề của bạn và đề xuất một giải pháp khiến cả hai bạn hài lòng. Đừng hét vào mặt cô ấy / anh ấy, điều đó sẽ gây độc cho năng suất của bạn.

Nếu không có thay đổi nào cả, đã đến lúc xem những gì đã thay đổi trên hệ thống. Ví dụ, gần đây các máy tính Mac OS đã cập nhật lên phiên bản mới của Apache, điều này đã khiến một số cấu hình không hợp lệ.

Chà, đây là một ví dụ thực tế về mã "đã làm việc ngày hôm qua" chứ không phải hôm nay ... Đó là từ đầu tháng này.

Ứng dụng trong câu hỏi lấy thông tin từ cơ sở dữ liệu theo ngày và hành vi mặc định là lấy dữ liệu cho ngày hiện tại. Điều này hoạt động tốt vào ngày 8 tháng 8, nhưng đã thất bại vào ngày 9. Nó đã không được thử nghiệm sớm hơn thế này. Nó cũng sẽ hoạt động vào ngày 9 tháng 9 và ngày 10 tháng 10 ...

Một manh mối khác là chúng tôi đang ở Vương quốc Anh, cơ sở dữ liệu được đề cập là ở Hoa Kỳ ...

Vì vậy, câu trả lời của tôi cho câu hỏi của bạn về việc cần kiểm tra trước là kiểm tra lại cách bạn định dạng ngày của mình, bởi vì nếu bạn kết hợp các trường ngày và tháng, nó sẽ hoạt động hoàn hảo, nhưng chỉ vào 1 ngày mỗi tháng :-)

Sửa lỗi (tuy nhiên bạn thường làm). Sau đó, nếu bạn tìm thấy ai gây ra nó hãy gửi cho họ một email lịch sự cho họ biết những gì đã sai.

Mỗi lập trình viên đều mắc lỗi và nếu bạn bắt đầu đổ lỗi thì điều đó sẽ gây tác động nghiêm trọng vào lần tới khi bạn làm điều tương tự. (có thể cả lỗi này là của bạn)

Chỉ khi bạn nghi ngờ họ bất cẩn một cách đáng tiếc thì bạn mới có thể giải quyết được một vài lỗi.

... Bạn chạy thử nghiệm hồi quy và tập trung vào những thử nghiệm thất bại.

Thực tế là những gì bạn quên làm ngày hôm qua trước khi rời đi, nó xảy ra.

Bạn không có cái nào? Ok .. bạn đang nói gì vậy? Đổ lỗi ? Chà ... điều đó có thể làm việc, sau đó

Điều đầu tiên cần làm khi một cái gì đó ngừng hoạt động là tự hỏi bản thân - Điều gì khác biệt? Điều gì đã thay đổi?

Khi một cái gì đó làm việc tối qua nhưng thất bại sáng nay, một điều rõ ràng đã thay đổi là - ngày và giờ :)

Tôi sẽ thử và xem liệu có bất kỳ phần logic nào tôi đang làm việc hay không phụ thuộc vào ngày tháng và có thể bị ảnh hưởng bởi thời gian trôi qua. Thật đáng ngạc nhiên bao nhiêu lần đó là nguyên nhân của những vấn đề như vậy.

Nếu thất bại, bạn chắc chắn nên theo dõi những lời khuyên tuyệt vời khác được cung cấp ở đây.

Một câu trả lời ngắn gọn (viết) nhưng khá dài để hiểu ý chính của nó: Tại sao các chương trình thất bại: Hướng dẫn về gỡ lỗi có hệ thống của Andreas Zeller (có vẻ hơi quá hàn lâm nhưng không phải vậy)

Bạn nhìn vào hộp thư của mình sau khi thư được gửi bởi công cụ Tích hợp liên tục khi (các) bài kiểm tra đơn vị không thành công (hoặc trang nhật ký nếu bạn không xem vấn đề cụ thể đó) và xem ai đã đăng ký ngay trước bản dựng đó .

Sau đó đi nói chuyện với anh ấy hoặc cô ấy.

Chỉ có hai lý do có thể khiến mã của bạn thất bại hôm nay, nhưng đã hoạt động vào ngày hôm qua.

Nhìn vào dữ liệu

Có một cái gì đó trong dữ liệu bạn không kiểm tra và hoặc tài khoản. Dữ liệu không được xác thực hợp lệ hoặc lỗi logic không được tiết lộ cho đến khi điều kiện logic bạn không lường trước được xảy ra. Điều này có nghĩa là lỗi đã có ngày hôm qua, nhưng nó đã được ẩn khỏi bạn dưới dữ liệu hợp lệ.

Tôi đã từng có một số mã nhập đơn hàng chạy tốt trong nhiều tuần. Tôi về nhà một ngày, và nó chết. Điều tra vào ngày hôm sau tiết lộ rằng tôi có một lỗi ẩn trong một chuỗi các cuộc gọi chức năng. Trong một ngôn ngữ gõ yếu, tôi đã khai báo một số nguyên khi tôi nên sử dụng một int dài. Ngôn ngữ đã tự động chuyển đổi giữa hai thứ cho đến khi không thể vì số lượng vượt quá số sẽ khớp với một số nguyên. Hệ thống bị lỗi theo số thứ tự 32768.

Nhìn vào những gì đã thay đổi

Nhìn vào những gì đã thay đổi kể từ khi nó hoạt động. Phần CNTT có đưa ra bản cập nhật hệ điều hành không? Có phải một lập trình viên khác sửa đổi mã mà chương trình của bạn sử dụng? Có phải sự cho phép của người dùng đã thay đổi? Thông thường, nếu bạn tìm thấy những gì đã thay đổi, bạn sẽ tìm thấy lỗi.

Chặt nhị phân

hoạt động đặc biệt tốt cho các lỗi JavaScript khó khăn. Về cơ bản nhận xét một nửa mã, xem nếu bạn gặp lỗi, nếu bạn làm điều đó trong một nửa mã đó. Một nửa nó một lần nữa và tiếp tục.

Nếu mã của bạn được đóng gói tốt thì đây là một công cụ tuyệt vời, tiết kiệm thời gian, giảm căng thẳng.

Khi bạn đã tìm thấy mã có tội, thường đáng để cô lập lỗi trên trang thử nghiệm của chính nó.

Và tất nhiên, những gì có thể được thực hiện để tránh ở trong tình huống như vậy?

Giải quyết câu hỏi này, bạn có thể muốn xem xét Tích hợp liên tục (CI) . Nói một cách đơn giản: CI là một quá trình mà các nhà phát triển thường xuyên (nhiều lần trong một ngày) tích hợp và kiểm tra tất cả các mã. Ý tưởng là những thay đổi đối với một mô-đun phá vỡ một mô-đun khác nhanh chóng được tìm thấy.

Trong thực tế, hầu hết các nhóm sử dụng CI sử dụng Máy chủ CI (xem: danh sách của Wikipedia ). Máy chủ CI thường được thiết lập để giám sát kho lưu trữ SCM và bắt đầu xây dựng khi thấy thay đổi. Khi quá trình xây dựng hoàn tất, nó sẽ chạy một loạt các thử nghiệm tự động và đăng kết quả qua e-mail và / hoặc trang web của quá trình xây dựng và thử nghiệm, cùng với những thay đổi gây ra quá trình xây dựng. Hy vọng rằng, khi một cái gì đó phá vỡ bản dựng hoặc thử nghiệm, bạn chỉ có một thay đổi rất nhỏ được xem xét, để nó được giải quyết nhanh hơn.

Có những câu hỏi khác ở đây về việc sử dụng máy chủ CI nào, vì vậy tôi sẽ cho phép bạn tìm thấy chúng quan tâm. Cá nhân tôi là một fan hâm mộ lớn của Jenkins.

[Tôi nên làm gì về những thứ bị phá vỡ.]

Như những người khác đã nói, tìm hiểu những gì đã phá vỡ và cố gắng khắc phục nó. Dành thời gian cố gắng để đổ lỗi là thời gian không giải quyết vấn đề.

Phản ứng tự nhiên của tôi là luôn đổ lỗi cho người khác nhưng qua thời gian, tôi đã nhận ra rằng thường thì tôi là người có lỗi. Ngoài tất cả các ý kiến ​​xuất sắc ở trên, điều quan trọng là bạn phải ghi lại cho mình lý do cuối cùng là gì. Không quan trọng bạn sử dụng Wiki được chia sẻ với các thành viên khác trong nhóm, Twiki riêng, Evernote, sổ nhật ký hay bộ nhớ tốt. Điều quan trọng, tại thời điểm bạn tìm thấy câu trả lời (và muốn quay lại làm việc!) Là ghi lại lý do.

Có lẽ nếu nó không còn hoạt động, bạn đã xác định các triệu chứng của nó không hoạt động, tức là nó bị treo hoặc ném lại một hộp thoại lỗi cụ thể cho người dùng.

Nếu mô tả duy nhất của vấn đề là "nó không hoạt động", điều đầu tiên bạn cần làm là thu thập thêm thông tin về các triệu chứng của vấn đề.

Sau đó, bạn bắt đầu tìm kiếm các nguyên nhân có thể, thông qua nhật ký hoặc cố gắng giải trí vấn đề hoặc kết hợp cả hai - phụ thuộc vào cách hệ thống của bạn được thiết lập tôi đoán.

Sau đó, bạn bắt đầu loại bỏ chúng.

Đó là những gì thường xảy ra khi tôi nghỉ lễ :-)

Nghiêm trọng hơn, trước tiên tôi muốn nói với họ:

• Tôi sẽ xem xét nó để xem những gì sai và những gì có thể là gốc

• Tôi sẽ chạm vào căn cứ sau 30-60 phút khi tôi có cơ hội thấy những gì đang xảy ra

Sau thời gian đó, tôi có thể mạo hiểm ước tính về những gì có thể đã xảy ra và sẽ khắc phục trong bao lâu nếu nó chưa được sửa và nếu có thể, chúng tôi có thể mất dữ liệu nào (nhưng tôi có bản sao lưu tốt, vì vậy điều đó không bao giờ xảy ra hy vọng).

Về phần đổ lỗi:

• nếu đó chỉ là một lỗi đánh máy của đồng nghiệp, thì không cần phải đề cập đến nó: chuyện xấu xảy ra và sự sợ hãi từ con bọ rất có thể đã dạy cho anh ta một bài học và hy vọng, anh ta sẽ không làm lại.

• nếu anh ta cố tình làm điều gì đó tôi đã bảo anh ta đừng (ví dụ: đưa mật khẩu gốc của máy chủ sản xuất cho anh chàng mới và bảo anh ta sửa đổi trực tiếp mà không cần giám sát) (vâng, điều đó đã xảy ra ...), thì tôi phải đề cập đến nó

Nếu các phương pháp theo dõi lỗi thông thường của bạn không hoạt động và mọi thứ đều là một mớ hỗn độn, thì thật tuyệt vời khi có một bản sao lưu mà bạn có thể khôi phục dễ dàng.

Đây là những gì tôi chạy cục bộ, tự động mỗi giờ từ 8 giờ sáng đến 6 giờ chiều:

rdiff-backup /path/to/mystuff /path/to/mybackup

Đơn giản hả?

Nếu bạn phải khôi phục lại bất cứ thứ gì, hãy sử dụng

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

sao lưu dự phòng chỉ lưu trữ các tập tin khác nhau. Bạn có thể sử dụng sao lưu dự phòng trên Linux, mac và giành chiến thắng.

Tất nhiên, đây không phải là bản sao lưu duy nhất của bạn. Nhưng đó là cách cực kỳ dễ dàng và rẻ tiền để có một bản sao lưu cục bộ.

Bây giờ, tôi sẽ không đề xuất đây là phương pháp sửa lỗi thông thường, nhưng nếu mọi thứ khác không thành công, đó là một dự phòng.

Lỗi có thể đã tồn tại, nhưng bị ẩn bởi các yếu tố bên ngoài hoặc các sự cố hệ thống sâu.

Điều này đã xảy ra với tôi. Một lỗi được phát triển giữa 2 bản dựng của dự án của chúng tôi. Theo nghĩa đen, thay đổi duy nhất chúng tôi đã thực hiện là cập nhật lên bản dựng mới hơn của một trong những thư viện cơ bản.

Tự nhiên chúng tôi đổ lỗi cho họ. Nhưng thay đổi duy nhất họ đã thực hiện là cấu trúc lại một số tiêu đề để biên dịch nhanh hơn. Tôi đồng ý rằng không nên phá vỡ hệ thống.

Sau nhiều lần gỡ lỗi, hóa ra vấn đề là một lỗi con trỏ lừa đảo đã tiềm ẩn trong mã của tôi trong nhiều năm . Bằng cách nào đó nó không bao giờ được kích hoạt cho đến khi tái cấu trúc của họ đã thay đổi sự sắp xếp của thực thi.

nó đã hoạt động ngày hôm qua vì nó đã được sử dụng một cách chính xác.

bạn thấy rằng những người khác sử dụng mọi thứ theo cách mà không cho rằng đó là một cách tốt để phá vỡ mọi thứ.

Luôn luôn tốt để cập nhật mã vào đầu ngày vì điều này cho bạn một môi trường thử nghiệm tốt.

Sao lưu!

Tôi thấy việc thiết lập các điểm dừng để tạm dừng và kiểm tra dữ liệu của mình rất hữu ích, để xác định chính xác vị trí và mức độ xấu của nó.