代码大全

精益求精。

代码大全笔记。
好的工匠知道完成某项工作要用哪样工具。也知道该怎样正确地使用。
编程方面的知识学得越多。你脑中的工具箱中就会有更多的分析工具。也会知道该在何时用这些工具。以及怎样正确地使用它们。
在软件领域里。专业的咨询人员有时会让你专用某种软件开发方法而远离其他方法。这样并不妥当。因为当你百分之百地依赖于某一方法论时。你就只会用一种方法去看世界了。
每位程序员都有许多工具。但并不存在任何一个能适用于所有工作的工具。因地制宜地选择正确工具是成为能有效编程的程序员的关键。
某些情况下。对于你所面临的问题还有其他更好的方法。你可能错失良机。这种工具箱隐喻能够帮助你把所有的方法、技术以及技巧留在脑海中—合适的时候即可拿来就用。
每个层次的注意事项。编程思维、编程风格、编程工艺、软件工艺、编程技术。
仔细的准备是必要的。而大型项目和小型项目之间也是有差异的。
事先做好计划能减小很多压力，让你的经验（曾经遇到的问题）来引导你吧。
创作引人注目的商业案例、
分析出全面而准确的需求、
创建高质量的架构

生命周期

使用高质量的实践方法是那些能创造高质量软件的程序员的共性。
这些高质量的实践方法在项目的初期、中期、末期都强调质量。

阅读顺序

• 低年级学生：第11章变量名的力量
• 初级程序员：第18章表驱动法。将复杂的逻辑判断转换为查表。从而简化代码的编写与维护。另外。本章中的一个示例说明了。面向对象设计并不只要因为它是面向对象。就一定会好于其他的设计。
• 自学编程的人。第7章高质量的子程序。本章详细讨论了子程序的命名和参数选择等问题。其中对子程序最佳长度的讨论颇有借鉴意义
• 高年级学生：第8章防御式编程。本章讲述如何面对严酷的充斥非法数据的真实世界。在遇到绝不会发生的事件和其他程序员犯下的错误时如何保护自己。
• 高级程序员：第4章关键的构建决策。本章关注的焦点是程序员和技术带头人个人必须(直接或间接)负责的项目准备工作
• 项目经理：第33章个人性格。程序设计是一项纯粹的脑力劳动。本章对挑选和培养优秀程序员提出了建议。
• 制定编码标准的人：第32章自说明代码。本章中有一段关于注释的精彩对话。它可能会改变您在制定编码标准时对注释的要求。
• 喜欢参与网上争论的人。第13。3节全局数据和第17。3节goto语句。听听学术界在这些问题上的争论也挺有意思。

核对表

前期准备
需求
架构
主要的构建实践
软件构造中的设计
质量
类的质量
高质量的子程序
防御式编程
伪代码编程过程
质量保证计划
变量
使用数据的一般事项
变量命名
基本数据类型
使用不常见数据类型的注意事项
组织直线型代码
控制语句
使用条件语句
循环
不常见的控制结构
控制结构相关事宜
表驱动法
测试
有效的结对编程
有效的详查
测试用例
关于调试的建议
重构
重构的理由
重构总结
安全的重构
代码调整策略
代码调整方法
工具
配置管理
集成
编程工具
美观
布局
自说明代码
好的注释技术

定义问题

(problemdefinition)
一开始就把事情做好是最合算的。

• 架构师吃掉需求。设计师吃掉架构。而程序员则消化设计。程序员是软件食物链的最后一环。
• 如果需求被污染了。那么它就会污染架构。而架构又会污染构建。
• 这样会导致程序员脾气暴躁、营养失调，开发出的软件具有放射性污染，而且周身都是缺陷。

  需求分析

  (requirementsdevelopment)。潜心分析需求

  计划、要求并且设计一个高质量的产品。
  需求、客户沟通、捕捉需求、动态需求、弄清哪些是最关键的需求
  弄清架构要素
  定义问题、要求、辨明当时的形势
  如果你正为某个高度迭代的项目做计划
  定下解决方案的规格（每个阶段）：规模、时间、人数、计算机台数
  设计解决方案的时候做出这种计划
  用Aztek的生产过程未必能造出好的劳斯莱斯。那么你从头开始做计划。
  设计轮廓、架构、设计、程序。

必备工具

在开始建造房子之前。审视：
蓝图(包含所有细节信息的设计详图)
全部(建筑)许可证
测量房屋的地基
CaperJones是SoftwareProductivityResearch(软件生产率研究)的首席科学家。他回顾20年的软件研究。指出他和同事见过不止
700种不同的编程语言。
40种收集需求的方法、
50种进行软件设计的方法、
30种针对项目的测试方法(Jones2003)。
三种主调的无数变奏：项目类型与典型实践

准备工作

