How do project-based companies accumulate technical skills -- Some Reflections on previous work

My first job was to write in a software company.ProgramThe main customer is a provincial power company. The work is mainly in the form of a project. The project has been signed for several months, from demand research to design, coding, testing, on-site debugging, and on-site maintenance. Usually there is a free time after completion, and then enter the next project. The requirements of each project are different, but they are all in the same power company. Although different customers solve different problems, they all belong to the same big business scope.

I have been away from this company for nearly a year. Sometimes, when thinking about past experiences, you can get rid of the confusion in this mountain and have some technical memories and reflections. Although the work is still going on, summing up previous experiences is also a fortune for the future. For others, it may be helpful. It is also hoped that a generation of programmers can accumulate their own experience and reduce the time for new people to explore in the dark.

The previous work is often of the project nature. One project is finished and another one is done. Each project has its own difference, solving specific needs. Every project is new, and it is difficult to form technical accumulation. Therefore, it is also quite painful for developers to work hard before dead line. It is a common phenomenon to work overtime and stay up late.

Now, although there are differences in the specific situations of every thing we did before, in general, the customer scope is in the power company and has a great commonality. If you plan carefully, you can still build a continuous architecture.

First, let alone specific projects and technologies to consider the basic business needs of power companies:

The main business needs of power companies are centered around the power grid. Each system is developed around the power grid, but its focus is different. Therefore, to build a continuous framework, the grid model is essential and can be said to be at the core. This model should include the topological structure of the power grid and various network elements (such as transmission lines, transformers, switches, generators, power loads, and so on ).

This model should also include the internal organizational relationships of power companies. For example, the relationship between various departments and groups in the power company and some important functions related to the power grid.

It should also include the relationship models between provincial power companies and cooperation organizations, such: the Relationship Model between power companies in different cities, the relationship model between power stations, the Relationship Model Between substations, and the Relationship Model between power units.

As shown below:

Building these models is completely unrelated to specific technologies and can adopt any appropriate technology. You can use Java, C ++,. net, or other appropriate things. Consider the maturity of technology and future development trends.

These models are relatively stable in the power company's business. With this, development will not start from scratch every time, and it can be built on a solid foundation.

For example, we need to build a system to monitor the real-time operation data of power grid devices. Then we can build the system on the power grid model, focusing on the real-time data and control commands of devices. There are some authority and process controls for monitoring, so internal organizational models can also play a role. For some monitoring work, cooperation measures should be taken by various power companies, power plants, substations, and power units. The cooperative organization model can be used.

Therefore, the development of this system may be like the following:

For another example, we need to develop a control system for equipment maintenance. This system needs to understand the topological structure of the network element equipment to ensure that some equipment can be repaired together, some devices cannot be powered off at the same time, and maintenance work should be arranged to evaluate the grid stability during the maintenance period. This system can be built on the basis of the grid model and focuses on the grid topology. The customer needs to make specific arrangements for the repair task, then the cooperation relationship model can be used. The system is as follows:

It can be seen that each system uses several models at the bottom layer, focuses on some aspects of the models, and then adds Personalized Requirements. This will speed up development and reduce the cost and time for the company to develop new systems.

How can we get this model?

First, we should learn from all the available knowledge. For example, industry standards and regulations promulgated by the State. Understanding these things can simplify our analysis process and avoid detours and mistakes. Or draw on similar products from other companies.

More importantly, we need to constantly establish and improve this model in the development project process, and implement the ideas on the drawings in a down-to-earth manner.Code.

For example, when we first developed the device monitoring system mentioned above, we should first consider designing a grid model to establish the object relationship between the grid element devices and realize the topological structure of the grid. We should not rush to the details of database design. After establishing a grid model, you can analyze the specific project requirements to enhance the robustness of the basic model. Then, perform specific project development on this basis.

Through such a process, the grid model can be well established for future development.

For another example, we need to build a system for power companies to manage the assets of Power Grid Equipment. At this time, we need to enrich the grid model and add the asset attributes of the device:

Note that this attribute must be separated from other attributes (such as real-time running data) to avoid adverse effects on the development and application of each other. On this basis, the actual functions of the development project are relatively easy.

In this process, we need to solve a difficult problem, that is, the contradiction between "urgent use first" and "Architecture first. It is hard to say that the situations of various companies vary widely. I can only say: even under the pressure of urgent use, we should also consider complying with the rules of the underlying model, and once there are conditions, we should gradually integrate the previously non-conforming architecture into a normal track.

Next, I will talk about my views on technology learning. A programmer must master advanced technologies. When the technology reaches a certain level, there is a certain understanding of various design methods, and then there will be a confusion: How should they apply these advanced technologies ?. Net and Java which is better, which is stronger for Linux and Windows, how should struts be used, what is spring, what are the benefits of ORM, how should we use design patterns ......

In fact, to answer these questions, you must not only consider the technology, but jump out of the Technical circle. From the perspective of users and businesses, we can analyze from top to bottom to understand what is important. In fact, those problems are negligible. There are no advantages or disadvantages of technology itself. We need to make a decision based on specific needs. Programmers should master the technology and then jump out of the technology to focus on the business in a specific field (maybe this business is the development itself, for example, you need to develop an IDE or are developing an operating system ), truly do some valuable things for customers and companies.