There are not many specific problems, and each problem has some usage scenarios. Each scenario can be implemented using several modes, what are the variants of each mode, what are the advantages and disadvantages of the patterns and variants... To understand these, it is not easy to use the creation of objects, and there are these situations:
(1) One-time trading: Just new
(2) You are my only one: single case
(3) Wait for a thousand years: object pool, prototype, cache
(4) The return of the familiar swallow: Xiangyuan
(5) I've seen GOF: Factory, Abstract Factory
(6) Don't ask me where I came from: IOC
Details are also important in implementation. But the so-called details are all about the aspects involved. The implementation at the next level is nothing more than the three layers of UI, service, and data access, and then adding an integration layer. UI is nothing more than those modes, and most of them are template-based and control-based. There are some main modes in business, and data access is mainly those three modes. There are also two usage modes when subdividing it. There are databases that require money, and there are external processes, internal processes, complex and simple. Files include ordinary files, files with indexes, html, xml and other files with specific formats. How to operate these?
3. Some experiences about MSF
Software process control mainly solves some problems. Code, bugs, requirements, documentation, communication, publishing, risks. The only thing I learned from MSF is Tradeoff (tradeoff/trade). The most valuable idea of MSF should be trade-offs. What purpose should be achieved, what should be given, what should be chosen, what should be given. I once studied MSF for a long time two years ago and wrote a Case (put it on a certain library online, and it seems that it costs money to buy it, hehe). In the past, software was mainly used for industrial purposes, stability was very important, and programs were unsuccessful. In the early 1990s, software applications transitioned from industrial to ordinary application fields, functions and availability became very important, and stability was not valued, and Windows stood out. The original version of MSF was formed in those years. Since then, Microsoft's Trade-off has basically made progress priority over functionality, functionality over stability and security. Recently, Microsoft's Trade-off has changed, and its stability and security ranks are relatively high. Back then, Microsoft's development team grew bigger and development management was a bit chaotic. So Microsoft organized a group of experts to summarize the experience during the development process and form the initial MSF version. With the development of the times, MSF gradually evolved into its current version. The current MSF is used as a process method by Microsoft and promoted to the outside world. My opinion is that MSF is first a summary of Microsoft's own successful experience, and secondly, it is a reference process method. MSF teaches how to successfully develop software products, not how to meet project requirements. And, MSF is not universal. There is a book called "Adaptive Software Development". That book is actually the best interpretation of MSF. Only in which organization is used this method, the book analyzes it thoroughly.
Four, four methods
To summarize, I think these four methods are probably useful:
Learning from a master: Learning based on cases, the first-hand information is the most reliable. Look at the source code more and the existing solutions more. Write more code if you have nothing to do.
Left and left-right mutual blog: For the same problem, learn more and study more and more solutions. Only learning one type of thing is easy to get out of sight, without comparing, and not being able to understand the advantages and disadvantages of a certain software, a certain solution, or a certain design pattern. When time is possible, try different solutions.
The butcher Ding cuts the cow: When you get something, you will have two horizontal and vertical knives, divided into horizontal ribs and longitudinal spine, and the rest is flesh. It is practical for most OO software. It is not your problem if it is not practical, it is because there is a problem with the software. For the software you wrote, you can try it if you have nothing to do. The software did not spread out and prove that there was something wrong with the writing.
Star-absorbing method: Any software has historical problems, and any method has historical problems. The software needs to be compatible and the company needs to promote it, so many things are not what it seems to be. .net is so powerful to the underlying binding, these are all historical issues. Therefore, when learning something, it is best to go forward a few versions to see what stories happened during the evolution of the software, what the background of these stories is. Each story means some trade-off, and you can learn a lot of software design knowledge from the middle. Learning in this way is equivalent to taking other people's practical experience as your own, how cool it is. Another meaning of doing this is to cultivate one's own ability to predict technology, and looking at one step more than others is a great advantage.
5. Tips for reading code
For OO, generally a library/software with 500 to 1000 classes, the main classes or interfaces are about 10 to 20. Generally speaking, these classes form a hierarchical relationship. Each layer, these classes or interfaces will have a lot of subclasses/implementations. There are about hundreds. The remaining classes are basically tool classes, auxiliary classes, and classes that obtain specific resources. The first step should be to find these main classes and interfaces, find out the main calling process, and understand the process. In this way, you will almost understand how this software/store works. The second step is to look at the inheritance/implementation of these main classes and interfaces, so that you can understand what this software/store can do and how to expand. In this way, a thing that counts M code can be clarified in 2 to 3 days.
The main difficulty of reading code is that the amount of code is too large, but OO greatly reduces the difficulty of reading code. A good OO software knows what to do when you see namespace, class name, and method name (you can form this intuition after reading more code). There is no need to read specific code. The difficulty of reading can be much lowered through tools: the class diagram and the sequence diagram of the main calling process are obtained through reverse engineering. Through reading these two diagrams, it is almost the same. Ndoc, Visio, doxygen, and even word are useful auxiliary tools. If you really can't understand it, just look at the code. The skeleton of the software is roughly these. In addition, each software may involve one or two core algorithms or its unique data abstraction (data structure), implementing some specifications or known algorithms. At this time, look at these specifications or known algorithms, and you will quickly understand them in combination with the code. In addition, there are some detailed knowledge scattered in those auxiliary classes. After understanding the skeleton, you will probably have a bottom line for these things, but it cannot be accurately determined. At this time, google, see how you use it and what are the precautions. If the reading code is incorrect, you will dive into these details at the first end, and that's all. For the main process Mastering and mastering levels is the first priority. Understanding design patterns is still second. There are also many non-OO software that can be easily read using this method. For example, reading protocol stack code and following a package. In the enterprise, walking around an order. These are very effective methods to deal with complex systems. In OO, it is to follow the method. Select a method and follow it. If you choose this method well, you will basically transfer the software/library to the end. In this process, you may encounter dozens of objects and hundreds of method calls. Once you understand it, it will be almost done. However, the main reading line cannot be messed up.
Previous page12Read the full text