1.代码规范
拜读了构建之法，感触颇多，从代码规范开始说起吧，书中将其分为风格规范和设计规范。并且详细的阐述了一条条规则。下面是我对代码规范的理解：
1)外在规范
代码，是给机器看的，这不错，但同样它也是给人看的，因为代码随着时间的推移总会产生变化。到时会有不同的人来修改检查代码，换句话说，代码也具有生命，一段时间需要重新修改，这样才会有生生不息的生命力。
下面说一些我所理解的外在规范重要环节：
Ⅰ.注释：这无需赘述，因为大的工程往往几十几百万行代码，如果不加注释就好像天书一样，因为文字描述的确非常重要，它可以让阅读者尽快地了解编写 者的核心思想，并对其进行修改，从而使代码焕发出新的生命力。再者说，一些大的软件用户就可以直接打开看到他们的代码，可是没有注释，这就注定我们对 代码的修改毫无头绪，所以注释对规范性来说是首当其冲的。
Ⅱ.缩进：使用四个空格，不用Tab间的原因是Tab在不同的情况下会显示不同的长度。
Ⅲ.行宽：必须限制，限定在100字符，否则严重影响用户阅读。
Ⅳ.括号：括号的作用是表明逻辑优先级，括号不规范的的后果是，连续出现了许多错误，找得焦头烂额，却发现原因在于少了几个括号，为了几个括号可能 好几天的成果付之一炬，一点也不值得。
Ⅴ.断行与空白的{}行，分行：这两个放在一起来说吧。许多人喜欢把一大堆东西写到一行，美其名曰显得紧凑。可是带来的后果是他人阅读的障碍和无尽的麻烦。记得高中学习的时候总喜欢借同学的笔记来看，有的同学一页笔记写得密密麻麻，虽然重点都标出了，但是十分乱套，一页的字。而有的同学呢，则写了好几页，不仅看着赏心悦目，知识点也可以一目了然，我想这和编程一个道理吧。
Ⅵ.下划线：用来分隔变量名字中的作用域标注和变量的语义。
Ⅶ.大小写：多个不同单词组成的变量名，用大小写区分更方便读者观察。
总而言之，这些规范不是做给机器的，是做给人的，因为代码具有生命力，它对机器的命令和对人的反馈同等重要，它需要与人好好的沟通，就像一本无价的书可以告诉我们世间所有的秘密，我们得到了却不懂里面的文字，无法操作，也没有用处。
2）内在规范
这里的内在规范就与前不同，外在规范很容易，无非是费点时间，花点精力，对能力并无什么太高的要求。而内在规范就是真正考察一个程序员实力的时候了。
Ⅰ.函数：只做一件事，并且要做好。
Ⅱ.函数最好有单一出口。
Ⅲ.错误处理：这里就是功力所在，这里考察一个程序员的心思是否细腻，是否洞察到所有的异常，并且在处理错误的过程中可能会产生新的未知的错误，这些错误很有可能改变你的思路以及你的想法，这一点需要注意。所以处理错误是非常重要的，它直接体现了我们的应对能力以及变通能力。
Ⅳ.模块化：这是一个程序员编程思想的体现，并且可以很好的对代码进行掌控和布局，达到内部规范的效果。
Ⅴ.用户需求：这一点其实也是属于内部规范，因为软件编写为了用户，如果编了用户无法使用，又有什么意义呢。
总而言之，编程其实是我们能力的展现，它不像绘画音乐那样可以天马行空的发挥我们的思想和想象力，但是这并不表明这些内部外部规则就可以束缚我们，不管是规则也好，需求也罢，都需要我们有足够的能力去想去应对。简而言之，编程是在众多规则掩饰下看似木讷的艺术，在规则之后，是程序员天马行空的想象和福尔摩斯似的逻辑。
2. 列一个checklist
|
阶段 |
检查项 |
结果 |
|
需求分析 |
用户需求是否有矛盾 |
|
|
用户需求是否现实 |
||
|
用户是否有默认的需求 |
||
|
设计 |
设计人员是否有能力完成 |
|
|
在设计中可能遇到的困难 |
||
|
设计人员分组模块化设计 |
||
|
不同组的模块能否正确衔接 |
||
|
统一规则，标准 |
||
|
制定短期时间规划 |
||
|
开发 |
检查代码的功能是否简洁 |
|
|
检查方法的使用是否有重合 |
||
|
处理错误代码 |
||
|
检查代码的效能 |
||
|
检查代码的可移植性 |
||
|
进行单元测试 |
||
|
设计并检查是否用户友好型 |
||
|
检查系统承受能力 |
||
|
对代码进行优化 |
||
|
检查是否遵循标准 |
3. 效能分析和测试
4. 用户需求
1）功能需求：
Ⅰ.用户的功能需求有些时候是矛盾的，需要及时提出并加以修改。
Ⅱ.用户提出的功能有些用现在的技术手段难以实现。
Ⅲ.有些需求用户不会提，因为在他们的字典里，那是必须的，所以事先一定要确定好。
2） 非功能需求：
Ⅰ.赏心悦目的界面，以及独特的点都是软件的加分点，想想看有多少人为了听林志玲的声音而使用的高德导航就知道了。
Ⅱ.软件的正常运行也同样必不可少，试想谁会使用一个经常自动崩溃的软件呢。
Ⅲ.人性化关心:虽然这里提这个有点不符，但是打感情牌也不失为一些软件长期存在的理由。
5. 过程控制：燃尽图、鱼刺图、甘特图
1） 燃尽图
燃尽图（burn down chart）是在项目完成之前，对需要完成的工作的一种可视化表示。燃尽图有一个Y轴（工作）和X轴（时间）。
2） 鱼刺图
问题或缺陷（即后果）标在"鱼头"外。在鱼骨上长出鱼刺，上面按出现机会多寡列出产生生产问题的可能原因。
3） 甘特图
以图示的方式通过活动列表和时间刻度形象地表示出任何特定项目的活动顺序与持续时间。基本是一条线条图，横轴表示时间，纵轴表示活动（项目），线条表示在整个期间上计划和实际的活动完成情况。它直观地表明任务计划在什么时候进行，及实际进展与计划要求的对比。
比较：燃尽图是对时间进行分析，工作量进行分析。
鱼刺图是对缺陷进行分析和解决。
甘特图是对任务量进行分析解决。
6. PSP
|
工作 |
类型 |
日期 |
开始时间 |
结束时间 |
中断时间 |
净时间 |
|
阅读构建之法 |
读书 |
2016.3.15 |
18：00 |
18：50 |
0min |
50min |
|
查阅相应的知识点 |
查阅 |
2016.3.15 |
19：00 |
19：30 |
0min |
30min |
|
编写随笔 |
随笔 |
2016.3.15 |
21：00 |
22：30 |
30min |
60min |
|
对比软件 |
随笔 |
2016 |
22：30 |
23：00 |
0min |
30min |
7. 从范围的角度，对比一类软件（3个软件）
|
范围 软件 |
人人 |
微信 |
微博 |
|
适用范围，年龄 |
所有 |
所有 |
所有 |
|
圈子范围 |
中 |
小 |
大 |
|
使用热度 |
小 |
大 |
中 |
|
功能度量 |
差 |
优 |
良 |
|
访问他人 |
半限制 |
有限制 |
无限制 |
|
界面友好 |
看不懂 |
很友好 |
一般般 |
|
系统测试 |
经常崩 |
很好 |
很好 |
|
存在可用数据潜力 |
极大 |
少 |
少 |
|
总结 |
人人俗称校内，败在它的圈子有限，校内人不像社会那样圈子互相融合，仅仅是个孤立的小群体，再加上用户软件之类的做的不好，所以不常用，但是数据潜力极大，如果更改方式，必定有所作为。 |
微信是现在的主要手段，其优点是极大程度的保护了人们的隐私，我的好友能看到我的圈子，非好友则看不到，这也降低了我们对日益复杂的网络的警惕。 |
微博的特点是在上面可以随便评论，没有任何的后果。可以发泄情绪不满，上面有各种人的动态，名人也好，朋友也罢，满足了我们的好奇心和众多少女的动态追星梦。 |
|
未来预计 |
不好说 |
维持现状，稳步提高 |
维持现状 |
本篇随笔字数：2551