看《unix编程艺术》总结的出色程序员十大良好习惯
1）易于理解，利于组合。
2）“只做好一件事”
3）想清楚代码的组合，如何构建自己的一套API.（更加深入地理解真实世界系统状态。重构）
4）【目前紧缺】：对事物形式化清晰描述与理解的能力。并将其流程图，伪代码化（到了这步，写代码就是技术活了，基本可以查阅资料，尝试，试验，请教人而完成）
1）模块，封装和最佳模块大小
强内聚弱耦合：让你解决小问题的时候尽量少的去牵连其他问题。
模块不能太大：
模块不能太小:不然就得编写很多接口。传递很多参数。而传递参数的思维成本，代码量都比较大。
2）先定义函数名字，函数参数，返回值，返回类型；再为该函数API写注释。通常写注释的过程中，你会将事情说清楚。
3）紧凑性：一个API设计，一个模块设计，能否轻松或者比较轻易地装入人脑的特性。如果不手册就可以看懂这个函数，那最美妙不过了。一套API,而不是一个。如同list.h中所实现的，看到名字就可以了解个程序的大概。其它的我只要查阅即可，而不须了解全貌。易于理解，利于组合。
4）名字起得好与不好关系很大。因为这涉及到能否易于理解，易于分类。而分类对后续工作的影响很大。
5）正交性：每一个动作（API)只改变一件事，不会影响其它。改变每个属性的方法有且仅有一个。
“只做好一件事”
6）重构（重复代码）：修改内部代码时，而不影响引函数的外在行为。
“不要重复自身，真理的单点性”：重复会导致前后矛盾，产生问题，因当你修改重复点时，往往只修改了一部分而并非全部。通常，这也意味着你对代码的组织并没有想清楚。
可通过重构去除重复代码；如果有大量的重复样板代码，是不是可以用单一的更高层表现形式生成这些代码、然后通过提供不同的细调选项生成不同个例？【代码生成器】
7）SPOT原则。倡导一个数据结构，使得模型中的状态跟真实世界系统的状态能够一一对应。
“无混淆”：真实世界绝对清晰明确的状态在模型中也应该绝对清晰明确；
“无垃圾”：数据结构（模型）不能设计得太通用，应该合就好。
"解决一个定义明确的问题"：强单一中心。
“形式法”，“试探法”
8）简洁性：清瘦如禅般的简洁性。
禅教导我们：依附导致痛苦；
Unix说：分离产生价值。
9）模块内的单个函数是不是太大了？这个与行数，与内部复杂性都有关。判别标准：如果不能用一句话简单描述一个函数与其调用函数间的约定，那这个函数就可能太大了。
就我个人而言，若局部变量太多，就倾向于拆分成子程序。
*代码是不是有内部API?好的API应是意义清楚，不用看内部具体如何实现就可以理解的。如果存在多层嵌套调用函数，应该警惕了。
“透明性和可见性清单”
10）在写函数原型之后立即写一行注释，每个函数都是这样。《编程风格的元素》（the Elements of Programming Style）
11）协作进程:将复杂应用程序划分成几个协作进程，通过应用程序专用命令集或协议通信。
==========================
6 透明性：来点儿光
=========================
1）美在计算科学中的地位，要比在其它任何技术中的地位都重要，因为软件是太复杂了。美是抵御复杂的终极武器。
2）可显性：对用户而言，良好的文档有助于提高可显性；对程序员而言，良好的变量名和函数名有助于提高可显性。在软件中仅仅做到“不晦涩”是不够的，还必须尽力做到“有帮助”。
*如果程序设计使内部数据流程非常容易理解。
3）优雅的代码：优雅的代码不仅正确，而且显然正确；优雅的代码不仅将算法传达给计算机，同时也把见解和信心传递给阅读代码的人。
通过追求代码的优雅，我们能够编写更好的代码。学习编写透明的代码是学习如何编写优雅代码的第一关，很难的一关。
==============================================
感想分类二：关于复杂度的一些新思考与术语概念
==============================================
1）问题本身很复杂
2）通过例程来学习apue是比较简单，直观而有驱动力，成就感的。
3）是什么增加了问题的复杂性？哪些原理？
组合的多样性；
思考不深入，结构的影响；
4）原型开发要做哪几件事情？顺序地做？循环递归地做？
分析业务（要做什么，有什么限制，要实现什么功能），定义一套API函数名及参数，逐个实现并逐个测试；
5）复杂度是要花代价的，拼命不遗力气地减小它。
6）特定清晰性。清楚。明白。简洁。秩序。考察。观察。
7）灵活应用这些API，并且体会为何如此设计。从内核和应用两个层次上体会。不要眼高手低。因为我是靠后者吃饭的。而前者是体验痛快的。呵呵。