IT foreign company things (5): Upgrade like a system

IT foreign companies (1): That's the case for foreign companies.

IT foreign companies (2): a variety of foreign companies

IT foreign companies (3): Strange interview

IT foreign companies (4): An exciting induction speech

 

After completing the induction training, you will start your program life in a foreign company. It should be noted that this article is not only limited to foreign companies.

For a long enough time, you will go from programmers, Senior programmers, team lead, to managers, and even ctor.

Let's take a macro look at this process and then taste the details one by one.

However, the process of review suddenly finds that the so-called programmer is the person who treats himself as a program.

The Tao Sheng Yi, his life is two, his life is three, and his life is three.

This statement roughly describes the process of the development and change of all things in the universe, while the Tao is the rule of the operation of all things in the universe.

Everything has its own law, gravity is a law, relativity is a law, and algorithms, operating systems, and computers that accompany our programmers every day, it can also be seen as a small part of the many laws of Nature. Only by mastering these laws can we control the operation of computers well.

System Development and programmer upgrade have not gone through such a process?

I. recognition rules: Tao

To build a system, you must first master the technologies required by this project. If the technologies are not used, this technology is an unacknowledged law. Before the project starts, systematic cognitive-related technologies must be required; otherwise, there will be a large risk.

To be a programmer, you must first master computer knowledge and grasp the knowledge of the system. Otherwise, your career will face great difficulties.

Systemization is crucial at this stage.

If you do not have a systematic understanding of related technologies in the project, the following consequences may occur:

• The designed system is not scalable.
• Application of clumsy Design Procedures
• A Bug occurs.

I don't know if you have participated in such a project development process. Due to the tight schedule and heavy tasks, the project team developed it when no one in the project system understands a certain technology, you have to download some Sample code from the Internet to copy and paste the program together. Even if you haven't figured out every configuration or line of code, you can use the Sample code, in this way, the system has almost no scalability in the later stage, and any flexible changes different from the Sample code are a very painful thing. The project team is as confused as a fly, however, I do not know the real consequences of each change. In this way, a large number of attempts and rework are required, and the entire project team is very tired and ineffective. This process is called a "Blind test ", that is to say, if you do not understand the principle, you can use repeated physical labor to traverse all the modifications that you think may be made one by one.