准备工作的中心目标就是降低风险:一个好的项目规划者能够尽可能早地将主要的风险清除掉。以使项目的大部分工作能够尽可能平稳地进行。
目前。软件开发中最常见的项目风险是糟糕的需求分析和糟糕的项目计划。
因此准备工作就倾向于集中改进需求分析和项目规划。
构建活动的准备工作不是一门精密科学。要根据每一个项目的特点来选择特定的降低风险的方法。
具体细节随项目的不同。会有非常大的变化。

• 为什么合适的准备工作是非常重要的
• 尽早查找并修正错误：缺陷检测成本
• 如何判定，是否已经准备好开始构建工作了

  构建

  你对如何进行构建的理解程度，决定了你这名程序员的优秀程度。构建活动的质量对软件的质量有着实质性的影响
  构建(construction)、建筑工人(constructionworkers)、硬纸板(constructionpaper)
  按照一般的用法。构建是指建设的过程。构建过程可能包含有计划、设计、检查工作的一些方面。多数时候，构建就是指创建事物过程中动手的那些部分。
  正式和非正式项目的红头文件。构建有时也被认为是编码(coding)或编程(programming)。

  规划构建(constructionplanning)
      软件构建
          软件开发的核心活动
          每个项目中唯一一项必不可少的工作。
      构建实践
          在构建过程中，辨明当时的形势如何。
          在你开始构建的时候。项目前期工作已经或多或少为这个项目的成功或失败打下了基础。
          如果你看到失败的乌云已经出现在地平线上时，就退回到项目的前期工作吧。
  软件架构(softwarearchitecture)或高层设计(highleveldesign)。精心设计架构

规划

项目规划。详细设计(detaileddesign)。活动、技术和诀窍
    代码格式
    代码布局
    设计方法
    用户界面设计、组件
代码可读性、编码(coding)
    设计并编写类(class)和子程序(routine)、命名和质量。构建细节：创建类的步骤
    创建并命名变量(variable)和具名常量(namedconstant)。
    语句。组织语句块。选择控制结构(controlstructure)。
    容器类(containerclasses)、科学计算函数、数据库访问组件
    数据类型
    编码标准

方案选择

无论何种项目。都会对准备工作进行剪裁。使之符合项目的特定需要;在构建活动开始之前。准备工作要做周全：
建造摩天大楼用一种方法。
建造普通住宅用另一种方法。
建造犬舍用第三种方法。
项目种类与典型实践
项目种类与典型实践
高迭代式与序列式
性命攸关的系统往往要求采用更加序列式的方法—需求稳定是确保超高等级的可靠性的必备条件之
无准备的序列式与迭代式
有装备的序列式与迭代式
方案选择
方案选择
UpstreamPrerequisites
MeasureTwice。CutOnce
构建活动差不多占整个项目成本的65%。
有的软件项目最终会进行两三次(甚至更多)构建。
将项目中最昂贵的部分执行两遍。这无论在软件行业还是在其他行业都是愚蠢的主意。
构建活动的地位示意图
构建的重要性

项目管理方法
    分阶段(phase)进行、还是迭代式(interation)进行。
    新语言、新开发过程、新方法论
    软件项目
    有没有更好的工具、启发、启发式、探索式、受益
    灵活轻量级的开发方法
    严格重量级的开发方法
    演进式交付(Evolutionary Delivery)
    敏捷编程(agile programming)
    调用别人的库，如砖块。自己编写那些现成的代码通常是没有意义的
    自己编写库，如自己定制的高档家具
    适当的多层次规划对编程是有好处的。
    增量式开发：先做出一个简单可行版本。一次增加一小部分代码，直到得到一个完全可以工作的系统
    超大型的项目要更高级别的规划
    精心计划不意味事无巨细的计划或过度计划
    在后期改变细节的能力。改变不会出重大事故。安全、时间成本和物资成本
    核查。留有余地以保证安全。
    对结构进行超出常规的规划和建设（over-engineered）

调试

(debugging)、测试、系统测试(systemtesting)、开发者测试(developer testing)

系统测试。软件质量保证。
测试只是质量保证策略的一部分。而且不是最有影响的部分。
测试是不可能检查出的缺陷
制造了一个错误的产品
使用错误的方法制造正确的产品
这样的缺陷必须在测试之前解决。更确切地说是在构建活动之前。

单元测试(unit testing)。确定如何测试所写的代码。
集成测试(integration testing)
测试用例
什么是可行
什么是不可行的
脚踏实地测试

集成

(Integration)。将单独开发的多个软件组件集成为一体

保障维护

(correctivemaintenance)。风险防御、因地制宜
评审开发团队其他成员的底层设计和代码。并让他们评审你的工作。
润饰代码。仔细进行代码的格式化和注释
调整代码(tuningcode)。让它更快、更省资源。

文档

CapersJones发表的报告称：
一套100万行代码的软件系统
平均需要69种文档(8100)
需求规格文档一般有四五千页长
设计文档常常是需求的两三倍长
不太可能有哪个人能完全理解这种规模的项目的所有设计细节，甚至只是通读一遍都不那么容易。

重构

代码调优的技术和策略、评审、审查
高质量软件。提高软件质量是降低开发成本的重要途径

