无论怎么拖也总是要做的，我感觉自己的拖延似乎是毫无意义的浪费时间，我的拖延挤出来的时间都是在干啥，这真是让我反思。好了继续读代码大全，我开始烦了已经，因为它太厚了。过渡工程，这个问题把握好并不容易。一方面，我们希望系统健壮，如果组成系统的各个部分只在最低限度满足健壮性要求，那么整体通常是达不到要求的。软件健壮性不取决于最薄弱的地方，而是等于所有薄弱环节的乘积。构架应该指出每个部分，程序员为了谨慎而宁可做过度工程，还是做出简单的能工作的东西就够了。有些东西是不应该过分花精力的，这个错误我们也犯过，尤其一些一开始就知道以后很可能要重构的部分，大量的精力花在里面很浪费。
有些东西我还是看不懂的，比如说这个叫做管理复杂度的名词，跟着老师上了一个学期的软件工程概论了，学了很多关于项目的介绍，我听到的是时间复杂度和空间复杂度这都是在说算法，书上说是软件构建的核心，好吧原谅我还小，不懂关于核心的东西。除了这些也学了一些小的知识，比如类的接口应提供一致的抽象，如果违背的话可能会引起很多的问题，类的接口应当隐藏一些信息――如某个系统接口、某项设计决策、或一些实现细节，这些我是有点看迷糊了，接口那么多讲究啊。而且类的包含比继承更可靠，这个，我还是没有经验，有什么更可靠的，是安全性么？哦，下面有说了，继承会加大复杂度，好吧，原来还有这茬，真是感受不到啊。
然后是关于子程序的地方了，这和我们的单元测试是不是有点关系呢?创建子程序最主要的目的是提高程序的可管理性，当然也有其他一些好的理由。其中，节省代码空间只是一个次要原因：提高可读性、可靠性和可修改性等原因都更重要一些。有时候，把一些简单的操作写成独立的子程序也非常有价值。子程序可以按照其内聚性分为很多类，而你应该让大多数程序具有功能上的内聚性，这是最佳的一种内聚性。子程序的名字是它的质量的指示器。如果名字糟糕但恰如其分，那就说明这个子程序设计得很差劲。如果名字糟糕而且又不准确，那么它就反映不出程序是干什么的。不管怎样，糟糕的名字都意味着程序需要修改。只有在某个子程序的主要目的是返回由其名字所描述的特定结果时，才应该使用函数。细心的程序员会非常谨慎地使用宏，而且只在万不得已时才用。
读了这些感觉是涨了点见识，虽然是被老书了，但是有些知识是不会过时的，我这样的起步者真是很需要吃到这些知识的。