2014 Annual Week Meeting summary

Last year, I started to preach some of my development ideas in the week, and here is a summary of last year's main points:

Programmer's accomplishment

Literacy, I think it is a group for the benefit of the overall development of the group of rules. For society, it may be manifested as morality. People living in different circles, there are different requirements of quality. Literacy is beneficial to the group and thus to the individual, but it may be detrimental to the individual in particular. For developers, I can think of: 1. Responsible for the code, do not have a passer-by attitude toward the code; 2. Code style and code comments, code style and code comments must be unified. For the application, the amount of comments can be slightly less, for the base platform and library, comments must be strict and rigorous; 3. Review, we help everyone to form a unified code of conduct; 4. Team awareness and initiative, to create better performance for the team. 5. Proactive communication, including exchange of work situations and knowledge exchange. Hold your knowledge in your own hands, and you will stay in that position forever. Their successors should be nurtured by themselves. Technical exchanges, should not stay in this is not a problem at present, and to consider the expansion, ask more questions like that is not better.

Comments and naming of code

Code comments and naming is the appearance of a program. The architecture of code is the temperament of a program. Temperament, everyone may think it is more important, but the appearance of the same is important. Beautiful appearance, can make people happy work, good name same. Good naming can not only be enjoyable, but also help you to understand the program more easily, while good naming helps you to better think about how you are going to implement the program. If you can name it clearly, that usually means there is a problem with your program structure.

A valid comment should be made, and the comment should describe your function, describe your structure, and describe your idea. Do not guide others, others may have a better way of achieving and thinking, to respect others. The structure and interface of the module, the method used by others, the part of the code algorithm, the temporary work-around section, require special comments.

Code schema

The code architecture is hard to generalize, but I think there are a few points to consider: 1. Program consistency, in the same application, there is a uniform parameter checking principle and return value system. 2. A clear hierarchy, a design of the architecture diagram should be easy to draw out. 3. Encapsulation, the ideal package should be on the upper level only need to know the structure of the next layer of information, if there is a long member operation, usually means bad architecture design. It is possible to make a good structure only if the code is clear to the chest.

Debugging information, we should pay great attention to the reasonable arrangement of debugging information, debugging information should belong to what, whether it is necessary, should be carefully considered.

2014 Annual Week Meeting summary