With the increase of age and experience, there will be some new knowledge about software analysis and design. Here's a short summary:
1. Questions about what to use not as a design:
In the last two companies, the original men were not designed (my own feelings), nor did they perceive any impulse to make the design. But the state of work is: Pressure task, catch progress, code a lot of repetition, errors clustered. This company has been commonplace for several years, but I am increasingly intolerant. So I am determined to work hard, starting from me.
In small projects, it is not necessary to make architectural design, layering, common to a person's project. In more than three people, it is necessary to decompose the modules, especially the cross-platform modules. Decomposition modules can prevent code duplication from the top level, wasting developers and saving money for the company. and decomposition module, for the reduction of learning difficulty has a great help, conducive to the exchange between groups, can be described as hundred and no harm.
2, about architecture design
I have read some books recently. There is a design approach that is very beneficial to understanding and practice: first, the logical structure decomposition, and then the physical decomposition.
Also, the concept of architecture itself is very abstract, everyone's understanding is very different, specific to the various types of software, there may be a very big difference.
3, about detailed design
From the perspective of practice, the first to find the whole object (modeling), and then development, and some of its own reality is inconsistent with the present. In the case of the boss and the leader staring at you, it's clear that this approach won't work. My approach can be properly designed, but writing code to complete the design is the most feasible.
Web server Analysis and Design (v)--some summary