First, the principle of selection of technology
A more standardized software development process can only be learned by a limited number of companies. The method I'm using now is 圡 method, master programmer, test driver, document and code written together, prototype. But basically adhere to a few principles:
In the work of practical-oriented, which practical learning which, to the smallest effort to obtain maximum results.
The first Utility I wrote was to import a legal CD into the database, and the optical source file format needed to be analyzed. The data is about tens of thousands of. One method is to write a program to import directly, another way is to write an interface, manual import. I chose the latter. The program interface is as follows: There is a text box, there is a big button, the button has a book so large, so the principle of design is to let the eyes closed to point. Let a watering buddy, CTRL + C, CTRL + V, keep pouring. Text pasted past, automatically parse, put into the database. Left ALT + TAB CTRL + C/V, right mouse, so rhythmic movement. Soon, the data will be finished in a few hours. Originally designed a text box, a button, very pp, but the old point does not. Then I put the button into the boss, in this one change, productivity increased by more than 1 time times.
Work, we must adhere to such a principle. To be able to distinguish value, to find the ability to improve the value of doing. Even if this violates the general rule, violates the technical dogma.
Learning to simple, the core of Dongdong. Can learn not to learn not to learn. Complex things unless you want to be an expert in this field, don't learn. I still give an example of their own, the first a while to do the GIS needs, the implementation of my responsibility. The budget is small. I set the open source GIS software This road, originally wanted to use C #, but no good open source GIS software, I decided to write in Java. I haven't got any Java in my hands. I chose an open source Lib, let a buddy run a demo, and then let him from the demo of the main function to draw the function call graph has been drawn to the database call. I ran to see the GIS specification, and then his diagram, combined with my knowledge of the specification, soon knew how many layers were in the middle of the software, what each interface was for, and how to call it. The pros and cons of this software. Then the architecture, the design came out, and then 2 Java programmers, and soon made it.
Skills of technical learning
Using the above example to talk about the skills of learning software
To learn one thing, learn the two kinds of knowledge of the thing: structure and detail.
The structural stuff is very important. Learning structure, you can start the director, learn the details, can do this thing well. The structure is not clear, the details are no better than understanding. The structure is very simple, is vertical, horizontal two lines. In a way, it's the execution of a program, and you need to know what step you're doing. To ASP.net, is from receiving request to return a page, the middle of the call process, which is the main line, and further, the program loading-> receive request (-> cache, session mechanism)-> return a page, this process clear, ASP.net is about the same. Vertical is usually called through the interface, look at the source code can soon be done.
Landscape is to look at the important interface, what the important abstract classes are implemented, what implementation is used, and what the pros and cons are. Then even if the structure of learning. The rest is a matter of detail. The details of the problem skilled natural very good, not skilled Google can Google, but it will take a lot of time. This study I think is the most effective learning, do not have to track the technical forefront, when a technology in front of you you can quickly see its skeleton, advantages and disadvantages, performance, at least can be estimated to approximate the scope. This slowly cultivates the perception of a technology, achieves juchongruoqing, knows where there may be pitfalls, and where there may be innovation. Hold the key and context.
The details are constantly being practiced and reconstructed. A useful software, constantly put forward higher requirements, and constantly refactoring, not a few times, several important design patterns on the heart. It is not advisable to learn the model by learning mode alone. Each pattern is for a certain problem. Deep understanding of these problems is the key to learning! Technology is a variety of things that change very quickly, but there are not many problems that technology has to solve.
At the architectural level, the main problems are: (1) addressing complexity-how to make complexity easier? The idea here is encapsulation, OO is a package, and there are other ways to encapsulate it. The key point in refactoring is to make your class name and method name clear about its identity and function. (2) Solving the problem of program evolution and extension--combination priority inheritance, how to expose the API, how to write the document, in short, let the program evolve and expand the simpler the better; (3) Performance problem--80/20 principle, performance test how to test, how to evaluate, different use scenario performance, caching mechanism (4) Functional problems--the main function must be realized, this and business-related, (5) Ease of use, (6) Vertical expansion, horizontal expansion, concurrent ... (7) The development of their own or the use of Third-party plug-ins or outsourcing and selection issues.
Specific learning, I recommend problem-oriented, case-based learning, do not adhere to the language, to learn the best things to learn. For example, the performance of the key in scheduling, this time you can look at the resource scheduling mode, Hibernate is a resource scheduling play to the extreme. Event-based scheduling (such as Web cache in. net), process scheduling, thread scheduling, workflows, all of which are behavioral scheduling, and if these things are mastered, master each of the advantages and disadvantages of implementation. Then all of the software design and time, concurrency, resources related to the dongdong is nothing. Behavior scheduling can look at the cache implementation in. NET, find a workflow software look, look for several thread frame to see, look at several typical operating system process scheduling mechanism.
Specific to the implementation of the problem is to face nothing more than:
(1) object creation and destruction, (2) object's encapsulation and inheritance system; (3) The granularity and semantic division of Objects, (4) The Reuse of objects, (5) object testing, (6) The Persistence of objects, (7) Specific API exposures, (8) Common collections (9) algorithm problems ; (10) Performance problems; (11) callback; (12) Eliminate semantic ditch; (13) I want to be lazy with you ... (14) What APIs (15) I can use to manage, (16) asynchronous calls, (17) remote calls
Current 1/2 page
12 Next read the full text
