From the programmer's perspective, talk about your own views on software development

From the programmer's perspective, talk about your own views on software development

Software development is scientific, engineering, technology, and handicrafts. Therefore, software development involves a lot of knowledge and experience. From the programmer's perspective, I would like to share my views on areas that I am familiar with and concerned with for your reference. [+ Humble and respectful. 〕

I often pay attention to two points: program quality and development efficiency.

1 From the programmer's perspective, the programmer must continuously cultivate internal skills:

(1) grasp the characteristics of a language at the language level. For example, c ++, value variables, referenced variables, and definitions and differences of pointers. In particular, how can we avoid wild pointers? Why must the basic class with virtual functions be interpreted as virtual functions? In the parameter initialization list of the constructor, is the initialization sequence of each parameter from left to right or from right to left? Why pay attention to this? If c # is used, it is better than c ++. However, there are still many things to note. For example, do I check whether the event object is empty before an event is triggered? And similar situations to avoid running exceptions. Do you remember to create and release objects like resources later? These should be clarified as much as possible, so that when using a language, the head has been vigilant against various traps, so as to ensure the quality of the program effect. Understanding of language features significantly improves development efficiency. Otherwise, [+ example shows how to cause errors and increase the cost of testing, equality, and problem fixing 〕

Familiar with library or function library supporting languages. For example, to use C ++, you must be familiar with STL and MFC. Otherwise, [+ how to reduce development efficiency and program quality, such as repeated code writing 〕

In terms of language-level internal practice, I am only talking about a subset of the knowledge that needs to be mastered. You can refer to help and some classic books. I personally know little about this.

(2) A good code style is required at the writing level. This is very simple and important. There are ready-made references. I will not talk about it more. For programmers who just graduated, pay more attention to this because the sample code of the textbook and the code written in the lab class are not standardized. One interesting thing I want to mention is that for Microsoft's set of things, I found that there are naming rules on MSDN. The topic "self-instruction code" in "code complete" is also well explained. In addition, I have seen a foreign country with detailed instructions on writing standard code books. What I feel is that, how can people sum up such concise and comprehensive guidance with such energy and thoughts?

2. Consider the team level. Team coordination and cooperation are required. Speaking of this, I am a little confused, because I have never been a leader. (+ Be humble, for example, "I just look at it from my own experiences and observations. Zhang Xiao and other colleagues can criticize this .") Let me talk about it for a minute or two. A team must have a role in task allocation, scheduling, tracking progress, implementing coding standards, code review, and internal testing. This role is usually held by a leader. In terms of task allocation, I think it is important to know the competence and focus of each member of the team. Otherwise, (+ various adverse situations ). I think it is difficult to reasonably determine the estimated time. I think the estimated time is a process of constant adjustment to gradually approach the accurate value. In addition, the accuracy of the preliminary estimated time customization depends on the group leader's familiarity with the project, the communication with members, and the reference for the completion time of previous tasks. If the team lead is not familiar with the project and determines the time, you can ignore this time value immediately and it has no reference value. Even if it is correct, it is the same as stepping on the shit in the metropolis of the text-it can only be said that luck is really good. Of course, this is an extreme situation. I want to do this in many cases when communicating with programmers. I think it is necessary to talk about the completion time of previous tasks. If the task description and completion time assigned to members are recorded, the data is of great reference value to the estimated time. From a macro perspective, the team lead can probably know which types of tasks and the approximate time for which individual tasks are completed, which is a basis for calculation. Of course, the premise is that there is a record, and in the case of a test, this completion time makes sense. It is easy to cause conflicts when you give a rough schedule. If it fails to be completed upon expiration, it may be due to low member efficiency; it may be due to incorrect calculation by the estimated time customizer-insufficient estimation of the difficulty of the task and insufficient staffing arrangements, or the task allocation is unreasonable (+ It is unreasonable to give a brief example of how to assign the task ). Therefore, if the programmer is required to finish the task on time, he must work overtime if the task is not completed. This is not true. It is unscientific and sad. The estimated time and the development efficiency of members need to be constantly adjusted. In terms of code review, Zhang xiaothat has been implemented and they are carried out every Monday. In my previous team, the code review cycle is one to four days. Generally, the team lead starts before work. When you are about to sign in the Code, the team lead will review the code one by one and propose suggestions for modification. Sometimes we exchange reviews. In short, we can ensure that the Code checked in every day does not have low-level errors. Many poorly structured and incorrect code is often removed at this stage. After the code is reviewed, the next step is to obtain the new version, compile, and perform a rough internal test. It is usually an exchange test -- I will test whether your functions are done well and whether there are errors. In this way, every time the Code is checked in, there is a deliverable program. In addition, the expected completion time is not so terrible. Even if my functions are not completely completed and the problems are not completely modified, at least one program is available every day, by keeping this bottom line secure, everyone is confident. In this way, the quality of the sub-control program is refined. By the way, code reviews often repeat. During the review, problems are found, comments are put forward, and modifications are made before they can be checked in. This process can improve the level of code writing. It can be said that at this stage, program quality, development efficiency, and programmer learning progress are the most unified. It can be seen that in terms of program quality control and development efficiency, the task of the leader role is heavy and requires the cooperation of all members. The above measures are necessary to control program quality and improve development efficiency. Of course, this is not what I have come up with. It is what I have seen, experienced, and tested in practice.

In addition, for the development of a team, pay attention to the short board effect. programmers with insufficient experience and ability often have certain restrictions on program quality and development efficiency. (+ Example ). What should we do? Old programmers (not necessarily leaders) are required. In this way, both program quality and development efficiency can be ensured, and the progress of these programmers can be promoted.

By the way, when my previous team started, the group leader was often busy, while some members were cool. This is usually because the team lead does not realize that it is the most important thing to mobilize the overall productivity of everyone. After I raised this question to the team lead, the form quickly changed. Of course, there are also some situations where only the leader of a task can solve the problem horizontally, and the rest of the people can only watch for it. This is another theory.

4. view the comprehensive quality of programmers. (1) You need to improve your sense of smell-sensitive smell of some parts of the program. Some paragraphs in Code Complete are very interesting. For example, the Code in the form of XX can be used to determine how to avoid detachment. Simply put, if a function or class code is too large (someone counts this boundary value), it is very doubtful that there is an error (+ Perceptual Analysis ). This is to be avoided. you can reconstruct an existing condition. (2) When you modify a bug.

5 from the development pipeline, the next step of coding-test. Sufficient tests must be ensured. In my opinion, this is unavoidable. Even if the voice is omitted and the strength is not enough, it is necessary to change the bug to the customer. Testing is also a good way to restrict programmers. Out-of-Question, test who restricts the customer. Otherwise, it is easy for programmers to meet their needs.