Project size metrics, Project architecture methods (fill in the blanks, continuous integration, edge test effect) (paste)

Size metrics for Java projects:

• Micro: Just a person, even half-day work in a few days to complete the software;

• Small: A person within six months to complete the 2000 lines within the program;

• Medium: 5 people in more than 1 years of time to complete the 5000-50000-line program;

• Large: 5-10 people completed in two years of 50000-100000 lines of procedures;

• Very large: 100-1000 people participated in a 4-5-year completed software project with 100, 0000 lines;

• Very large: 2000-5000 participants, within 10 years to complete the 10 million lines within the procedure;

The above excerpt: "Introduction to Software Engineering" Zheng, Yin People compilation

This view is based on the line of code as a measure of the nature of the line of code is considered to be a large number of projects.

Reference: http://zhidao.baidu.com/question/303914133298509404.html

---------------------------------------------------------------------------------

That's the repetitive code that must be merged into a function, or a method of a class. The first is to save the code, but more importantly, the structure begins to unfold, from the thorough noodle code to the structured, structured code. People's cognitive ability is limited, memory capacity is limited, screen size is also limited. When you turn the hundreds of-line noodle code into a couple of functions, first of all, the unit you use to understand the code changes, and from the big logic, you can use each function as a black box, and the overall structure becomes, calling several functions. Then when you find a problem with the system and you suspect it is within a function, you can simply analyze the input and output of the function to locate whether the problem is within the function. when you are sure, the difficulty of modifying and understanding is greatly reduced.

Previously there was a principle called code block that repeats two times and must be functional. a function is as far as dozens of rows. It is not necessarily 100% strict implementation , but it is recommended to carefully understand, always reflect.

The process of writing code should be, write thick first, then write thin. Write a time to reflect on the implementation of the structure is reasonable, is not too redundant. When your code is always able to maintain a certain amount of structure and reuse, the number of lines of code will be a good evaluation parameter for the project size. More than one line, the logic is really a complex layer. If you form such a habit, your skill will naturally deepen as the amount of code grows.

In fact, writing procedures, is a series of logic, you can abstract them, you can also have like them, in the view of the global time abstract, can help you to think about the problem, see big picture, can clarify the clue. As a concrete implementation, you can go back to specific details, but with the global abstraction structure, you can only care about a local detail.

Just now my company and I were discussing the development steps of the new product, and I recalled to him that we had developed this 20,000 multi-line interactive typesetting system. I said that if we start with a module of a module from scratch, step by step, then maybe we can do it for a few years. But in fact we first defined each module, implemented an empty shelf, and then 1.1 points perfect. this has several advantages, first, this thing is can be continuous integration, side development can test the overall effect, can continue to improve, do not need elephant . However, we can actually grasp the progress from beginning to end and we can see the priorities. In this way, the project can only be done, otherwise it is completely uncontrolled.

When you can smoothly switch your abstraction level, you actually understand what the architecture is.

Project size metrics, Project architecture methods (fill in the blanks, continuous integration, edge test effect) (paste)