分类目录归档：Study & Reading

IT技术这个行业混久了，作为一路走到现在的人，很多事情看不习惯，很多新手非常的浮躁，总是问，学什么赚钱，我要是知道学什么赚钱，我自己就去了，还轮到你么？再说不管什么行业，只要你处于金字塔的中上层，钱都不会少的。钱不是目的，他只是提升的自己的一个过程。新手遇到问题，劈头就问怎么解决，怎么办？甚至问题都不想清楚就问，我非常讨厌这样的提问方式。国内产出文章质量比较高的社区之一 —啄木鸟社区为想做程序员这个行当的人树立了很好的榜样，建议新人去看看，你不一定要学Python，但是其中的一些精髓是值得每个程序员学习的。 提问的智慧 全文在此，图如下：

这本书是近来难得一见的好书，认识字的都应该去读几遍，中文最近也出版了，各大售书网站都可以买到，打完折二十几块钱，非常物有所值，尽管英文版我已经读过，依然忍不住买一本中译本收藏，虽然中译本的名字我觉得很恶俗，这本书和商业思维没有太多的关系，中译本的作者自作聪明的加上这个小标题，有点恶心，另外将rework翻译成“重来”个人觉得也有点欠妥当，还不如不翻译，意思可能会更明确一点。虽然中译本有这样那样的问题，整体来说翻译的不错，不喜欢英文的可以买来看看，鼎力推荐——我本人不会有任何好处 那来的从错误中学习 中国人常说的一句话是：失败是成功他妈。作者引用哈佛商学院的报告证明，失败的创业者再次创业并不比从未创业的人成功的概率更高。有一类人非常明白这个道理，他们有个名字叫VC（风险投资人），VC非常喜欢那些已经或者曾经创业并且干得不错的人，换句话说这些人往往能从VC那里以比较小的代价（损失较小的股份或者少费周折）搞到很多很多的钱用于再次创业或者公司发展 。 何必壮大 这个观点有点意思，几乎所有的企业家都想将自己企业做大，富士康的员工超过百万，而作者觉得大未必是最优的，我非常认同作者的观点，我身边就有很多的公司每年几个亿的业务却只有10个左右的员工。公司越大责任就越大，不仅要自己赚钱还要照顾好这些员工，是一个有责任的企业家应该做到的，而不是压榨。如果你不能，那么就尽量提高效率，少招几个人吧，与人与己都是好事。 工作狂 引用里面的几句话：工作狂实际取得的成就并不比正常人高，他们自诩为完美主义者，但这仅仅代表他们浪费了大量的时间去关注次要的细节，而不是推动下一项任务。真正的英雄是早已想出办法、搞定一切，然后回家了。 Start making Something 我们身边总有这样的人在叹息“XXX我早就想到了，只是没有下手，如果当初我干了，现在也亿万富翁了”，这个观点很可笑，你大脑中有创意跟你实际去创建这样的事情一点关系也没有，在你人生中最有意义的使你做了什么，而不是你想过什么、说过什么或者计划过什么 没有时间不是借口 当你拥有某种极其强烈的渴望时，你就能挤出时间来，不管你身上是否还背负着其他的责任，事实上大部分的渴望不是那么强烈，于是他们总是拿没有时间来做借口进行自我保护。如果我不是这样，我今天已经做出了好几个开源作品了。 =====未完待续======

