60 Problem Solving Strategies for Programmers

Basic guidelines

1. First of all, when writing code, there should be no defects. The best way to fix the bug is to let it die in the womb.

Good unit testing

Enforcing database constraints

Using an input validation framework

Avoid unimplemented "else" conditions

Know how to use it in isolation before applying it to your main program

log

2. print statements. Often an extra line or two of output will help isolate the problem.

3. Switch to detailed logging. Detailed logging helps to find more clues.

4. Search the log files. If there are too many log files, you can use keywords or error codes to search the log files.

5. Turn on word wrapping and turn off word wrapping. Controlling the word wrapping of logs is also very useful.

6. Search different logs. The master server's log may not be the only useful log.

7. Windows Event Log. Another source of log files may be the operating system itself.

8. Make useful logging. Sometimes, if you don't get any useful logging, then you may need to write your own.

Communicate with others

9. Ask someone who might know the answer to your question.

10. Asking "stupid" questions. You may think these questions are stupid, but they are not.

11. Explain the problem to your teammates. They may know the answer or be able to suggest something you haven’t thought of.

12. Explain the problem to your dog. It doesn’t really matter who you explain it to, but it will allow you to analyze the problem from a different perspective.

writing

13. Describe the problem. Describing the problem in the most accurate and precise terms will help you think about possible solutions.

14. Problem journal. Create a text file to record the various approaches you have tried, including code snippets, configuration settings, and any errors that occurred.

15. Record problems and solutions. Have you ever seen a familiar problem that you remember solving before but can't remember how you solved it? You can record the problem and solution in an easily searchable place, such as a wiki, bug tracker, or even email it to yourself.

support

16. Read the FAQ.

17. Submit a support request. If there is support available for the product/library, use that.

18. Think before you click send. Writing a support request allows you to think about the problem again. Sometimes, just when you click the send button, an idea suddenly comes to your mind and you come up with a solution to the problem or a new clue.

19. Other support. You can communicate with developers directly face to face, the best is real-time chat/SKYPE/screen sharing.

Leave the keyboard

20. Take a walk.

21. Take a nap.

22. Reset your priorities. Another benefit of temporarily leaving the keyboard is that it allows you to re-evaluate the importance of this problem. Maybe this problem is just a CSS/layout problem and it is not worth spending 16 hours on it. In short, allocate and use your time effectively.

23. Put the problem aside for now. If you really can't solve it, you can put it aside for now. Maybe a few days later when you read the related questions, you will suddenly get an idea and find the key to solving the problem.

isolation

24. Determine which line of code is causing the problem. First, determine which line of code is causing the problem so that you can insert a print statement.

25. Separate the problem into a separate program. Sometimes for library and product problems, we can separate the code from the main program. This may take a little time, but it is often easier to deal with an isolated program than to deal with the entire project build process. Then compare the solution to the main program after solving the separate program.

Change the code

Even if you have no idea how to solve the problem, changing the code is a very effective solution.

26. Write new unit tests.

27. Refactor. Problematic code is often a bit messy, and some simple refactoring methods, such as renaming variables or expanding nested if/then/else blocks, can make the code tidy.

28. Finding bugs. Another way to clean up the code is to check the "Find Bugs" report of the relevant code. The reason why we should clean up the code first is: as a way to let our brain focus on the code, it is simple and cost-effective.

29. Rewrite. Dump all relevant code and rewrite it from scratch. A fresh perspective may allow you to avoid the problem entirely.

30. Add comments to unnecessary code - or at least you think it is unnecessary. Then you will find that these code flows may not be as "unnecessary" as you once thought.

31. Experiment. If you are not sure how the underlying product or library works, then small experiments, especially around boundary conditions, can be very useful.

32. Return to a clean state. If you make a lot of changes in the code or play around with a lot of configuration settings, it is very important to return to a clean state regularly. Otherwise, the results of your experiments may affect the correct answer, and you will never find the right solution.

33. Switching technology.

product

34. Upgrade to a higher version. Maybe the problem you are dealing with has been fixed. You can try upgrading to another version first.

35. Downgrade to a previous version. Perhaps the problem is caused by incompatibility with other products/libraries you are currently using.

36. Patching.

37. Download and install the source code.

document

38. Read the manual. Most developers would probably think this is a low-probability strategy, but hey, you never know, maybe the answer is in the documentation.

39. Read the correct version of the manual.

40. Is the manual correct? Sometimes the code has been updated but the manual has not.

debugger

41. Learn the shortcuts on your keyboard.

42. Step Back. This is a debugger feature that lets you step back through your code.

43. Write breakpoint code.

44. Break on exception. A very useful feature of the debugger is the ability to catch specific exceptions anywhere.

45. Professional debugging tools. For example:

Plumbr

AppDynamics

Chronon

Wireshark

HTTP profilers: Fiddler2, Charles, Live HTTP Headers

Source code control

46. ​​Number and tag bugs. Have you ever encountered a problem that was fixed one way, and then a few weeks later became a bug again and was fixed another way by someone else? It seems that there are two correct answers to the problem. The solution is to tag the relevant bugs in the source code and record some more detailed explanations about why the change was made and who was involved in the decision.

47. Blame feature. This cute little tool tells you who *** changed the code.

48. Git bisect feature. Git has an interesting “bisect” command that automatically does a binary search through your commit history to find glitches.

Finding answers

49. Google search.

50. Forum Posts.

52. Search Stack Exchange.

53. Create a stack problem.

other

54. Hire an expert. Can be costly in a short period of time.

55. Hire interns. The opposite of hiring an expert is hiring a novice. Sometimes a beginner’s enthusiasm allows them to approach a problem from a different perspective.

56. Change the requirements. If you can’t fix the defect, change the requirements. By explaining the various cost requirements, you may be able to get the customer to change their mind.

57. Change upstream/downstream systems.

58. Learn technology step by step.

59. Check configuration with breakpoints. Changing key configuration values ​​and making sure to breakpoint allows us to set configuration without worrying about it.

60. Systematize. Sometimes we need to combine three or four things together. Then we can record the combinations we have tried and try various combinations if necessary.