"Blind trial" is a common mistake made by programmers who are new to the workplace. When they first enter the workplace, they have hundreds of times of confidence and are in high spirits. They are eager to deliver results most of the time, when a task is released, it is not about the system to read the document, evaluate the scheme, and design the framework (these are all about sharpening the knife without mistake, it may be very effective in the early stages of the project. However, as the project progresses, the maintenance cost increases and overtime is often performed, with little effect. For experienced programmers, it is relatively easy to design a module in the early stage and add a module in the later stage.

In fact, we can also understand the appearance of this situation. After all, the boss is very keen and will not conduct research on so many events for you. Programmers always have the feeling of being pushed away by the skin, therefore, it is impossible to systematically master the technology and framework design. This is also an interview with many programmers. Each of them claims to have worked on Project A, Project B, and Project C, respectively, and applied the, B, and Project c technologies. However, when I went into depth, I found that, their knowledge of technology a, B, and c is limited to project A, B, and C, and they know nothing about others.

Without systematic understanding of technology, you may write a lot of clumsy programs, ugly implementations. Because you only know one of them, you don't know the other, you only know the other, and you don't know why. Originally, there was an efficient ready-made Technology in people's frameworks to implement this feature. You don't know, as a result, we barely pieced together the successful capabilities based on the one-sided technologies we learned, and naturally achieved the results. However, when we started to read the classic books in this area, we couldn't help but feel: "cough, it was easy to handle. At that time, I was so stupid to write more than N pieces of code."

Without a systematic understanding of the technology, it is more painful to add a new module when a Bug occurs. Because we do not understand the principle, we can only guess from the surface phenomenon, and then conduct a blind test.

Therefore, a systematic understanding of technology is a task that is not only responsible for projects, but also responsible for itself. If the boss is technical, he should be persuaded to take this into consideration when estimating the project time. If the boss is non-technical, the programmer should also leave the buffer time on his own. Otherwise, you have worked hard for eight hours during the day, and worked overtime for several hours at night and then for the boss. How do you make progress on your own?

If programmers do not have a systematic understanding of computer technology, the above problems also exist.

Your career is also not scalable. If you cannot systematically master basic knowledge such as algorithms, data structures, operating systems, computer networks, and computer composition, it may not be obvious in the early stages of programmers. You can also write good programs during any training, however, when you change the direction or platform, you will face great pain. We can see that the excellent programmers around us can quickly get started with C, C ++, and Java, both linux and windows, it is because of the good foundation.

Project and programmer's understanding of the law is actually nothing more than reading, documentation, and prototype development (for programmers, the internship phase is equivalent to Prototyping ).

Conclusion: the first stage of a project or programmer: Wu Dao, key words: "systematic"

2. Tao shengyi

When you have mastered the project-related approaches, that is, the technology, you must enter the project development.

The current project still has fewer systems composed of one process. Due to the increase in data volume, a multi-node distributed system will be developed. However, complicated systems, it is also basically done from a single-node system, that is, the process of creating a Tao.

When you have mastered computer-related technologies, you can become a real programmer. Of course, it is impossible for you to manage a project team from the beginning. The only thing you need to manage at this time is yourself.

Openness and robustness are the top priorities of this stage.

For projects, a good single-node system, the so-called openness, is that even if a single-node system is designed, it should also be considered from the perspective of designing a multi-node system, this makes it easier for the system to be expanded into a multi-node system. The so-called Solid State means that the single-node system must be small and full-fledged to implement most of the functions in a down-to-earth Manner, and there are a considerable number of test cases to ensure that the functions are correct.

Otherwise, the following consequences may occur:

• When a multi-node system is used, it is found that the single-node system requires a lot of modifications, or even a whitelist, and starts again.
• The single node is unstable, which leads to bugs in multiple nodes. But I don't know whether the error lies in the implementation of multiple nodes or the single node, which is difficult to locate.
• There are not enough test cases. When modifying for multiple nodes, the function implementation cannot be guaranteed to be correct.

Assume that a project with 100 nodes takes 100 days, not one day for each node, but 30 days for the first node, after the first node is completed, it is natural to expand the back. However, if the first node is not doing well, one node is created every day, and the design done yesterday is overturned and redone every day, even in 100 days, no more than 100 nodes can be reached. This is an extreme example, but has never happened around us?

For programmers, it is also necessary to make a good screw open and solid.

The so-called openness means that although we are only the lowest-level employees, the architecture of the entire system may not be able to reach us, it does not mean that we only stare at our own one-acre, three-point location to complete the function, instead, you must always consider the problem from the perspective of the entire project. Soldiers who do not want to be generals are not good soldiers. We suggest you do the following:

• In various project meetings, I often think about the problem from the perspective of the project manager and architect. If I want to design it myself, why did the Elders design it like this, and then ask questions from their predecessors. Although the original idea is naive, you can leave it alone. However, if you think like this for a long time, you will find that your design level will develop rapidly and slowly, you will find that you can give some suggestions at the meeting, and then you will find some defects in the design of your predecessors. Then you will find that you can provide appropriate improvement solutions for the current design, one day, you will find that you are no longer a single-node programmer.
• In addition to completing their own functions, let's take a look at the Code implemented by our predecessors, hand-draw some of their structural diagrams in our own way, and write down some of the components that we don't quite understand and think they can be used for reference.
• Try to use the learned architecture in your own module (maybe a very small module at first.
• You can repeat or read some New Classical Books, and strive to use industry-recognized theories to explain the design and architecture you have come into contact with, so that you can increase from perceptual knowledge to rational understanding. For example, the previous generation wrote these classes and used this design model. It also has the following advantages and disadvantages and is suitable for designing systems. This will not only help us to properly use the existing design in future projects, but also help us to accurately describe the project to others. Imagine that during the interview, a professional term is more effective than a wide array of topics.
• You can describe the architecture you have learned to your classmates and friends at the dinner table, and ask your friends to ask details. If you are not sure, go back and try again, although you are only a screw in the project, it seems like you have designed this system from start to end.

I would like to remind you that not all bosses like to be soldiers of generals and employees who are always asking questions.

The so-called Solid State means that all the connected knowledge should be mastered from point to point based on practices and theories. At this stage, there is a large amount of information, and there are many things to learn. We often get in touch with all kinds of technologies. We also have a taste of all kinds of technologies and finally form a similar situation, this hinders your development. During interviews, we often find that some candidates are limited to the ones they have done, and their knowledge is very weak, this will naturally affect his development from a single-node programmer to multiple nodes. Therefore, every time you get in touch with one aspect of the project, in addition to finishing the project at work, you can read more books and blogs on this aspect after work, so that you can change from knowledge to knowledge, we also need to know why and what problems exist. After dragging controls in MFC during the day, you should always read some in-depth introduction to MFC to understand its mechanism, read windows core programming to understand windows API and some principles, it is best to read windows internals to understand the story behind the principle. Otherwise, how can I open a speech to someone else during the interview to design a program in windows? If you cannot create a socket object, you can claim socket Programming. At least take a look at UNIX Network Programming. I have used NFS. Why don't I understand the filesystem mechanism in linux?

Of course, this is very tiring and time-consuming. However, when we graduated, we had no experience, no contacts, no funds, and sometimes it was time?

Cherish the fact that I have just graduated from the past few years to lay a solid foundation. When I am older, I am not so energetic. I have to take care of many things, but I still have to rely on my old man.

Conclusion: the second stage of a project or programmer: daosheng 1. Keywords: "Openness" and "robustness"

Iii. Life 2

For projects, when the single-node system is stable enough, it is time to extend the results to the client/server or master/slave, that is, the second-in-one process.

For programmers, when you are competent enough for personal work, you can bring an intern or junior programmer.

The key to this step is "communication.

For the system, the main consideration should be how to communicate between nodes, how to collaborate, and what protocol to adopt.

• Communication can be connection-oriented or not connection-oriented. It can be synchronous or asynchronous.
• Communication is hierarchical. Different Levels of protocols are applied in different situations. What protocols are used for heartbeat, what protocols are used for internal data block transmission, and what protocols are used to publish a service to provide external services, all should be considered.
• The internal structure of the data is the same as that of the interface through communication and agreement, which facilitates resolution and scalability, rpc? Serialized object? Xml? Json? Protocol buffer? Or a custom format?
• For clients that require frequent access, the connection pool is required and it takes a lot of time to establish a connection.
• The server should have restrictions on the total number of connections, as well as request Distribution and congestion control (not necessarily network congestion, but relatively slow processing at a certain stage)
• In the project, the communication module should not be developed by any two modules that require communication. Instead, it should be used as a basic module and be stable after a lot of tests, this enables people who need to use the communication module to focus on their own logic. When inter-module collaboration fails, there is no need to worry about the communication module transmission error.

For programmers, communication protocols with interns or junior programmers should also be considered.

Some codes are clearly written, but how can you accurately describe your ideas, ideas, designs, and difficulties when getting started? Based on the feedback from the other party, how does one confirm that the other party actually understands your information? There are many experienced programmers who face computers every day and neglect to communicate with people. It may be a pity that they can't speak out. For newcomers, his feedback does not necessarily mean that he understands it, or does not dare to say anything.

• Communication on important issues should be synchronized, that is, face-to-face communication. In this way, in addition to language feedback, some feedback can be obtained through expressions. Any problem must be divided into several stages in advance. It is best to have a topology in mind. The understanding of the next stage will depend on the understanding of the previous stage, when a brain puts all the information in front of the other party, anyone will be dizzy. Every time you go through a stage, you need to collect a feedback. As the sender of the information, you can prepare some key issues in advance to check whether the recipient actually understands the information, you can use "you mean... .
• Pay attention to congestion control. Every discussion should be completed within one hour, and the effect will decrease. The receiver feels that the information is full of brains and there is no clue, so it is difficult to have a clear idea.
• Each communication should have at least a meeting record and some conclusions. Otherwise, the discussion is equal to the white discussion. Otherwise, the team may often hold meetings, but the discussion is always on the same issues, it seems that every time I brainstorm, the efficiency is actually very poor.
• Important conclusions should be connection-oriented, that is, written (email, document, wiki) notifications, and written replies (OK, I am following the bug XXX ).
• You can create some connection pools, that is, the specific context of communication. After a certain period of time, the team can subconsciously create or reach consensus on some words to replace a certain context, which can improve the communication efficiency. For example, if "system a generates a report tomorrow", the programmer understands that there must be a unit test coverage report, QA understands that there must be a report on the current bug, and the performance test group should have a system performance test report.
• Communication is also hierarchical, and the most common mistakes, no matter who you are, the documents you write, and emails you send are the same. In fact, different information should be provided for different levels of people. For the team's personnel, principles, architecture, design, testing, how to do each step, how the results are, and the specific data should be described, for other team members, the specific data and steps do not need to be done. For the project manager, simply describe the principle, architecture, and conclusion. For the senior management, the team can inspect the work, the principle and result will be added. This is why a document contains abstract, summary, overview, concepts, detail, appendix, and so on. It is actually for different people.

Conclusion: The third stage of a project or programmer: Life 2. Keywords: "communication"

IV. B. III

For projects, when the Client/Server or Master/Slave has been running stably, it is time to develop one Master with multiple Slave instances, that is, the process of two generations.

For programmers, when you can bring an intern or junior programmer, you can become a small Team lead.

The key to this step is load balance and balance.

For the system, load balancing is the most important for two purposes:

• High reliability: When a server crashes, it does not affect external service provision.
• High Performance: multiple servers can do things in parallel, provide services, and speed up the corresponding time.

In fact, SLB uses Data partitioning (Data partitioning) or Data replication (Data replication. Data blocks point all requests to a server according to certain policies. For example, by time blocks, such as the mail backup system, all emails within a certain period of time can be placed in one server, all queries for this time period point to this server. For example, you can partition data by region, such as the map information management system, and put all the data in a certain region in one server. Data replication is about to replicate multiple copies of the same part of data on different servers. This ensures high reliability and evenly distributes requests to multiple servers, for example, if Google File system copies three copies of data, the server of a large website usually places the same content on different servers.

For programmers, communication is equally important, but it is no longer limited to one-to-one communication. It is no longer necessary to clearly express the problem, but to maintain a balance within the team. Both work stress, Project Fun, training opportunities, and growth opportunities should be balanced.

There are only two purposes:

• High reliability: The project will not affect the progress of the project because of a person's illness, vacation, or resignation.
• High performance: the strength of the entire team has not become a bottleneck.

This is not just a method of data partitioning and data replication.

The so-called data block means that different people are responsible for different modules, such as a frontend, a backend, a development, and a testing. This can bring high performance, because everyone's professionalism and experience will improve efficiency, but the problem is high reliability. If the person responsible for this module leaves, the change will greatly reduce efficiency. The working pressure cannot be well balanced. In the early stage of a system, backend development is very busy, while the front-end is relatively idle. in the later stage, front-end development is very busy, the backend is stable and therefore idle. Moreover, people are not machines, and there is a marginal effect. When taking charge of a module for a long time, the interest will be greatly reduced. I feel that there is no sense of accomplishment and there will be less growth. Therefore, the data replication method is also necessary, that is, through partner development, Knowledge sharing, code review and other methods, so that people in different modules can understand each other's modules, resulting in high reliability, that is, when one person is absent, other people can keep up quickly, or when a module is under great pressure, others can help with some auxiliary things, such as various tools and test cases, performance testing, or even some bugs with lower priority, not only balance the work pressure, but also access to new modules will make employees have a great deal, it is also more interesting to work.

Conclusion: Stage 4 of a project or programmer: Stage 3, key words: "balance"

5. Three life

If the Tao Sheng Yi, his second life, and his third life are the process of qualitative change, then the three life is the process of quantitative change.

For computer systems, if a master can well balance two or three slave instances, it can be expanded to ten or even hundreds or thousands. However, the principle is ideal, but the reality is that when the number of slave managed by the master reaches a certain number, the master is a bottleneck, and the high performance and high reliability of the master become a problem, at this time, you can use multiple masters for data replication to achieve load balancing. You can also make multiple masters manage the slave of a group. At this time, there should be a master of the master, that is, the system is layered. Hadoop's Multirack cluster is such a tree.

The same is true for team management. Each person's direct management energy is about 10 people. More than these people often have many omissions or exhaustion, when a team grows to a certain extent, it also needs to be layered. When the team grows by 15 to 20 people, we should consider selecting the master from the existing personnel, that is, the team lead or at least coordinator, which makes the organization a tree.

Conclusion: the fifth stage of project or program life: three life, all things. Keywords: "stratified"