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ờ? [đóng cửa]


29

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ú?


3
Mô tả của bạn có thể đúng - Khởi động lại và thử lại!
NoChance

5
đăng nó trên stackoverflow tất nhiên :)
William

5
Tại sao bạn quyết định ngưỡng 10 giờ? Điều đó quá dài - nếu bạn không biết rõ điều gì gây ra hành vi bất ngờ trong vòng một hoặc hai giờ, bạn sẽ gặp rắc rối.
Vector

5
"Khi đi sẽ khó khăn, khó khăn đi ngủ và để tiềm thức làm việc với nó." - anon
Michael Easter

2
1. Nhờ ai đó giúp đỡ. Hai người là phải. 2. Thu hẹp nó xuống bằng cách sử dụng số lượng câu lệnh gỡ lỗi quá mức. Có một tệp trong đó mỗi dòng đơn được đi trước bởi một macro gỡ lỗi để xác định chính xác một dòng bị phân tách.
SF.

Câu trả lời:


9

Đố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.


79

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ờ.


17
Bạn cũng có thể thử vịt cao su. vi.wikipedia.org/wiki/Rubber_duck_debugging
Dave Nay

2
19 trên 20, vâng. Điều tồi tệ nhất của tôi không bao giờ được giải quyết, chỉ làm việc xung quanh. Không có môi trường thử nghiệm nào cho thấy nó, chỉ có môi trường sản xuất đầy đủ hoạt động - chúng tôi thậm chí không thể tái tạo nó sau nhiều giờ.
Loren Pechtel

3
Tránh xa thứ gì đó gây khó chịu cho bạn có thể thực sự khó khăn - nhưng tôi đã phát hiện ra trong nhiều năm qua rằng đó luôn là điều tốt nhất để làm. Tâm trí tiềm thức có thể giải quyết vấn đề trong khi bạn ăn, ngủ, nghỉ ngơi, xem TV ... và ngày hôm sau (hoặc ngày hôm sau) mọi thứ trở nên tốt hơn. Mặc dù vậy, một lời cảnh báo: thu thập thông tin trước khi bạn bỏ đi ... Đi bộ không giống như bỏ qua nó và giả vờ không có ở đó. Bạn vẫn cần chăm chỉ!
quick_now

1
Tôi không biết khoảng một giờ. Tôi thường giải quyết hầu hết các loại vấn đề khi tắm khi tôi thức dậy vào buổi sáng. Lần thứ hai thường xuyên nhất sẽ là khi tôi gần như ngủ vào ban đêm và cuối cùng đã cho phép mình ngừng suy nghĩ về nó.
SoylentGray

3
Có một Khoa học NOVA hấp dẫn NGAY BÂY GIỜ được tổ chức bởi Neil deGrasse Tyson nói về khoa học của giấc ngủ. Trong đó đã được thảo luận về hiện tượng đập đầu vào một vấn đề trong nhiều giờ, đi ngủ và thức dậy và giải quyết nó ngay lập tức. Khi chúng ta ngủ, bộ não của chúng ta biến các sự kiện trong ngày của chúng ta lặp đi lặp lại, phân tích nó từ nhiều góc độ khác nhau. Những gì nó để lại là những con đường thần kinh mới thực sự có thể giúp chúng ta nhìn nhận vấn đề theo một cách hoàn toàn mới trong tiềm thức, và sau đó thực sự giải quyết vấn đề. Khá tuyệt vời.
Byrne Reese

44

Trước khi mười giờ trôi qua, tôi sẽ nhận được sự giúp đỡ.

  1. Mô tả vấn đề cho người khác, bất cứ ai khác, ngay cả con vịt cao su của bạn .
  2. Yêu cầu người khác xem mã, hoặc bước qua nó với họ.
  3. Cô lập nó. Xóa một loạt các công cụ, sau đó đưa nó trở lại từng chút một cho đến khi vấn đề xuất hiện trở lại.
  4. Có được một giấc ngủ!

12
+1 để xóa mọi thứ cho đến khi vấn đề biến mất.
Giô-na

4
Bạn nên làm một trong những điều đó trước khi 1 giờ trôi qua. Bạn càng nhìn chằm chằm, bạn càng ít có khả năng đạt được sự hiển linh của mình. Tôi thường giải quyết một vấn đề chỉ bằng cách nói chuyện với ai đó.
Ben

Tại chỗ trên. Thường thì tôi tìm ra vấn đề, (hoặc đến gần nó) bằng cách mô tả vấn đề trước tiên. Thường thì điều này xảy ra trong khi viết mô tả vấn đề cho câu hỏi StackOverflow. Điều này cũng đòi hỏi phải giảm (cách ly) và sau đó không thành công, đó là khoảng thời gian chờ đợi khi bạn tránh xa vấn đề và để câu trả lời SO xuất hiện.
sholsinger

17

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.


Cảm ơn bạn rất nhiều - Tôi đã đọc bài viết về thời gian trên wikipedia, rất hữu ích.
Adel

7

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 đỡ.


1
"Người khác" không cần phải là con người. Đôi khi tôi giải thích mọi thứ với con mèo, và aha! Tôi tìm thấy vấn đề.
DarenW

Tôi thực sự nên mua một con mèo quá. Tôi sẽ huấn luyện nó để gãi đầu theo yêu cầu.
Adel

Ai đó thực sự phải tạo ra một tấm bìa cứng kích thước thật của Jon Skeet.
Don Roby

5

Tôi có một kế hoạch ba bước:

  1. Lấy một ly cà phê hoặc đồ uống ngon khác.
  2. Làm việc trên một cái gì đó khác cho phần còn lại của ngày.
  3. "Gọi điện cho một người bạn" và vẽ nguệch ngoạc trên bảng trắng.

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.


