Some ideas and simple suggestions about the procedure

A person to amuse themselves to write a small program, with a bunch of people to write a large program. It's really not the same.

A person, there is no communication, mutual understanding of the problem. The more people you understand the intentions of others, the more time you will take to explain your intentions to others. As long as it is necessary to communicate the task, not the more people the better. Some people join, in order to make the person who joins to do something, the original matter will be reclassified, and after the separation to cooperate, but also spend time to communicate. Found that a lot of important software started by a few people to do. In the comics, the task also uses group mode, as if <, < Hunter > are four-person group.

Here, the most basic problem is the division of tasks, the ideal division is mutual independence. It is difficult to achieve this independent, orthogonal division, and it is even more difficult for you to find that the original task will change over time. Traditional software engineering will say, first of all, defining requirements, followed by general design, detailed design, coding, unit testing, overall testing, and so on. But the real implementation, found that there is no such ideal, many projects are not rewritten, but in the original code to strengthen, it is likely that the original is the sand, is very quicksand, but to the top of the high-rise. If a project is completed in half a year, spend one months to define requirements and design, and then code, you will find a lot of things are unexpected, some seem very simple things a card on the card for one months, no progress. To find out that this was a very simple question involving the structure of the project, and before the structure is difficult to modify, or not willing to modify, in order to solve this problem, resorted to some crooked strokes, it seems very clever, but disrupted the original structure, followed by these ancient strange strange, unexpected problems emerge, the original design gradually deviated, And not to modify the document. Time more and more tight, the project dragged, the company found the top of the road, add people, newcomers, pick up the original design documents to see, found that not on the. The old man took the time to help him understand the project. To the original deadline, the program is a run on the crash, the final result of two or three months later released, released a lot of bugs, and then spend two or three months to correct, send a patch package. A year has passed.

In the software, the Task Division is to establish the boundary condition. For example, the component is divided into components, the component is divided into classes, components and components, class and class interaction through some interfaces. Boundary conditions are most likely to be problematic. Originally I this class good, one and another class interaction, on the problem, and such as this function well, a thread switch that instant problems. The definition of an interface is important. The software has not yet been fully plug and play like hardware. The first to establish the interface, and then find different people to do it, and finally embedded it can be used, which is also a very ideal situation. It is likely that the interface would have been wrong in the first place, and the other might have understood the meaning of the interface by the implementing person. A lot of things, finished to know is done wrong. For example, exams, usually after the test out to know the answer, think about the next good preparation, test better, but found that next time there is a problem will not do.

I now own opinion (may also change later), the project is in any case can not think of specific details, so as long as there is a general direction on it, to do as soon as possible. Since you didn't come up with all the details before, emphasize that you can easily adjust the structure of the code, add more details, that is, refactoring. Note that refactoring is not about adding new features, but about organizing your code without changing the performance of the program, making the original code more reasonable, and then adding new functionality is easy. The so-called add an if to judge the null pointer, and then add a button on the dialog box, etc., it is not a refactoring.

It's easier to modify your code, and you should pay attention to some small details. Especially when the project is bigger. Some habits need to be developed from the beginning, do not think of just doing little things to play, no relationship. In the beginning should be to the industry's top of the group of people, so that can be professional.

1. Reduce compile connection time, especially try not to add header file on header file.

Before also very random add header file, anyway, small project, then compile. Now I find that if I change a header file, and so it compiles enough to read a chapter book, after compiling torture, it is very important. Because the header file is modified, a CPP file containing or indirectly included will be compiled. Chaos contains, will find the bottom of the file a change, almost the entire project is compiled, is very time-consuming. Also, do not write all class definitions in one place, so the inclusion of dependencies can be reduced.

If the compilation time is very long, obviously knows some place is not good, also will not go to revise. It's like writing programs that are afraid of trouble.

2. Variables are used to define, not to be defined from the outset.

