Read "Programmer's path to training-from small to expert" read Note 02

These two weeks our team has entered the sprint stage of the training, this week I read the "programmer of the Way" the third chapter of the content.

how to program by coincidence by coincidental programming

I don't know why it works at first. Accidental implementation: Things happen because the way the code is written now. Finally, you will rely on errors or boundary conditions that are not recorded in the document. It may not really work-it may just seem to work. The boundary conditions you depend on may be just an accident. Behavior that is not documented may change as the library is next published. Unnecessary and unnecessary calls can slow down your code. Redundant calls can also increase the risk of introducing their own new bugs. Conclusion? Some basic principles can help you with the code you write to someone else, good modularity, and a small interface that hides the implementation from writing good documents. For the routines that you invoke, only the behavior of the document is counted. If for any reason you can't do this, take your various assumptions into the document. Contextual coincidence: Just now that you are writing code for the GUI environment, will the module have to rely on your GUI? Do you rely on English-speaking users? Have a culture of users? Do you still rely on something else that is not guaranteed? Implicit assumption: Coincidences can be misguided at all levels-knowing the test from production requirements. In particular, tests are filled with false causal relationships and coincidental outputs. Do not assume, to prove. Don ' t program by coincidence how thoughtful programming always realizes what you are doing. Don't program blindly. Follow the plan, rely on something reliable, don't rely on coincidences or assumptions. Create a document for your assumptions. Do not just test your code, but also test your assumptions. The assertion prioritizes your work. Spending time on important aspects is probably the hardest part. If the infrastructure is not correct, then a good whistle is useless. Don't be a slave to history. Be ready to refactor. So the next time something seems to work, and you don't know why, make sure it's not a coincidence.

Algorithm rate What do we mean by estimating algorithms?

As long as we write a program that contains loops or recursive calls, we subconsciously check the runtime and memory requirements. O () notation: 1: Constant type, access to array elements, simple statement LG (N): logarithmic, binary lookup n: linear, sequential lookup NLG (n): less than linear, but not much worse (fast sort, heap sort) n squared, square-shaped (select and insert sort) n cubic, cubic, 2nxn matrix phase  By. Cn, index type, travel quotient problem, set division. Common SENSE estimates: a simple loop, from 1 cycles to N, is probably an O (n) nested loop, O (m*n), O (square of N) dichotomy, O (ln (n)) divide and Conquer, O (NLN (n)), which is often optimized by heuristic methods. Algorithmic rate in practice: the tradeoff between time and space. Estimating the order of your algorithm requires only a few points to determine. Test your estimate. The best is not always the best: the quickest algorithm is not necessarily the most appropriate. Sometimes the pursuit is simple, fast.

Refactoring Overrides,

Redo and re-schema code merge to become refactoring, refactor when you should refactor do not hesitate to repeat the changes, non-orthogonal design, outdated knowledge, performance. The complex situation in the real world: refactoring is like removing tumors, and it takes time to repair. Otherwise early refactoring, often refactoring. If you cannot refactor it immediately, add it to the plan. How to Refactor: Refactoring is re-design, new facts, new understandings, new needs and so on. Re-construct activities that are prudent, deliberate, and carefully conducted. 1, do not attempt to add new functionality while refactoring. 2, before you start refactoring, make sure you have a good test. Run these tests as often as possible. So, if you change it, you will know it. 3, take a short, thoughtful step. Test after each step. Modify the code, and also modify the place of the dependent code. It is best to fix it once and for all, and not tolerate broken windows.

Easy-to-Test code unit testing

The unit test of the software is the code that drills the module, establishes some kind of artificial environment, and then invokes the routines in the module being tested. A different test value is then checked for the return value. Test for contracts: whether the code conforms to the contract, and whether the contract has the same meaning as we think it is. Boundaries, conditions, and so on. This style of testing requires you to test the module's self-assembly first. It's easy to know where something went wrong. Designed for testing purposes. Finding problems early is better than solving problems. Write unit tests: put them in a convenient place. This brings invaluable resources to developers: 1, some examples of how to use all the features of your module. 2, a means to build regression tests to verify that any future changes to the code are correct. You can use #ifdef to skip the code of the unit test at compile time. You can also use shell scripting. Using test devices: either GUI-driven or makefile and Perl script combinations should have the following features: A standard way to specify settings and cleanup. The method used to select individual or all available tests. Means of analyzing whether the output is the expected result. Standardized form of failure reporting. The subassembly can be used to form a system that reaches any depth. Impromptu testing, ad hoc testing, print, or interaction. It may need to be formalized. Build Test window: A log file containing trace messages is a mechanism that is formally consistent in format. Open the Diagnostic Debugging window with a hotkey that is not known to the normal user. For larger programs, you can use a Web server. Test culture: Testing is a technology, but also a culture. Test your software, or your users will have to test it.

Evil Guide.

Use the wizard carefully, and the wizards write code for you that you may not know. If you're not sure, you're probably just programming by coincidence. Do not use wizard code that you do not understand.

Read "Programmer's path to training-from small to expert" read Note 02