Chapter 4 key building decisions (Code Daquan 2)

　　Once you are sure that the "build" Foundation is well established, the preparation will be transformed into a decision on a specific "build. Chapter 2 "Think twice: Preparations" discusses the design blueprints and building licenses in the software business. You may not have much say in those preparations, so Chapter 1 focuses on "What do you need to do after building ". This chapter focuses on the preparations that must be taken directly or indirectly by programmers and technical leaders. Before heading for a construction site, how do you choose to apply the work to your belt? What should you install in your car? This chapter discusses the equivalence of this transaction in software.

4.1 Choice of Programming Language)

Studies show that the selection of programming languages affects production efficiency and code quality in multiple aspects.

When programmers use familiar languages, production efficiency is higher than when they use unfamiliar languages. Programmers who use advanced languages have higher productivity and quality than programmers who use lower-level languages. Some languages can better express various programming concepts.

Language descriptions)

I have introduced many languages and will not write them here.

4.2 programming conventions)

In high-quality software, you can see the relationship between "conceptual integrity of architecture" and "underlying implementation. The "Implementation" must be consistent with the (guiding the implementation) "architecture, and this consistency is inherent and inherent. This is the key guiding principles for "build activities", such as variable names, class names, subroutine names, format conventions, and comment conventions.

In a complex program, the architectural guidelines balance the structure of the program. For the "build activity", Fang ze provides the underlying coordination, which combines each class) are connected to a complete design (Comprehensive Design), become its reliable parts. Any large program requires a control structure, which can unify the details of the programming language. The charm of the big structure lies in that each specific component can reflect the connotation of the overall architecture. If there is no unified rule, the things you create will be filled with different styles and appear chaotic and messy. These different styles put a heavy burden on your brain-simply to understand the differences (essentially casual) between different programming styles. One key to successful programming is to avoid random changes so that your brain can focus on the changes that really need them.

Before "build" starts, let's clarify the programming conventions you use. The details of the coding conventions must be accurate as follows: after writing the software, it is almost impossible to change the coding conventions that the software complies. Such conventions are everywhere in this book.

4.3 your position in the technology wave)

In my career, I saw the rise of PC star and the fall of mainframe star. I saw that the graphic user interface replaced the character interface program, I also saw the rise of web and the decline of windows. I can only assume that when you read this book, some new technologies will flourish, and Web programming that I know today (2004) will gradually disappear. These technical cycles (or technology waves) mean different programming practices, depending on where you are in the technology wave.

How you deal with your programming work depends on your position in the technological wave. If you are at the end of the wave, you can plan to write new functions in a stable and continuous manner for a large part of the time. If you are in the early stage of the wave, it is expected that you will spend a lot of time, it is used to identify unspecified programming language features, errors caused by debugging program code defects, and revisions to the Code to adapt to the new version of the function library provided by the vendor.

If you work in a very basic (simple) environment, you will find that the programming practices introduced in this book will be more helpful than the mature environment. As David gries said, programming tools should not decide your programming ideas (1981 ). Gries distinguishes "programming in a language ." Programmers who program in one language limit their ideas to those that are directly supported by the language. If language tools are elementary, the programmer's thoughts are also elementary.

A programmer who goes deep into a language-specific programming first decides what he wants to express, and then decides how to use the tools provided by a specific language to express these ideas.

Example of "going deep into a language for programming" (example of programming into a language)

Understanding the difference between "programming in one language" and "exploring a language-specific programming" is essential for understanding this book. Most important programming principles do not depend on specific languages, but on the way you use languages. If the language you use lacks the components you want to use or tends to encounter other types of problems, try to make up for it. Invent your own coding conventions, standards, class libraries, and other improvement measures.

4.4 selection of major construction practices)

Some preparations for "component" are to determine which methods you want to emphasize in so many optional practical methods. Some projects use Pair Programming and test-driven development, while others use single-user development and formal check. Both technical combinations may play a role, depending on the specific environment of the project.

The following checklist summarizes the specific programming practices that should be consciously used or excluded during the "build" process. These practices are detailed throughout the book.

Checklist: major construction practices)

Encoding

Are you sure you want to know how much design work will be done in advance and how much design work will be done on the keyboard (while coding )?

Do you have "encoding conventions" such as names, comments, and code formats "?

Do you specify specific coding practices determined by the software architecture, for example, how to deal with error conditions, how to deal with security issues, what conventions are there for class interfaces, what standards can be followed by reusable code, and how many performance factors are considered during encoding?

Have you found your position in the technological wave and adjusted your measures accordingly? If necessary, do you know how to "program in one language" without being limited to languages (just "program in one language ")?

Team work

Have you defined a set of integration processes-that is, have you defined a specific set of steps that require the programmer to check in the Code to the main source code library, must these steps be performed?

Are programmers paired programming, independent programming, or a combination of these two?

Quality assurance

　　Do programmers write test cases for them before writing code?

Will programmers write unit tests for their own code? (Whether first or later )?

Do programmers use the debugger to track the entire code process in one step before checking in code?

Do programmers perform integration-test before checking in code )?

Will programmers review or check other people's code?

Tools

Have you selected a version control tool?

Have you selected a language, a language version, or a compiler version?

You chose a programming framework or explicitly decided not to use it?

Do you decide to allow non-standard language features?

Whether you have selected and have other tools to be used-compiler, refactoring tool, debugger, test framework, and syntax checker.

Key Points)

Each programming language has its advantages and disadvantages. You need to know the clear advantages and weaknesses of your language.

Before you start programming, make some conventions (Convention ). It is almost impossible to "change the code to make it conform to these Conventions.

There are more types of "build practices" than any single project. Make a conscious selection of the best practices for your project.

Ask yourself, is your programming practice correct response to your programming language or is it under its control? Remember to "program in one language" instead of "program in one language ".

Your position in the technology wave determines which method is effective-or even may be used. Determine your position in the technological wave and adjust your plans and expectations accordingly.