Many people also keep the C habit of defining all the variables used to begin with the function. This habit is actually very bad, on the one hand, no necessary construction of the destructor will be invoked. More importantly, you'll find it troublesome to break the original function into smaller functions, because the definition is at the beginning, the scope is the entire function, and you want to make a piece of code that makes it difficult to determine which variables to use. Another variable definition must attach the initial value, this error looks very retarded, but many people will commit, especially like to put all the variables in the beginning of the kind of C-style people.

3. Manage resources with a class, obtain resources and release resources as far as possible in the same place, not separate in two places. In particular, do not do new in the same function, delete the same object or array.

Resources are very broad, such as taking GDI objects and releasing them, often speaking of memory. To copy a string, or to temporarily read a memory, start without knowing the length, many people will new a char array, followed by the end of the function is released. There is a problem, such as a return in the middle, skipped the release of the statement, there is a resource leak. Many people insist on a function of an exit, but there are often some variables that mark the end of the loop and so on, far less than a return direct. Another person to change the code, he probably does not believe in a function of an export. As the function modification becomes longer, the corresponding gain and release are farther and further apart. For fear of trouble, in order not to add the release code before each return, someone uses goto out: replace return and out: then do the release.

As long as the Goto, resources and release too far away, later want to put some code to make another function, it is very troublesome.

So C + + has a idiomatic method of Raii, the simple idea is to use classes to manage resources, get in the constructor, and release in the destructor. Because the standard guarantees each exit, the generated object's destructor is invoked, including an exception. If you want to assign a char array, you can use std::vector<char> mem; Mem.resize (memsize) to replace, new Char[memsize];, the following pointer can be written as &mem[0]. One might say that if the object is too large, it may be directly defined to cause a stack overflow, so be new. If so, it is likely that the object's design itself is problematic. It would be annoying to write about some of these freed auxiliary classes, and look at Loki::scopeguaid.

4. Consistency of Style

Style seems to be very personal, very small things, but for a group of people to maintain coordination is also very important, the most bogey is the team everyone, or individuals at different times the style is not the same. Because the style is different, in from a style to escape to another style, thinking will card a card. In addition, the interface naming style is not the same, it is easy to use the interface incorrectly.

For example, there is an iterator class, to determine whether the advance is reasonable, there are strange names, Hasmove, Hasmoveelements, Iscurvalie, Isvalie, IsOk Islegal. Or the judge has several elements, the name getlength, length, size, numelemnts, totalelements. You use those classes, probably scold the original code of the group of people too stupid. But think about it, there are a few people who will keep the style consistent.

In fact, the style itself is not good or bad, the most afraid of is not unified, choose one, then use it. But the reality is often a group of people with a project, each have their own writing, but also despise the way others. If a is called STL that style, lowercase underlined, b to take the Life of MFC, C named as Java kind, looks very tired. This problem is very common, write code a lot of people are very smart, also very proud, often feel that they do is the best.

Another point is that those function interfaces of the same function class, if they have the same function, should be the same name, do not mess.

A bunch of people will do one thing together, they will establish rules, such as playing games together, go out to play, and negotiate a time. There is a class of people when people talk about the rules, he does not make a sound, or do other things, such as playing mobile phone texting and so on. The rules are fixed, they are not clear, they always ask, or foul the strange rules are unreasonable. This kind of person is very influential in morale, observe, you should have similar people around.

5. The last one, the old principle, Keep it simple and stupid.

The program is first for people to see, after the computer is seen. Must be simple. For example, interface design to the simplest, do not think of this interface will be used to add, to think of the future may not be used to remove. If you are narcissistic, think you are smart, such clever code can also write, in the future there is no software to write out, attention, so think there will be a problem. Because the more ingenious the code, the more difficult to understand, the more error-prone people. In fact, simple code is difficult to write. The best design should be taken for granted, and it is logical to feel less ingenious. < grandson > There is a sentence, the fighter, no fame, no Yong Gong. Because they go to war, fight before the win, there is no need to be very brave, very fierce to win, all logical, as if there is no difficulty, nature will not be praised. Similarly, a tricky way to solve a problem is to fall in.