Preface
这本书的整个前言都是在推销这本书有多么多么的好。这本书的内容本身是很重要的，construction在整个软件开发中的重要性被低估了balabala....。当然这本书的全部内容自身也充满了技术类畅销书的一切特点，生动、活泼、图解、humor...
我们所需要知道的是本书确实集合了各种与construction相关的内容，包括一些本属于其他流程的相关内容，这些是许多先辈们通过实践得到的宝贵经验，而construction的过程对于程序员来说无疑是重要的。
废话不多说，直接上干货，开读！
Part I: Laying the Foundation
Chapter 1. Welcome to Software Construction
Mostly "construction" refers to thehands-on part of creating something.
所谓的construction就是以Coding && debuging为核心的具体程序实现过程。
对于个体程序员来说，本书的诱惑在于：“With a focus on construction, the individual programmer's productivity can improve enormously”。
Key Points
|
Chapter 2. Metaphors for a Richer Understanding of Software Development
2.1 Importance of Metaphor
这一部分讲的确实很有启发性，通过一般的科学史上的例子说明Metaphor（实际上是指Modeling）的巨大作用。它使得人们理解新的事物具有更加直观的一种感受，使得人们关注的角度不同，从而可能直接影响对于事物本身的理解程度。
最后作者强调的是作为一个比较新的学科，软件开发自身也以及出现了许多Metaphors，而我们在听到、认同它们的时候应该保持一种批判的理性，应该接受那些better的，而拒绝那些worse的，这样有助于我们对于软件开发自身的理解。
In general, the power of models is that they're vivid and can be grasped as conceptual wholes.
A good metaphor is simple, relates well to other relevant metaphors, and explains much of the experimental evidence and other observed phenomena.
2.2. How to Use Software Metaphors
读了这一部分我一下子就明白了为什么有些人推荐CC 说它和读波利亚的怎样解题由相似的体验了！确实，这里所说的Metaphors是说我们应该通过合理的隐喻来帮助我们对于一个刻板/严格算法的完整理解，建立一种更加具有启发式的宏观理解，这样将有助于我们对于软件内涵的理解，而不至于过分的去关注于算法的细节以至于容易忘记。这种想法正类似于波利亚在怎样解题中对于数学证明采用一种更加分析/启发式的方法而不是观点的几何原本式的严格演绎方式。这在我们解决软件的construction中是同样重要的！
从实践的角度上看，重要的是在实践中对于较为复杂的过程、算法，我们最好能够通过一个生动简洁的类比来帮助于我们理解、记忆以及对别人阐述。
A software metaphor is more like a searchlight than a road map. It doesn't tell you where to find the answer; it tells you how to look for it. A metaphor serves more as a heuristic than it does as an algorithm.
An algorithm gives you the instructions directly. A heuristic tells you how to discover the instructions for yourself, or at least where to look for them.
Thus, knowing how to approach problems in general is at least as valuable as knowing specific solutions for specific problems.
How do you use software metaphors? Use them to give you insight into your programming problems and processes.Use them to help you think about your programming activities and to help you imagine better ways of doing things. You won't be able to look at a line of code and say that it violates one of the metaphors described in this chapter. Over time, though, the person who uses metaphors to illuminate the software-development process will be perceived as someone who has a better understanding of programming and produces better code faster than people who don't use them.
2.3. Common Software Metaphors
这一部分给出了一些业内常见的对construction过程的类比，体现了对于coding不同角度、不同程度的思考。This doesn't mean that you have to learn how to make code out of waterborne sediment; it means that you have to learn how to add to your software systems a small amount at a time.
相对于一般的将coding称为writting，将其类比为“ Software Oyster Farming: System Accretion”以强调原型先行式的增量开发过程，类比为“Software Construction: Building Software”以强调在比较大的项目中我们必须要首先多想多构思，因为由于项目大所以之后的一些修改可能会带来较大的代价必须提前考虑，这与建造高楼十分的相似，我们需要前期的总体规划，然后一步步的按照计划加以实现，在此过程中还会不断的进行阶段性的检查；或者在应用时注重将其看作一个工具箱，根据项目规模特点的不同使用不同的开发方式“Applying Software Techniques: The Intellectual Toolbox”
（1）In incremental development, you first make the simplest possible version of the system that will run. It doesn't have to accept realistic input, it doesn't have to perform realistic manipulations on data, it doesn't have to produce realistic output—it just has to be a skeleton strong enough to hold the real system as it's developed. It might call dummy classes for each of the basic functions you have identified. This basic beginning is like the oyster's beginning a pearl with a small grain of sand.
After you've formed the skeleton, little by little you lay on the muscle and skin. You change each of the dummy classes to real classes. Instead of having your program pretend to accept input, you drop in code that accepts real input. Instead of having your program pretend to produce output, you drop in code that produces real output. You add a little bit of code at a time until you have a fully working system.
（2）In building a software product, materials are even less expensive, but labor costs just as much. Changing a report format is just as expensive as moving a wall in a house because the main cost component in both cases is people's time.
A well-planned project improves your ability to change your mind later about details.
It generally doesn't make sense to code things you can buy ready-made.（要格外注重代码的重用，不要无畏的浪费自己的时间，注意自己的时间是最宝贵的资源，不要重新发明轮子）
（3）People who are effective at developing high-quality software have spent years accumulating dozens of techniques, tricks, and magic incantations. The techniques are not rules; they are analytical tools. A good craftsman knows the right tool for the job and knows how to use it correctly. Programmers do, too. The more you learn about programming, the more you fill your mental toolbox with analytical tools and the knowledge of when to use them and how to use them correctly.
Key Points
-
Metaphors are heuristics, not algorithms. As such, they tend to be a little sloppy.
-
Metaphors help you understand the software-development process by relating it to other activities you already know about.
-
Some metaphors are better than others.
-
Treating software construction as similar to building construction suggests thatcareful preparation is needed and illuminates the difference between large and small projects.
-
Thinking of software-development practices as tools in an intellectual toolbox suggests further that every programmer has many tools and that no single tool is right for every job. Choosing the right tool for each problem is one key to being an effective programmer.
-
Metaphors are not mutually exclusive. Use the combination of metaphors that works best for you.
Chapter 3. Measure Twice, Cut Once: Upstream Prerequisites
这部分主要是介绍在正式coding之前进行一些准备工作的重要性，暂时略过。the preparation is tailored to the project's specific needs and done conscientiously before construction begins.
Some programmers do know how to perform upstream activities, but they don't prepare because they can't resist the urge to begin coding as soon as possible.
Then you know that before you implement a system, you need to understand what the system is supposed to do and how it's supposed to do it.
Key Points
-
The overarching goal of preparing for construction is risk reduction. Be sure your preparation activities are reducing risks, not increasing them.
-
If you want to develop high-quality software, attention to quality must be part of the software-development process from the beginning to the end. Attention to quality at the beginning has a greater influence on product quality than attention at the end.
-
Part of a programmer's job is to educate bosses and coworkers about the software-development process, including the importance of adequate preparation before programming begins.
-
The kind of project you're working on significantly affects construction prerequisites—many projects should be highly iterative, and some should be more sequential.
-
If a good problem definition hasn't been specified, you might be solving the wrong problem during construction.
-
If good requirements work hasn't been done, you might have missed important details of the problem. Requirements changes cost 20 to 100 times as much in the stages following construction as they do earlier, so be sure the requirements are right before you start programming.
-
If a good architectural design hasn't been done, you might be solving the right problem the wrong way during construction. The cost of architectural changes increases as more code is written for the wrong architecture, so be sure the architecture is right, too.
-
Understand what approach has been taken to the construction prerequisites on your project, and choose your construction approach accordingly.
Chapter 4. Key Construction Decisions
This chapter focuses on preparations that individual programmers and technical leads are responsible for, directly or indirectly. It discusses the software equivalent of how to select specific tools for your tool belt and how to load your truck before you head out to the job site.
your ability to think a thought depends on knowing words capable of expressing the thought. If you don't know the words, you can't express the thought and you might not even be able to formulate it
规范化，遵守这种语言的编程约定，保持整个项目具有一种整体统一性！
One key to successful programming is avoiding arbitrary variations so that your brain can be free to focus on the variations that are really needed
Before construction begins, spell out the programming conventions you'll use. Coding-convention details are at such a level of precision that they're nearly impossible to retrofit into software after it's written. Details of such conventions are provided throughout the book.
These technology cycles, or waves, imply different programming practices depending on where you find yourself on the wave.
The point is that how you spend your programming days will depend on where you are on the technology wave. If you're in the late part of the wave, you can plan to spend most of your day steadily writing new functionality. If you're in the early part of the wave, you can assume that you'll spend a sizeable portion of your time trying to figure out your programming language's undocumented features, debugging errors that turn out to be defects in the library code, revising code so that it will work with a new release of some vendor's library, and so on.
不要被一种语言自身的局限所限制，要programming into language not in 。Programmers who program "into" a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.
Understanding the distinction between programming in a language and programming into one is critical to understanding this book. Most of the important programming principles depend not on specific languages but on the way you use them. If your language lacks constructs that you want to use or is prone to other kinds of problems, try to compensate for them. Invent your own coding conventions, standards, class libraries, and other augmentations.
Key Points
-
Every programming language has strengths and weaknesses. Be aware of the specific strengths and weaknesses of the language you're using.
-
Establish programming conventions before you begin programming. It's nearly impossible to change code to match them later.
-
More construction practices exist than you can use on any single project. Consciously choose the practices that are best suited to your project.
-
Ask yourself whether the programming practices you're using are a response to the programming language you're using or controlled by it. Remember to program into the language, rather than programming in it.
-
Your position on the technology wave determines what approaches will be effective—or even possible. Identify where you are on the technology wave, and adjust your plans and expectations accordingly.
（Part I 到此结束）
826
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