指标

在更短的时间内写出更棒的程序
用户的需求。项目的需求发生变动时帮助你成功地维护并修改已经开发出来的软件
开发效率。交付快，更快速地进行开发
预算不超
健壮、安全、漏洞少，遇到的问题更少。为什么会遇到那些问题。如何在将来避免它们。反复尝试和试错的结晶。
规范、弹性
掌控更大型的项目
优秀

过程隐喻

隐喻、类比、模型、概念化、泛型
完整、充分
春天播种了一个代码种子，希望秋天收获丰盛的代码
播种、培育、耕作、小步前进
生长、增量、迭代、累积、冲积层、珍珠、提炼
growing、accretion、incremental、iterative、adaptive、evolutionary
自适应、演进
writing、building
成果：速度和精读的提升、省时省力

其他

里程碑

思维训练。高质量代码习惯。编程原则是超越特定语言语法的。
丰富的理论知识研究、当今的理论发展水平、前沿的开发实践。
编程经验、编程技术、行之有效的编程实践经验技术、反映实践状况的产品级代码。
软件开发领域、项目（管理）经验经验技巧、开发策略
项目思考。需求分析。实用、有效、强大。
行动策略。具体情况作出更正确的决策。避免反复陷入完全一样的战斗
实质地改善编程质量并提高工作效率。

名片

畅销书作者
杂志主编
计算机科学与技术委员会（ComputerScienceandTechnologyBoard）
当艺术评论家聚在一起的时候。他们谈论的都是关于版式、结构以及意蕴之类的话题;而当真正的艺术家聚在起的时候。他们谈论的则是到哪儿才能买到更便宜的松节油。PablePN毕加索。

你在技术浪潮中的位置

自学程序员、经验不足的程序员、学生⇒参加过正规训练的程序员⇒软件开发者⇒优秀程序员、经验丰富的程序员、内行⇒分析师、软件架构师、项目负责人⇒业界大师与教授、技术带头人、技术领导。有些教授并不实际编写产品代码。教授们写出来的技术内容对于学生们的项目而言还行得通。但他们通常不知道如何在完整规模的开发环境中施展这些技术。⇒知识与商业实践大咖。

一般商业实践⇒学习并掌握不止一门语言是专业程序员职业生涯的分水岭⇒编程领域的大众技术、强大的软件开发技术、前卫的软件开发实践迅速发展⇒业界研究、学术成果、研究成果、专家经验⇒软件工程界软件开发领域⇒让那些关键性的研发成果现在就能为更多编程人员所用。

强大的编程技术已在学术论文和期刊里尘封了多年。
软件业界以及学术界的研究人员已经发现了不少行之有效的实践经验
足以解决自20世纪70年代以来编程领域中日益蔓延的大多数问题
可是这些实践经验很少在高度专业化的技术期刊之外对外发表
所以时至今日大多数编程的机构和组织还没能用上这些技术

有研究表明：一项研发成果从其诞生之日起，到进入商业实践阶段，通常要经历5到15年甚至更长的时间(RaghavanandChand1989;Rogers1995;Parnas199)。

专业经验

杂志上的文章
编程语言书籍
技术参考资料
其他软件著作

激动人心的项目

互联网、电影特技、医疗中的生命维持系统、航空、高速金融分析、科学研究、太空计划

扩展阅读

• ProfessionalSoftwareDevelopment。专业软件开发。Mcconnell2004第16章描述了专业技能培养计划。
• ThePsychologyofComputerProgramming。Weinberg8100，GeraldWeinberg的经典著作。
• 硬件参考手册。Intel或Motorola的。
• 函数手册。MicrosoftWindows或Linux操作系统的。
• RethinkingSystemsAnalysisndDesign。Weinberg1988。OntheOriginsofDesignerIntuition(论设计直觉的源泉)这一章。另一个关于软件方面的耕作的比喻。
• WhatSupportstheRoof。是什么撑起了天花板。Starr2003。深入阅读关于构建隐喻的引申。
• TheStructureofScientificRevolutions。THomasKuhn。科学变革的结构。隐喻、模型(model)以及范型(paradigm)中的试金石和金典。在一个达尔文周期中，科学理论如何相对于其他理论而诞生、发展并消亡的书。于1962年首次发布。奠定了科学哲学的基础。该书短小精悍。列举了大量科学中隐喻、模型以及范型间此消彼长的有趣示例。
• TheParadigmsofProgramming。Floyd.Robertw.编程范型。1978年图灵奖的颁奖演讲。这是一篇令人神往的关于软件开发中的模型的讨论。Floyd将Kuhn的理念用到了编程上。
• CommunicationsoftheACM(ACM通讯)。August1979。pp。455—460。

Java编程入门
高级Java编程
高高级Java编程

WISCA综合症或者WIMP综合症:
Why Isn't Sam Coding Anything?为什么Sam不在写代码
Why Isn't Mary Programing?为什么Mary不在编程