Lời khuyên tốt! Vì vậy, "Điện thoại một người bạn" được trích dẫn bởi vì nó nên được giới hạn trong 60 giây, như trên Triệu phú, phải không? Tôi thích ý tưởng bảng trắng quá.
Adel

1
Tôi tìm thấy bảng trắng thực sự giúp suy nghĩ nó thông qua phương pháp. Báo giá là bởi vì thường người bạn ở cùng văn phòng nên thực sự gọi sẽ là số lẻ. Nhưng nó giống như một huyết mạch từ chương trình truyền hình.
Flexo

4

Ngủ qua nó

Nếu không, hãy gọi cho ai đó gần đó và yêu cầu anh ta xem nhanh mã.

Thông thường các lỗi sẽ khiến bạn mất nhiều thời gian để tìm (vì mã của bạn) được người khác tìm thấy rất dễ dàng


3

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ĩ.


3

Tôi thường làm một trong ba:

  1. Đi bộ / đi xe đạp ... một số khiến bạn rời khỏi máy tính.
  2. Chơi với chó hoặc mèo của tôi
  3. Nếu bạn có một sở thích, hãy làm việc đó một thời gian.

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 :-).


3

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ả điều này là tốt và tốt nhưng phải thừa nhận rằng lỗi đã và có thể được sao chép. Điều gì sẽ xảy ra nếu 19 giờ dành cho đến nay chỉ là ... cố gắng tìm một phương tiện để tái tạo vấn đề theo cách xác định và có hệ thống ... sau đó thì sao? Đối với tôi đó là bản chất của câu hỏi ở đây!
Newtopian

Lập trình viên thực dụng là tuyệt vời
Adel

2

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.


2

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.


Có thể lấy lại các bước của một người là rất quan trọng. Cảm ơn bạn!
Adel

> Có thể lấy lại các bước của một người là rất quan trọng. Phần mềm SourceControl là chìa khóa để có thể khôi phục / truy xuất. Hãy ANAL về điều đó và nếu bạn có thể, hãy đặt cài đặt của bạn để buộc bạn để lại nhận xét khi đăng ký.
Vector

3
Thật không may, cho dù bạn biết mã của mình tốt đến đâu, đôi khi vấn đề là sự tương tác với mã (nguồn đóng) của người khác.
Nate CK

2
+1 @Nate CK- rất đúng. Các loại lỗi tồi tệ nhất xảy ra khi bạn nhận được một số từ vô nghĩa từ dịch vụ web mà bạn đang dựa vào. Tôi đã có một nhà cung cấp Saas một thời gian trước, người đã tinh tế thay đổi một số chức năng mà không cần cảnh báo trong dịch vụ web của họ. Tôi đã phải giải thích cho nhà phát triển cách sửa lỗi của chính anh ta qua điện thoại khi anh ta mô tả cho tôi biết mã của anh ta trông như thế nào.
Morgan Herlocker

1
Để xác định cái gì? Đó là một vấn đề trong mã bên thứ 3? Phần đó tương đối dễ dàng. Phần khó là tìm ra điều kiện nào kích hoạt nó và cách khắc phục nó, khi bạn không có nguồn, nhà cung cấp không phản hồi và có lẽ điều đó không xảy ra trên hệ thống kiểm tra của bạn. Nếu bạn nghĩ rằng việc biết mã của bạn sẽ giải quyết tất cả điều đó cho bạn, tôi đề nghị có lẽ bạn chưa bao giờ phải đối phó với nó.
Nate CK

1

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).


1
"Tôi đã khởi tạo và trả lại một vật thể lên một thứ khác ngoài bản thân" - những lỗi như thế là TOUGH! Bạn có thể nhìn nó hơn 100 lần và không bắt được nó. Nhưng bạn không thể thấy hai phân bổ bằng cách truy tìm trong trình gỡ lỗi?
Vector

1

nhập mô tả hình ảnh ở đâ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 .


Ý tưởng tuyệt vời .... bây giờ tôi chỉ cần nhờ sếp đặt nửa tá bồn ngâm trong văn phòng.
Dave Nay

Nếu chỉ có quân đoàn của công nhân tủ thì mỗi người có một căn phòng như thế.
Adel

1

Từng bước từng bước, xuống lắp ráp. Ai gọi cái gì, điểm dừng trên bộ nhớ truy cập. Điều đó thường bắt lỗi thực sự nhanh chóng.

Nếu không, hãy đi bộ.


1

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 đỡ


1

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à:

  1. 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.

  2. 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.

  3. 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.

  4. 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ố).

  5. 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.

  6. 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.

  7. 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.

  8. Thêm thiết bị vào mã của bạn.

  9. Tweet về nó ??


1

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.


Thật sự là 'người giải quyết vấn đề, người giải quyết vấn đề'
Adel

-1

Google nó. Stackoverflow nó. Đăng nó trên các diễn đàn. Về cơ bản nếu bạn không thể giải quyết nó một mình, hãy nhờ mọi người giúp đỡ.


-1
  1. Viết ra vấn đề.
  2. Suy nghĩ kĩ.
  3. Thực hiện giải pháp.

Súc tích, rất tốt!
Adel

1
Thật ra, không. Suy nghĩ quá nhiều cùng các bài hát chỉ là điều tồi tệ nhất bạn có thể làm. 'Thử thách, liệt kê, xem xét lại và kiểm tra từng giả định của bạn, một cách có hệ thống' là giải pháp ở đây; mọi người đang thảo luận về các chiến thuật khác nhau để đạt được điều đó.
smci
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.