读《卓有成效的程序员》-----我的一些题内和题外的感想

原创于 2009-04-15 13:35:00 发布 · 1.3k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#文档 #工作 #thoughtworks #powershell #subversion #selenium

读《卓有成效的程序员》-----我的一些题内和题外的感想

本文出自：http://hi.baidu.com/xiaonan33309/blog/item/c708c901a50d940b728da555.html

写在前面：

我不想单纯从程序员的角度来解读这本书，因为我读它的初衷并不是为了更好写程序，而是希望从中能获得一些有益的提示。当然其中一些解决问题的方法和应用软件是我们可以去“偷”用的，它确实很好，并且可以达到某种有益的效果。

1：关注本质，而非形式。

当我看见这个标题的时候，我的第一反应就是我们项目里实施的各种统计文档，那些传说会占用PL 70% 时间的东西。我不知道那些编造出来的BUG统计可以对我们后续的项目有什么有益的帮助。我一直都是致力于简化一些东西，让重点更加突出，就像杰克韦尔奇书里说的“通用公司要简化掉那些繁冗复杂的文档报告流程，让流程更清晰，更便捷，更实用”（大意）。我想至少我们可以做一套简单明了的文档，或者让这些工作分散到各个组员身上，从而减轻PL的压力，当然我希望这些文档不只是一些统计的数据，而是可以为后续项目提供帮助的有利参照。

2：一个应用程序列表的有用程度和它的长度成反比。

或许程序列表并不能引起你的共鸣，但是如果换成桌面快捷方式，我想你就会很有感触。当你在满桌面的快捷方式中寻找你要的程序启动图标时，一定会懊恼当初如此设置的愚蠢，那简直是一场噩梦。因为我们过度地使用了“快捷”，这是我的理解。

书里提供了两种我认为比较好的建议，一种是加载器（Launvher），“它是一类应用程序，允许你输入应用程序（或者文档）名称的第一部分来加载（启动运行）它。”。它还提供了两个开源的程序，我下载了其中一种，效果还好，准确的讲它需要一些适应的时间。

第二种是利用现有的环境构筑一个方便的菜单----简单地说就是“手动整理”，听上去这个方式很笨拙，但是不可否认它最容易实现，效果也很好。我们建立起文件夹，把快捷方式放进去，然后按照使用频率来分级存放。定期一周或者一段时间整理一次。我们把这文件夹放在右下角类似于下图。

因为第二种我很早以前就已经那样使用了，所以我在努力地尝试第一种方式，希望在实践中得到一些更新的东西。这里只是提出一个问题，给出两个解决的方法样例。不要问我什么方法最好！用什么方式去解决这样的问题，怎么样解决最好，多数取决于个人的习惯，请注意我说的是“多数”。

3：忘记历史就意味着你要再输入一遍。

或许这就是CMD里F7的妙用所在。这句话大家自己揣摩吧。

4：当你第二次输入一个复杂结构时，把它做成模板。

这个句话我把它放在8里面一起讨论。

5：项目规定“安静时间”。

“ 开发人员渴望一种流畅的工作状态”。当没有任何打扰的时候会进入一种忘我的状态，那时的工作效率之高是无法用言语形容的。一旦受到打扰，就好象一辆全速的汽车停下，又启动的过程一样。在项目里设置“安静时间”是一个很新奇很好的方法。除非紧急问题，否则在“安静时间”内项目组内部是免打扰的。书上提供了两种方式来“自制”“安静时间”，一种是“你可以戴上耳机（即使并不是在听音乐），当别人看见你戴耳机的时候，他就不太可能打扰你。”另一种“是或者如果办公室不允许用耳机，考虑贴一张‘请勿打扰‘的标签在你的工位间隔的入口处，这样应该能让其他人在打扰你之前三思。”。

说一些题外的话，在我们公司很多PL工作没有逻辑性，他们甚至可能按照自己的意愿每5分钟呼唤你一次去解决一个他想要解决的问题。原因是他们认为这个团队是他的。但是兄弟！你忽略了一个问题，你也是团队中的一员！在你的项目实施一下“安静时间”，我想很多人会爱上它。

