Bạn biết chúng, những lỗi đó KHÔNG có ý nghĩa. Có vẻ như một con gremlin vừa nhảy sâu vào bên trong con chip của bạn và làm hỏng thứ gì đó. Bạn có đi dạo, viết công cụ, gọi một người chú?
Bạn biết chúng, những lỗi đó KHÔNG có ý nghĩa. Có vẻ như một con gremlin vừa nhảy sâu vào bên trong con chip của bạn và làm hỏng thứ gì đó. Bạn có đi dạo, viết công cụ, gọi một người chú?
Câu trả lời:
Đối với những vấn đề thực sự khủng khiếp, chiến lược của tôi thường diễn ra như sau.
Thử nghiệm và google. Hãy tiếp tục cố gắng giải quyết vấn đề. Hầu hết thời gian điều này giải quyết vấn đề trong một giờ hoặc ít hơn.
Vì vậy, nó đã không làm việc. Nghỉ ngơi một lát. Uống cà phê, nói về một cái gì đó không liên quan đến đồng nghiệp. Đẩy vấn đề ra khỏi tâm trí của bạn. Khi bạn nhìn vào vấn đề 5 hoặc 10 phút sau, bạn đang nhìn nó từ một góc độ hơi khác. Hầu hết thời gian này hoạt động.
Trong trường hợp này thì không. Vì vậy, dành 10 - 30 phút để nhìn vào nó. Sau đó gọi cho một đồng nghiệp. Nhưng trước khi bạn làm, hãy thực hiện một số lưu ý; bạn muốn chứng minh vấn đề, tái tạo nó, sau đó liệt kê những điều bạn đã thử, và quan trọng nhất là chứng minh rằng bạn đã thử chúng. Vì vậy, làm một chạy khô đầu tiên. Đặt một số dấu sách trong mã, đóng bất kỳ tài liệu mở thừa nào, v.v ... Bằng cách này bạn có thể tự giải quyết vấn đề hoặc khi bạn chứng minh vấn đề bạn sẽ không lãng phí thời gian của họ.
Hỏi đồng nghiệp của bạn để làm cho bạn chứng minh tất cả các giả định của bạn. Là setter thực sự đang được gọi? Là phương pháp đó thực sự trả lại những gì bạn yêu cầu? Bạn nghĩ rằng đối tượng không phải là null - hãy cho họ thấy nó không phải là null.
Hầu hết thời gian, hoặc là chứng minh vấn đề sẽ khiến bạn nhận ra rằng bạn chưa thử tất cả các khả năng hoặc đồng nghiệp của bạn sẽ thấy lỗi của bạn.
Nếu điều đó không làm việc thì đã đến lúc phải nghiêm túc. Tài liệu chính xác những gì bạn đang cố gắng làm, những gì bạn đã cố gắng và tại sao nó không hoạt động. Gửi email này cho tất cả các đồng nghiệp của bạn. Đăng nó trên SO. Tại thời điểm này, tài liệu nên là một câu hỏi SO hoàn hảo.
Trong khi bạn chờ phản hồi, google google google. Hãy thử mọi hoán vị của câu hỏi bạn có. Mở ra một loạt các tab. Có thể bạn sẽ không nhận được câu trả lời vào thời điểm này, nhưng bạn đang tìm kiếm ý tưởng, khả năng, cách tiếp cận vấn đề khác nhau.
Làm một cái gì đó khác, nếu bạn đã dành 5 giờ cho một vấn đề thời gian của nó để rời khỏi nó cho một ngày khác. Có thể bạn sẽ nhận được một phản ứng hữu ích. Có thể khi bạn tấn công vấn đề vào ngày hôm sau thì điều đó sẽ hiển nhiên.
Nếu không có cách nào hiệu quả, đã đến lúc tìm kiếm một giải pháp khác. Có lẽ bạn có thể sử dụng một phương pháp khác, một công nghệ khác. Có lẽ bạn nên xem xét từ bỏ tính năng này ngay bây giờ. Bạn đang thanh toán cho khách hàng theo giờ? Bạn đang làm việc cho một công ty trên một ứng dụng nội bộ? Bạn cần phải chuyển vấn đề này cho chủ sở hữu và nói với họ "hãy nhìn xem, tôi đã dành x giờ cho việc này và không có tiến triển gì, liệu lợi ích chi phí có đáng không?". Bạn không muốn đến gặp sếp của bạn và nói với họ rằng bạn đã dành 16 giờ cho một vấn đề chỉ để họ quay lại và nói, điều đó không quan trọng, hãy bỏ qua nó cho bản phát hành này. bạn cần tìm ra điều đó sớm hơn
Và nếu điều đó không làm việc? Vâng, lựa chọn duy nhất của bạn là tiếp tục giải quyết vấn đề hoặc tìm kiếm chuyên môn trong ngành. Hãy hỏi các chuyên gia công nghệ trên twitter. Gửi email cho nhà cung cấp công nghệ của bạn.
Thoát Không, không phải việc của bạn! Chỉ cần đứng dậy và về nhà. Bạn đã hoàn thành trong ngày hoặc cuối tuần. 19 lần trong số 20 khi bạn quay lại vấn đề tiếp theo, giải pháp sẽ tự xuất hiện trong vòng một giờ.
Trước khi mười giờ trôi qua, tôi sẽ nhận được sự giúp đỡ.
Một từ, timebox
đặt một khoảng thời gian giới hạn để làm việc với một cái gì đó, và nếu nó không được giải quyết, hãy chuyển sang một thứ khác và quay lại vào ngày hôm sau với một viễn cảnh tươi mới.
Điều đó và một đôi mắt khác, luôn có giá trị hơn bất cứ lúc nào bạn có thể lãng phí khi nhìn chằm chằm vào một cái gì đó.
Tôi sẽ không bao giờ dành quá 45 phút đến một giờ để cố gắng giải quyết một cái gì đó trong một lần ngồi, nó vi phạm luật giảm lợi nhuận.
Giải thích vấn đề cho người khác.
Bằng cách giải thích vấn đề cho người khác, bạn phải làm rõ vấn đề: điều này thường cho phép bạn xem giải pháp.
(Một trong những tạp chí máy tính chuyên nghiệp của Vương quốc Anh đã từng đề xuất bán các tấm bìa cứng kích thước cuộc sống của một lập trình viên cao cấp đặc biệt cho mục đích này.)
Tôi thấy ngủ trên một vấn đề (đôi khi trong một vài ngày) cũng có thể giúp đỡ.
Tôi có một kế hoạch ba bước:
Mỗi giai đoạn là một sự leo thang nếu bước trước thất bại. Hầu như luôn luôn có một cái gì đó hiệu quả khác mà tôi có thể làm việc ở giai đoạn 2.
Bạn có thể thấy nếu thức dậy, đi loanh quanh và suy nghĩ về vấn đề giúp bạn tìm ra giải pháp. Cho dù bạn có thực sự đứng hay tạo nhịp hay không, hãy thử tránh xa máy tính trong khi bạn đang suy nghĩ.
Tôi thường làm một trong ba:
Bất kỳ ai trong ba người đều làm tốt công việc đánh lạc hướng bản thân khỏi tình huống hiện tại. Tôi tìm thấy những phiền nhiễu để cho tiềm thức của tôi nhai một cái gì đó trong một thời gian. Sau một giờ hoặc lâu hơn, bam, có giải pháp :-).
Xây dựng một thử nghiệm Khai thác để nhắm mục tiêu chính xác Khiếm khuyết đó và cô lập nó
Chỉ cần tiếp tục loại bỏ mã tốt .. trong khi nhân rộng các khiếm khuyết. Cho đến khi bạn nhắm mục tiêu chính xác của đoạn mã lỗi. Sau đó theo dõi mã.
Đề nghị đọc: Lập trình viên thực dụng Cụ thể Chương 10: Đạn Tracer
Tất cả những gợi ý này là tuyệt vời. Tuy nhiên, tôi sử dụng một kỹ thuật khá thường xuyên mà tôi không thấy được đề cập. Lập danh sách để sắp xếp suy nghĩ của bạn về vấn đề. Nếu tôi gặp vấn đề đặc biệt khó khăn, tôi thường viết ra nhiều danh sách như: Sự kiện, Giả định, Câu hỏi, Triệu chứng, v.v. Tôi thấy rằng đôi khi trong quá trình tổ chức mọi thứ theo cách này tôi phát hiện ra những giả định mà tôi không nhận ra mình đã có ( điều đó thường trở thành sai), những câu hỏi tôi không nhận ra cần phải hỏi, những hoán vị khác tôi có thể kiểm tra, v.v.
Chỉnh sửa:
Câu trả lời ngắn gọn:
Q: Làm thế nào để bạn giải quyết các lỗi thực sự kỳ lạ khiến bạn bối rối trong hơn 10 giờ?
Trả lời: Hãy chắc chắn rằng chúng không bao giờ xảy ra: hiểu thiết kế của bạn, biết mã của bạn, tìm hiểu cách sử dụng trình gỡ lỗi của bạn.
Giải trình:
"Trường hợp có vẻ như một con gremlin vừa nhảy sâu vào bên trong con chip của bạn và làm hỏng thứ gì đó"
Điều này không bao giờ nên xảy ra. Nếu đó là mã của bạn, bạn nên biết rõ nguyên nhân gây ra lỗi trước khi sửa lỗi.
Hơn nữa, khi bạn viết mã của mình, bạn sẽ biết nó ở đâu và tại sao nó có khả năng thất bại.
Đã nói rằng - hỏi một người ngang hàng, đăng bài trên SO, rút lại và quay lại các bước của bạn và nghỉ ngơi - tất cả các đề xuất được đề cập ở trên sẽ giúp ích.
Một điều khác, là bạn phải biết các công cụ của mình - bộ công cụ gỡ lỗi của bạn. Ghi nhật ký tin nhắn tại các điểm nghi ngờ trong mã của bạn, kiểm tra ngăn xếp cuộc gọi của bạn một cách cẩn thận, sử dụng các điểm dừng và đồng hồ có điều kiện, v.v. Kỹ năng gỡ lỗi không phải là tính năng bổ sung - chúng là một phần của lập trình.
Tôi đã có một vấn đề tương tự, một lỗi bộ nhớ rõ ràng trong Objective-C, mà tôi đã phải vật lộn trong nhiều giờ. Nhưng sau đó tôi và các đồng nghiệp của tôi vừa đi dạo ăn trưa, và tôi đã giải thích vấn đề (và một điều đặc biệt phải làm với việc khử lưu huỳnh một đối tượng trong phương thức init của nó), và về cơ bản là tôi đã giải thích toàn bộ vấn đề.
. nó cũng vậy).
Đi tắm.
Bất kỳ người hâm mộ Rodney McKay ?
Nghiêm túc, mặc dù, nếu có một điểm chung trong số tất cả những câu trả lời này, thì đó là nghỉ ngơi và làm một cái gì đó khác .
Tôi thích nghĩ về nó như đưa vấn đề vào tiềm thức của bạn. Ngay cả khi chúng ta không biết gì, tâm trí của chúng ta (dường như) vẫn tiếp tục giải quyết vấn đề, ngay cả khi chúng ta đang làm gì đó, chẳng hạn như tắm .
Một sự kết hợp của tất cả những điều này:
Tránh xa nó ra một lúc để nó có thể ngồi trên lưng bạn. Ngủ, nghỉ, ăn, đi dạo, sao cũng được.
Kiểm tra vấn đề nhiều hơn, nó làm gì sai, bạn có thể tìm thấy những triệu chứng nào khác?
Nghiên cứu vấn đề, xem những gì bạn có thể tìm thấy. Hãy nhớ thử các từ khóa khác nhau
Hãy thử một cái gì đó khác nhau . Một công việc xung quanh. Một kỹ thuật sửa lỗi khác nhau. Một trình xác nhận. Một máy tính khác.
Nói chuyện với ai đó . Ngay cả khi họ không thể giúp đỡ, hoặc thậm chí không phải là lập trình viên, đôi khi nói chuyện sẽ kích hoạt bóng đèn ý tưởng
Khởi động lại! Nếu thích hợp, hãy thử khởi động lại máy tính, máy chủ, v.v ... Nếu không có gì khác, bạn có thể sử dụng thời gian để suy nghĩ.
Hỏi StackOverflow! Chúng tôi ở đây để giúp đỡ
Tôi thực sự không thích câu trả lời được bình chọn nhiều nhất, bởi vì mặc dù đôi khi nó hoạt động, đôi khi bạn chỉ cần tìm ra nó cùng ngày, vì vậy, những gì tôi muốn giới thiệu, theo thứ tự này, là:
Xác nhận rằng nó không chỉ xảy ra với bạn. Điều này có thể giúp bạn tiết kiệm rất nhiều thời gian. Có thể bạn đã gỡ cài đặt một thành phần bắt buộc hoặc thực hiện thay đổi trong môi trường của mình và một ngoại lệ đang bị nuốt ở đâu đó trong mã của bạn. Nếu nó chỉ xảy ra với bạn, tôi sẽ sử dụng một công cụ so sánh môi trường. Gần đây tôi đã đọc về một phần mềm có tên Envy, cho phép bạn làm điều đó, mặc dù nó không phải là phần mềm miễn phí, nó có giá 10 USD.
Xảy ra với mọi người? Tốt thôi, bây giờ hãy xem Lịch sử xem mã và xác minh những thay đổi gần đây có thể gây ra lỗi, trực tiếp hoặc gián tiếp.
Có sự thay đổi nào gần đây không? Nếu đó là một lỗi rất cụ thể (một ngoại lệ), 'stackoverflow it'. Bây giờ điều đó không tốt hơn 'google nó' nhưng tôi cảm thấy tốt khi nói rằng lần đầu tiên tôi tìm kiếm stackoverflow cho nghiên cứu lập trình so với google. Nếu đó là một vấn đề thực sự được biết đến, rất có thể bạn sẽ tìm thấy một giải pháp ở đây. Nếu không, sau đó gửi một câu hỏi trên trang web stackexchange liên quan. Bạn có thể nhận được câu trả lời rất nhanh, hoặc thậm chí nếu bạn không, câu hỏi của bạn sẽ được đưa ra ngoài trong khi bạn thực hiện nhiều nghiên cứu hơn. Đó là một lợi ích.
Nếu bạn không tìm thấy câu trả lời trực tuyến hoặc đó không phải là lỗi chung, thì hãy từng bước thực hiện mã, kiểm tra xem kết quả thu được của từng bước có hợp lý với kết quả mà bạn mong đợi không. Bắt đầu để kết thúc trên mỗi phương thức và từ dưới lên trên trên một giải pháp theo cấp bậc. (tức là nếu bạn đang khắc phục sự cố hiệu suất, hãy bắt đầu với mã truy xuất các bản ghi. Sẽ không có ý nghĩa khi bắt đầu trong UI nếu bạn có thể xác định nhanh nếu bước đầu tiên là sự cố).
Nếu sau khi đọc mã một vài lần bạn vẫn không thấy có gì sai, hãy gọi cho ai đó để nói về nó. Như ai đó đã đề cập, nói to về nó có thể thắp sáng bóng đèn. Cộng với lập trình cặp là thực sự hữu ích.
Tại thời điểm này, nếu điều đó là khả thi, hãy bỏ đi một lúc hoặc cả ngày. Tôi đã đọc một tweet rất đúng ngày hôm qua nói rằng "Tôi đã đi ngủ suy nghĩ 'làm thế nào các fck' và thức dậy suy nghĩ 'nhưng tất nhiên'". Thật vậy.
Nếu bạn vẫn chưa có câu trả lời, tôi dám nói bạn có thể thử tái cấu trúc thành các nhiệm vụ / phương thức / chức năng nhỏ hơn. Henry Ford đã nói điều gì đó như 'Không có một nhiệm vụ nào phức tạp đến mức không thể hoàn thành bằng cách chia nó thành các nhiệm vụ nhỏ hơn'. Tại thời điểm này, nếu giải pháp quá phức tạp và bạn không thể tự mình tìm ra hoặc nhờ sự giúp đỡ của người khác, hãy cấu trúc lại mã thành các nhiệm vụ nhỏ hơn. Ngay cả khi bạn không kết thúc nó, nó có thể giúp bạn tìm ra lý do.
Thêm thiết bị vào mã của bạn.
Tweet về nó ??
Bạn cần lùi lại. Phương châm của tôi là 'nếu vấn đề quá khó thì bạn đang giải quyết vấn đề sai'. Giả định của bạn là gì? đừng tin bất cứ điều gì
Hệ quả của điều đó là 'vấn đề của người thừa kế, người giải quyết vấn đề'. Sức mạnh của máy tính là logic của nó để bạn không thể chiến thắng logic. Bạn có một bộ não và phải nghĩ ra nó.
Trong thời hiện đại, có rất nhiều thứ khác tương tác trên một hệ thống - tường lửa, AV, Antispyware, cập nhật tự động xảy ra mỗi đêm - bạn phải đối phó với các mục tiêu di chuyển.