Abstract:What capabilities are required in software engineering and how can they be secured? Where do we need to focus on complexity?
Traditional operas
In this article, we will explore the following questions:
1. What capabilities are needed in software engineering and how are they guaranteed?
2. Where should we pay attention to complexity?
3. What is the purpose of the exam?
We must not be enslaved by technology by regulation.
A good state of mind is a must in order to bring people’s abilities into full play.
Focus on what you’re good at. So, in software engineering, how should this concept be implemented?
7. Why do we need to refactor our code and design? How to do?
8. How to ensure the quality of software development?
Ability to
Capabilities are the key to success or failure, and in this section we’ll look at what capabilities are required for software engineering and how to secure them.
The so-called software engineering capability is actually the ability to solve specific problems, that is, the ability to translate practical problems into project code.
Let’s talk about the development of people. There must be a soul figure in a project. Although we say that the current software engineering development is a team of cooperation, but the team must have one brain, not more than one brain.
How do we understand this? For small teams, let’s say 10 people, the leader is the soul of the team. The team leader needs to lead everyone to carry out research work, and finally make a conclusion. This place can be understood as the setting of the architectural design direction.
With that in mind, the next step is to distribute the work to each member. The team leader needs to closely follow up the progress of the project. For example, if there is a problem, the team leader needs to solve it together with the members, rather than entrust the members to conquer it alone.
If there are no problems and the team members solve them individually, then the team leader needs to understand the solution thoroughly, close it well and study hard at the same time.
The requirement for the leader is to assume that the whole team consists of 10 people, and only the leader is left. He should also be able to maintain the project.
Above are the requirements for team leaders. The first one here is learning ability, which is the ability to love and comprehend the unknown field.
Next, team members. The first task of a team member is to complete the assigned task well.
It requires the cultivation of understanding and execution. This needs a period of time to run in, the whole team can form a strong fighting force.
Another is the cultivation of subjective initiative. If the task is completed, you should take the initiative to find new tasks to do, when there is work to do, no work to find work to do.
It takes driving forces to develop initiative, and there are a few of them:
The first is the desire to realize self-value. The first is the confidence that innate talents will be useful. That is to say, everyone wants to do something, find their own value and integrate their value into the work of the team.
The second is extrinsic rewards, which can include material, reputation and so on. It means that good work has been recognized.
Above are the requirements for team members. Here, the first one is the executive power, which is the ability to complete tasks quickly after receiving instructions.
Now to the engineering method. The more popular one is agile methodology. There are two general directions in agile methodology: one is development team driven and the other is project manager driven. In either direction, one of the basic requirements of this methodology is that output is visible in the short term and that output is sustained.
This methodology, when used comfortably, can bring a great sense of achievement and morale to the team, thus motivating the team members to take work as fun. Agile methodologies can be formalized in real-world applications, such as people standing there and speaking for a few minutes each day. If that’s the case, it’s off track. To avoid formalization, you should be output oriented. Keep other team members updated on your status.
Now for the algorithms and the logic. For software technology, I think most of the time it is applied as an engineering technology, that is to take the tool and solve the actual user needs. In the process of using technology, we will constantly use a variety of algorithms and logic to adapt our business processes. For specific algorithms and logic, it’s all case by case. We’re not going to go into individual cases. We’re going to explore a very important concept, which is the problem of complexity.
I’ve worked with a lot of programmers, especially senior ones, and I’ve noticed that many of them have a habit of making simple problems more complicated. Be thoughtful. Be thoughtful. Here’s a very simple example. Let’s say we get a project, and the need for the project is to save the planet.
Many programmers get caught up in the fog of thinking about how to save the planet. The first thing to think about is how many planets there are, and then how many planets there are. Then, when the project is running and an input parameter is identified to specify earth, it gets into the task of figuring out how to save the earth.
If you ask why this is such a complicated question, my need is to save the planet. A very lofty reason was that he wanted to do a universal project that would support more planets in the future, making it easier to scale.
Based on this idea to do the project, the project will become more and more complex, the team will become more and more large, and the cost will naturally rise sharply.
Amazon has suffered a lot in this regard. On early projects, some programmers designed projects that were so complex that when they got promoted and left the project, others couldn’t take over and maintain the project, even if they went back to the original designers. Because it’s too complicated.
About processes and tools. These two aspects can be said together. The process needs to be simple and efficient, to hit the nail on the head and solve problems. The tools are the same. It doesn’t matter if everyone’s preferences are different — some people like interfaces, some people like the command line — pick the tools and processes that bring you the most productivity.
In the field of embedded driver development, some companies write code with plain text editors, and code reviews manually incorporate code by comparing software. While the amount of code in driver development should not be too much, a driver, for example, may have design problems if it is too much code. Even small amounts of code should be handled with advanced tools, such as code editing using VS Code, Eclipse, Qt Creator, etc., code review using platform tools such as Github, GitLab, Bitbucket, Gerrit, etc. Code can be viewed using Git tools (fork, Git Extensions), etc.
This is just one example to illustrate how to avoid using very primitive tools, which are prone to errors and inefficient.
The complexity of the
Now to the question of complexity, less complexity in software development is, of course, better. When we talk about complexity in general, we probably think about all kinds of complexity in logic, complexity in design, and actually complexity is involved in all kinds of aspects of the software process, so let’s take a look at some of the areas where we need to pay attention to complexity.
The first is naming conventions. So for example, LET’s say I have a variable called word. Some people like to write it as WD. This adds complexity to the definition of this variable, which is hard to understand from WD. This variable means word.
Whether it’s naming a variable or naming a function, we want to see names, and we should be able to understand what the variable or function is basically related to.
Therefore, careful use of abbreviations is an important prerequisite to avoid the complexity of naming rules.
The second is the complexity of the program logic. Linear sequential execution has a complexity of one, which is multiplied by the number of branches. A branch can be a condition or a loop. Therefore, avoiding branches as much as possible is an important way to reduce the logic complexity of the program.
If branching is inevitable, place it at the highest logical level possible. The purpose of this is to avoid diverging branches in the lower processing. Diverging branches can dramatically increase the complexity of a program.
The higher the complexity, the harder the program is to maintain, and beyond a certain level of complexity, human programmers cannot handle it.
The third is the complexity of the architecture design. Architecture design involves module design and system design. Extract as many common modules or subsystems as possible, such as security-related, journal-related, tool-related, etc., that might be called by all other business modules or systems.
When invoking these common functions, the simpler the better, and the caller does not need to care about the specific internal implementation, just how to use it.
The goal is to keep the programmer focused on the design of the business code.
Fourth, the complexity of system deployment. System deployment consists of several different phases such as development, test, and production. Regardless of the phase, the fewer steps you have to deploy, the less error prone you are. Some systems naturally require a configuration of many instructions. If this is the case, write a batch file to simplify the deployment steps for external users, turning multiple steps into one step.
Associated with deployment is the integration section. It would be great if you could automate it or create it from a template.
The fifth is the complexity of the test. There are white – box and black – box tests. The complexity of the white box tests is directly related to the complexity of the code level, and the higher the complexity of the code level, the higher the complexity of the white box tests.
An important aspect of white-box testing is not to take this part of the code away from the design of the actual business code. That is to say, the white box tests its attachment object is our actual business code, from the architectural design is a subsidiary layer, do not try to use any software design art or so-called programming art here.
The style of this code is simple and straightforward, with linear complexity.
The complexity of black box testing comes from business requirements analysis. It should be well documented, with clear instructions on the test procedures and expected results.
The sixth is the complexity of technology. Technology tends to become simpler and more powerful as it develops. Avoid using older technologies during design and development. For the choice of technical framework, do some research in advance. What framework to choose on the front end, whether to choose some UI libraries, and what framework to choose on the back end, whether to choose some program libraries, are in principle to simplify our learning process, improve development efficiency, and enhance the maintainability of the whole project. It needs to be done on a case-by-case basis.
The seventh is the complexity of the team structure. The composition of the team must be short and strong, more people do not necessarily easy. For example, Amazon advocates a two-pizza team, which means that the entire team can eat two pizzas. Roughly, it’s a team of about 10 people. Of course, this is just a reference.
The team must have a clear goal. All people are moving towards that goal, the division of labor may be different, but the goal must be the same.
Objective + division of labor is the key to the successful operation of the team. The idea is to break your goal into multiple tasks, each of which can be broken into smaller tasks, so that everyone else can do the same task. Keep yourself busy, not others.
(To be continued…)
Click follow to learn about the fresh technologies of Huawei Cloud