6：根视图例子：cmd：“explorer /e, /root, E:/名称変更対応_納品”

看见这句话的时候，我简直像找到了宝贝，或许你早就知道，但我承认我见识了一个我一直要找的东西。我见识过保守项目里那复杂的树形目录，如果你想不出错误地上下拉动它们，你需要精准的手法。恩，它很好用，至少对我来说，所以我推荐给大家。它符合我的工作逻辑“把复杂的问题简单化！”

7：以创造性的方式来解决问题，有助于在将来解决类似的问题。

总有一些操作和行动是重复的，总有一些工作是需要大量的精力，比如EXCEL的数据对比。这时候我们就在想应该找一些方法，或者做些Tools出来简化我们的工作。从刚进公司的“PLSQL纳品格式工具”到最近的“EXCEL对比工具”，都起到了很好的效果，至少对我和我身边的同时而言。我们可能在这个项目上花费了一些精力和时间，但是这些都会在后续的项目中得到“弥补”和“奖励”。

8：是否应该自动化的关键在于投资回报率和缓解风险。

1）长期看来，将其自动化能节省时间吗？

2）这件任务是否很容易出现错误（复杂的步骤）？一旦出现错误是否会浪费大量时间？

3）执行这样的任务是否在浪费注意力？

4）如果手工操作会造成什么危害？

回答了这4个问题，我想你应该知道自己该怎么做了。

9：研究性的工作应该放在时间盒子里做。

我们总是用项目时间紧张来给自己丑陋的代码开脱，很多问题因为这个冠冕堂皇的理由一直放在那里，直到失去客户的信任。

当然“项目经理一定会担心你的工作失控”，“原本以为2个小时能搞定的事情，最终用了4天才完成。”要控制这种风险，书上给出了以个名词“时间盒”（timebox）。给自己设置一个“时间盒子”，在盒子的规范内进行，一旦超出盒子范围就要重新考虑其可行性。

我的想法是，尽量去尝试，所有努力都是有回报的，只是这种回报可能会是以各种不同的方式体现而已。

10：利用虚拟平台使项目依赖标准化，并使这种环境可以存放N年。

这应该是活用虚拟系统（VMWARE）的一种方式。

建立一个标准的工作环境，制作成一个标准的WINDOWS GHOST镜像。然后分发给所有成员，成员用虚拟系统安装并开发，这样可以保证所有环境的一致性。并且此环境可以存放N年。当那一阶段项目结束时，我们把VMWARE的镜像文件保存在服务器上。N年后当这个客户回头再找我们增强功能的时候，我们只要启动虚拟机，一切环境会犹如当年再现一样。这样可以节省好多天的环境构筑。

我们公司现在的情况是，如果想保留环境就要保留一个实体的机器来存放环境，这样太浪费了，不妨尝试一下这种方法。

11：过时的文档比没有文档更糟糕，因为它会误导你。

这个太重要，我们都曾深受其害，过期的，过期的可能意味着你正在走向一个错误的方向。每个项目的文档整理都是由PL管理的，当然如果项目够大，指定人员管理是必要的。我还是倾向于把管理文档定期执行，定期整理一次不管是否有更新，即使没有更新也可以验证一下寄存文档的正确性。不要抱怨，我们的工作难度复杂度就应该是至上而下的，因为我们拿着比他们高的工资，所以我们要对手下的兄弟们负责。

12：想知道进度，给你推荐一个套装（SUBVERSION , SVN2WIKI）wiki支持RSS

这个完全可以参考进我们的SERP工时系统。很好的东西，不过需要时间去实践。

13：软件开发是一场沟通的博弈。

这个我打算单独开一个日志来发，结合“组织行为学”谈谈这个问题。

卓有成效的程序员 (CHINA-PUB 3.20日全国独家首发) THE PRODUCTIVE PROGRAMMER
评　　价：		购买团购收藏
作　　者：(美)NEAL FORD
译　　者：THOUGHTWORKS中国公司
出版日期：2009-3-1	上架时间：2009-3-20
出版社：机械工业出版社	ISBN：9787111264064
市场价：￥45	4-5星会员：￥33.75