Feeling

    三人行,必有我师焉

   ::  :: 新随笔 :: 联系 ::  :: 管理 ::
  185 随笔 :: 0 文章 :: 392 评论 :: 0 Trackbacks

1、  程序员不擅长交际,但擅长说服别人。

2、  要习惯阅读别人的代码。

3、  通过阅读程序员的代码,主管可以从中了解程序员的能力,工作是否出色。

4、  在软件维护的过程中,被阅读最多的代码往往不是最好的代码,而是最需要重构的代码。

5、  如果程序根本无法正常运转,对其效率,适应性以及生产成本的评价就毫无意义。

6、  什么是程序中的毛病,在很大程度上取决于人的观点。如果这种毛病出现在你的程序中,你几乎不可能会认为它是毛病。

7、  在考虑一系列的程序的开发工作效果时,需要衡量开发时间的方差,而不是只考虑平均值。一般的开发主管宁愿先做 12 个月的计划,然后花 12 个月完成,也不愿做 6 个月的计划,却花了 9 个月。真正困扰人们的并非预先估计的平均开发时间,而是实际消耗时间的标准偏差。大多数人愿意每天花 10 分钟坐车,也不愿 4 天花 1 分钟, 1 天花 26 分钟。尽管就平均时间而言,后者花费更少,只需要 6 分钟。但是由于某次无法预测的长时间等待而将计划打乱,这点好处无法弥补损失。

8、  Fisher 基本定理:一个系统对某个特定环境的适应性越强,它适应新环境的能力也就越弱。为保证程序的效率,就必须考虑要解决问题的特殊条件。过分追求效率,只会降低适应性。但通常我们还是在二者之间做一取舍。至少,具备一种优点,要比哪种都没有强。

9、  衡量程序的真正效率,并不总能用运行时间来衡量。

10、 作为一个好程序,有一些重要的因素:该程序在多大程度上满足功能要求;该程序的开发是否按照计划完成,和计划的偏差幅度有多大;当条件改变时,是否能够修改,修改的成本有多大;程序的效率如何,为了弥补某一方面的低效率,是否牺牲了另一方面的高效率。

11、 主管根据什么来奖励程序员?在你的标准中是否存在相互矛盾的现象 ? 即快又好,还要易与重构,容易修改?

12、 在你的项目中,修改或者重构是否属于一项主要开支?

13、 即使一个计划不可靠,只要它是完成进度的唯一希望(尽管可能根本无法完成),程序员还是会采用它,你知道为什么吗 ?

14、 在进行某个项目的时候,你的脑子是否有一些明确的准则?或者是依照上级主管的看法?在项目的进行过程中,这些准则有无更改,或者你是否有办法让你的准则不被动摇?

15、 在编写程序时,你曾经有多少次想到它可能在未来会被人修改?反过来,在修改别人的程序时,你又曾经咒骂过几次?

16、 你是否因为追求“效率”,而延误了工作进度?反过来,是否因为要“赶时间完成”,而没有做到尽善尽美?

17、 在软件质量管理的过程中,软件性能的偏差使一个极其重要的方面。

18、 许多主管希望得到所有的东西,却不知道更重要的是应该通过明智的权衡,得到自己可能得到的最佳成果。

19、 爱因斯坦的名言:重要的是不要停止怀疑。如果不去进行尝试,我们永远不肯能成功。

20、 霍桑效应:因受到他人关注而带来提高或进步。关注手下工作的领导,将会取得更好的成绩。很多负责软件开发的主管,就是不愿意与属下并肩工作。

21、 最优秀的程序员同时也是那些最善于自省的。如果他们发现做错了什么,他们会对导致这个结果的思维过程(或物理过程)进行检讨;然后,他们会采取一些相应的措施,对这个过程进行调整。这种方法称为“根源分析”。然而更多人仍然喜欢使用“过失追究分析”方法,这种方法恰恰相反,它会诱导人们把引发问题的根源隐藏起来。

posted on 2007-03-18 23:52 三人行,必有我师焉 阅读(1653) 评论(0)  编辑  收藏

只有注册用户登录后才能发表评论。


网站导航:
 
GitHub |  开源中国社区 |  maven仓库 |  文件格式转换