We often hear from our peers what projects we have done and what projects XX has done. When talking about the project, you will be excited. Many new students and new programmers often do not know any projects or the relationship between projects and their own growth. Some even claim that they have been programming for several years, I have never had any project experience. This is true. Only programmers who have participated in the project are real programmers. Those who have not done the project, although they have compiled a lot of programs, although proud of their own programs, but after all, there is a big difference with the programmers who have done the project, these differences mainly include:
1. Program Value
Programmers who have not done any project can write programs to learn how to improve their programming capabilities through programming. What and how to compile programs are determined by their own opinions, you cannot do anything you can. Programmers are not very concerned about whether a program can be used by others or sell for money.
Project programmers are not the same. The program he wrote is not for learning (although he participated in the project with a learning attitude), but for sale as part of the product, compiled programs must be put into daily operation. He has no choice but to complete program functions. The value of a programmer is reflected by the price sold by the program and the use of the program.
2. Program time requirements
Programmers who have not worked on projects decide the length of time for programming. When you are happy to compile the program, you can compile the program. When you encounter other problems, it doesn't matter if it takes ten days and a half months!
Project programmers are not the same. They must complete programming within the specified time. They must not delay the program in advance. Otherwise, the whole project progress will be slowed down, because the project cannot be delivered to the customer on time, the result may be fined or even canceled due to delay.
3. Team
Programmers who have not done a project basically write a program in a single place. The program function is relatively simple and can be completed by one person more time.
The project programmer becomes a member of the project team. He is only responsible for a part of the project, or only writes a program, not all of it. Therefore, his program must be connected to the program prepared by others, his program must read others' data, and his data may be read by others. There is no error in each link here, and an error in one place will affect the entire project. Therefore, he must work closely with others in the team to complete his program.
4. learning atmosphere
Programmers who have not done any projects learn by themselves and learn by Google on the Internet. The learning content is very random and no one can supervise them.
Project programmers not only learn by themselves, but also by Google on the Internet, but also by going to the project owner, to others in the project team, and to customers. What you learn is also targeted. Learn detailed program design plans from the project owner, learn program interfaces, data interfaces, and learn business and needs from the customer. The program quality should be verified through testing and user use.
Therefore, participating project programmers can overcome self-righteous misconceptions, establish the idea of programming for customers, and measure their own value based on the value of software sales; establish team awareness, integrate yourself into the team, be proud of the team, and be ashamed of the team; learn to view program design from the overall situation in the project, learn to judge the difficulty of the program, learn more practical program methods and algorithms.
So what is the project? The project mentioned here may be different from the general project definition. The project here generally refers to the sum of the design, development, production, and maintenance work performed by the software company or internal project team according to the customer's requirements. It only includes software-related fees, and other hardware, network, and software environment fees are not included here.
There are large and small projects, some large projects are measured in, and some small projects are measured in, which is very different. Because there is no standard, different people have different definitions of the project size. For example, some enterprises refer to more than 1 million of software as projects and over as large projects. Some small enterprises CALL software of more than 10 thousand yuan as a project, and more than 50 thousand yuan as a big project. The size of these projects depends on the scope and level of the customer's fund management. Generally, the larger the project, the higher the organization or enterprise's leadership should approve the project.
The size of the project I am talking about today is determined by the software project itself. It has nothing to do with the definition of the customer's project size. I think the project size can be considered in the following dimensions: Capital, developer month, and project complexity.
1. Capital
I think that in today's price conditions, more than 50 thousand and less than 0.5 million are small projects. More than 0.5 million of projects are large projects, and more than 5 million are super large projects.
2. developer month
Similarly, from 2.5 to less than 25 individual months are small projects. More than 25 people a month is a big project.
3. Project complexity
The complexity of software projects can also be measured by the number of users of the software, the number of tables in the database, and the number of records in the table:
Number of software users: 10-1000 people for small projects, more than people for large projects.
Number of database tables: 20-100 tables are small projects, and more than tables are large projects.
Number of records in the Table: 0.1 million-10 million is a small project, and more than 10 million is a large project.
In addition, the benefits that project operation can bring to customers and the complexity of the project's business logic can all be considered by the project size.
If a project cannot reach the level of a small project, we will not regard it as a project here, because many projects lower than a small project are personal programming, which is a little different from the characteristics of project participation.
So my advice to programmers is:
1. Take the initiative to participate in the project
Both large and small project programmers must work hard to participate, because only the project's own capabilities can be improved. Do not wait for others to select, but actively express your desire to join the project. During my project process, I often give more opportunities to programmers who actively want to join the project, because such programmers have initiative and work better. A project is an opportunity, and a project is an opportunity. The machine cannot be lost.
2. Do not release small projects
Programmers should not be small but not small. Only after several small projects have been done can programmers do big projects. Programmers who want to expand projects in one step will often lose the opportunity to exercise small projects. They often feel powerless After they participate in large projects. Although a project is small, it can also train people. programmers can have more opportunities to experience the role of the project owner. Learn to look at programming from a holistic perspective.
3. actively prepare to participate in large projects
For programmers who have already participated in small projects, they must seize the opportunity to actively participate in large projects. The larger the project, the more people they train. In large projects, you must learn to correct your position and learn from other team members modestly. When there are no projects at ordinary times, you need to make more technical preparations and pay more attention to possible large project development content. In project development, you can focus on understanding the relationship between different functional modules. Learn to look at programming from the perspective of association.
Based on my experience, I believe that programmers can get started only after 5-6 small projects, and programmers who have experienced more than 3 large projects have started to mature. Of course, we cannot exclude the genius of programmers. Some programmers will reach a very high level in a very short time. However, the growth of the vast majority of programmers must be catalytic through projects, especially for large projects. To put it bluntly, projects are like sunshine, programmers are like seedlings, and the relationship is so simple.
From: http://www.cnblogs.com/n216/archive/2010/01/04/1638649.html