Software Knowledge classification (also about income)

# I haven't been here for a long time. Please use this article to clear the weeds!

The commonly used software knowledge classification method is keyword-oriented, but it seems that this classification method is quite wrong.

For example:

· Programming language and Program Design

· Software engineering and software methodology

· Software project management

· Software requirements

· UML

· Modeling

· EXtreme Programming

· Software methods/Software Engineering

· Object-oriented

· Software quality, software testing and maintenance

· Software Process

· CMM (Software Capability Maturity Model)

· Design Model

·......

The main reason why "design patterns", "Extreme Programming", and "Object-Oriented" become different categories is that they use different keywords, rather than what is essentially different between them.

The advantage of such classification is that it is more convenient to find a book, but the disadvantage is that it is less helpful for learning and a little mistaken.

Therefore, we need a new software knowledge classification method:

The direct knowledge of software can be divided into three categories:

① Knowledge used to create conceptual boundaries and optimize the logical relationships between concepts. For example, object-oriented analysis and design.

② General domain knowledge used to implement concepts and logic. For example, a programming language.

③ Specialized domain knowledge used to solve specific domain problems. Proportional algorithm.

In many cases, ③ is not necessary, but ① and ② are inseparable, and there is no problem of being serious or serious. There is no concept to form logic, and there is no logic to define it completely. Without the concept and logic of a carrier (such as a programming language or UML), it cannot be expressed. In fact, the evolution of programming languages is largely to make this expression easier.

The indirect knowledge associated with software has four categories:

① Requirement development and description. For example, write the Specification Description. ※1

② Estimation. For example, Function Points and methods.

③ Test. For example, acceptance testing.

④ Software engineering and methodology. For example, cmme and agility.

※1. You can count requirement development as a direct knowledge of software.

Based on the preceding classification, we can recreate a classification form.

Direct knowledge about software:

· General domain knowledge

· Programming language (C/C ++, Java, C #, Python, Perl, etc)

· Framework and class library (MFC, boost, struts, hibernate, etc)

· Platform (Windows API, POSIX,. NET Framework ※2, Java API, C/C ++ Runtime Library

· Computer architecture (CPU commands, virtual storage, etc)

· Practical skills (debugging methods, code generators, etc)

·......

※2 sometimes, the boundaries between subcategories are not easily defined. One of the main reasons is that there is a concept like. NET framework that covers too much content.

· Create and optimize concepts and logic

· Object-Oriented Analysis and Design/Structural Analysis and Design

· Design Model

· Reconstruction

· Contractual Programming

· UML ※3

·......

※3 in terms of form, UML is more similar to a programming language, but it may be a more appropriate choice here.

· Expertise

· Graphics and image Algorithms

· Network protocols

· Artificial intelligence

· Numeric/non-numeric Algorithms

·......

Indirect knowledge about software:

· Requirement development and description

·......

· Estimation

· Estimation method. For example, cocomo and FP.

· Estimation. For example, the original method is counting.

· Test

· Software engineering and methodology

· Lightweight methodology. For example, agility.

· Big methodology. For example, cmme

· Comprehensive analysis. For example, the work done by man-month myth and man-piece.

 

In this form, management-related content is not included, and the main focus is on software development and directly related fields with software development. Management and so on will make further analysis in the comprehensive ability classification method chapter.

With the above classification, we can return to a very old topic:

How should we learn program design?

According to the nature of software, we can say that, because programming mainly solves the concept and logic problems, and the concept and logic problems are closely related to reality, there is no such Theorem to remember, then there will be a choice for application, and eventually a good product (work) will be produced. It can only be a learning point, a practical point, and a summary point.

According to the above classification, a specific possible learning method is:

Step 1: select a general domain knowledge.

For example: C # +. NET Framework, Java

Step 2:

In practice, gradually improve the ability to create and optimize concepts and logic

For example, the object-oriented method

Step 3:

If you have the opportunity: Study the knowledge of the selected specialized fields in depth and expand your general domain knowledge.

For most developers, there are few opportunities to directly access knowledge in some specialized fields. More often, they focus on the first two steps. In this case, there is a misunderstanding to avoid.

The more languages, platforms, and class libraries the better. Although sometimes there are practical rationality, It is a misunderstanding from the perspective of learning. When languages are frequently switched, platforms and class libraries are at the same time, it often wastes some opportunities to think about the essential problems of software, and ultimately it is not conducive to personal growth.

In reality, some enterprises are under too much pressure to survive and have no right to choose some things.

But considering that companies and individuals tend to exchange value in essence (you work, I pay ). The value of what you do does not come up (for example, new graduates can do the same). If you want to earn too much income, it is unlikely, or it may be dangerous.