1、空间换时间法则 这个东西，稍微有点程序经验的人应该都接触过，比如在设计数据时候冗余了部分数据，避免关联表查询，减少开销，实际上也减少了查询时间，所谓空间换时间。还比如，我们将一个有点开销的计算结果存储起来，避免下次再次运算，减少时间消耗，再如，CPU的设计，设置了高速缓存，一级缓存，二级缓存，主存（通常所说的内存），其实一个硬盘和一个CPU也可以干活，只是干得不怎么样，因为硬盘和CPU之间速度实在是差别太大了，如是就有人想把可能要用到的数据预先加载到高速缓存或者主存中，慢慢形成了今天的个人计算机架构。 2、以时间换空间法则 这个其实也是天天在用的一个法则，只是一般技术人员看到“压缩”二字的时候，没联想到那么多，压缩就是最典型的拿时间换空间的例子，就是不断的重复前面已经存储过的存储地址，用来避免存取真实的数据。 3、循环法则 大部分稍微有点经验的人不会在同一个函数中循环两次同样的变量，但是仅限于同一个函数，假如在一个函数里调用了另外一个函数，那么就不一定了，很多人为了看似解耦的一个操作，在两个函数对同一个变量做了多次的循环。循环法则有几个比较经典细则： 第一、将代码移除循环，这是最容易想到的，当然，可以移除的条件是，每次循环都执行同样的某次操作。 第二、合并测试条件，高效的内循环应该包含尽量少的测试条件，最好只有一个，因此，程序员尽量用一些退出条件来模拟循环的其他退出条件。 第三、哨兵法则，在数据结构边界上放一个哨兵以减少测试是否已经搜索结束的开销。 第四、展开循环，展开循环可以减少修改循环下标的开销，对于避免管道延迟，减少分支以及增加指令级的并行性也有很大帮助。 第五、删除赋值，赋值的开销实际上在整个程序的执行过程中占的开销可以忽略不计，但假如你要在一个循环十万次的循环中赋值，那么开销就不能不计了，尽可能的在循环中减少赋值吧。 第六，消除无条件分支，快速的循环中不应该包含无条件分支，通过旋转循环，在底部加上一个条件分支，能够消除循环结束处的无条件分支。 第七、循环合并，如果你不小心做了傻事，那么合并两个对同一个变量循环操作吧 4、逻辑法则 利用等价的代数表达式。如果逻辑表达式的求值开销太大就将其替换为开销较小的等价代数表达式。 短路单调函数。如果我们想测试几个变量的单调非递减函数是否超过了某个特定的阈值，那么一旦达到这个阈值就不在需要计算任何变量了。 对测试机条件重新排序。在组织逻辑测试的时候，应该是降低开销的，经常成功的测试放在高开销的，很少成功的测试前面。 5、过程法则 打破函数层次。对于（非递归地）调用自身的函数，通常可以通过将其改写为内联版本并固定传入的变量来缩短其运行时间。 并行性。在底层硬件条件下，我们构建的程序应该尽可能多的挖掘并行性。 6、表达式法则 编译时初始化。在程序执行前，应该尽可能多的变量初始化。 利用等价的代数表达式。如果表达式的求值开销过大，就将其替换为开销更小的等价的代数表达式，比如换一种算法 消除公共子表达式。如果两次对同一个表达式求值，其所有变量都没有任何改动，那么我们可以用下面方法避免二次求值：存储第一次的计算结果并用其取代第二次求值。

《代码大全》是本好书啊，推荐所有有志于改善自己的程序，或者在编码上寻找进一步提高的人应该仔细研究研究。以下是摘抄自《代码大全》第二版中谈到关于怎样的代码格式更适合人类阅读，更能令人愉悦的Check List。对照List进行自检和反省，令人欣慰的是List中80%以上我都做到了，在我的上一个项目中做得比较失败，由于时间的原因，很多注释没有加上，逻辑也不够清晰。在重构中解决，借此反省。 一般问题： 格式化主要是为了展现代码的逻辑结构吗？ 2、你的布局方案能统一运行吗？ 3、 你的布局方案能让代码易于维护吗？ 4、你的布局方案是否有利于代码的可读性？ 控制结构的布局 1、你的代码中避免begin-end 或对｛｝的双重缩进了吗？ 2、相邻的块之间用空行分割了吗？ 3、对复杂表达式格式化时考虑到可读性吗？ 4、对只有一条语句的块布局始终如一吗？ 5、case语句与其他控制结构的格式化保持一致了吗？ 6、对goto语句格式化是否让其显眼了呢？ 还好目前PHP只有5.3以上版本才会有goto 单条语句的布局： 1、为逻辑表达式、数组下标和子程序参数的可读性使用了空格了吗？ 2、不完整的语句在行末似乎以明显又错的方式结束吗？ 3、后续行按照标准数码缩进了吗？ 4、每行顶多只有一条语句吗？ 这一点是团队中比较头痛的问题，很多人不按照这个规则来做，结果它成了一种风气 5、所写的每个语句都没有副作用吗？ 6、每行顶多只声明一个数据吗？ 注释布局： 1、注释与其所注释的代码所尽量相同吗？ 2、注释风格便于维护吗？ 子程序的布局： 1、你对每个子程序的参数格式化方式便于看懂、修改、注释吗？ 2、采用空行分割子程序各部分了吗？ 4、文件中子程序用空行清楚分开了吗？ 5、在没有更好的组织形式的场合，所有子程序都按字母排列了吗？ 这一点我没有做到，没有做到是没有想到这一点，以后编码注意了……