Yuan Yijun (bbbush) wrote,
Yuan Yijun
bbbush

Easy reading "Code Simplicity" from O'Reilly

http://www.codesimplicity.com/
http://shop.oreilly.com/product/0636920022251.do
By 

做程序员的一定要时不时地读一些 easy reading,尤其是不需要做算法、操作系统那些高深东西的,多出来的脑细胞应该想办法用掉。而且 easy reading 可以让工作更顺利些。

这本书对我的胃口,因为很薄,一两天就翻阅完了。而且文字简单,可以想象编辑同志花了多少工夫去改一个 code monkey (哪怕是 chief architecture) 的文字。。 里面讲到的很多 law 和 rule,我猜测作者是想用 Assert(!fail) 来着,如果这本书的厚度翻一倍,就会让人厌烦了(像 unit test 一样!),现在这样刚好。

书里讲到的一些观点很有用。摘录如下:

Chapter 1
"All of us have been taught that software is “a series of instructions given to the computer,” and this is true. However, there is no field in which a set of instructions and the result of those instructions are so closely linked as they are in the field of software development. In other fields, people write instructions and then hand them off to others, often waiting a long time to see them carried out. But when we write code, there is nobody between us and the computer. The result is exactly what the instructions said to do, without question. The quality of the end result is dependent entirely upon the quality of the machine, the quality of our ideas, and the quality of our code. "


之前也很困惑为什么做软件不能像传说中的 engineer 那样,搭座桥建座楼,一百年不倒。 Chicago 的房子都是百年以来修修补补的。不过按书里的说法,这个反馈太暴力了,出一点儿错都不行。

“Everybody who writes software is a designer.

However, this does not mean that design is a democracy. You must not design by committee. The result will be an actively bad design—one which makes things more complex instead of simpler. Instead, all developers should have the authority to make good design decisions in their own areas. If they make poor or mediocre decisions, these should be overridden by a senior developer or the lead programmer, who should have veto power over the designers below them...

A designer should always be willing to listen to suggestions and feedback, because programmers are usually smart people who have good ideas. But after considering all the data, any given decision must be made by an individual, not by a group of people.”


这个听着也很给力。

Chapter 2

"The purpose of software is to help people"


(从 stakeholder 角度看这句话,那这句话算是公理了。)

Chapter 3

不考虑合适的收益率,是这一章最大的问题。书里的算法,完全不考虑折现率,来计算成本和收益,只适合于 Open Source。如果一个产品不能有足够的回报,做它干什么?像 bugzilla 等等基础软件,如果不做,结果就是亏损,所以不得不尽力减少亏损。

这也是为什么开源软件需要爱好、慈善、狂热分子一起来做。为了其他产品的商业成功,投资于开源软件,算是极有效的资源分配方式。而不考虑这种模式,那就不是调动资源,而是与其他事物共享资源。通常也能有效地避免资源浪费,只是不会发展得那么快。

一个软件长期维护的成本高,所以要想办法缩短软件生命周期,像手机厂商、芯片厂商、大小软件厂商,都得及时让旧的产品 EOL,让用户转移到新的产品上。这样是不是对资源的有效分配?一方面这样的厂商在市场上成功了,另一方面这种成功可能来自于垄断优势,所以究竟是否有效还难说。对于 bugzilla 这样的基础软件,不用考虑生命周期的问题,这是不是对资源的有效分配?

“The most common and disastrous error that programmers make is predicting something about the future when in fact they cannot know.

...there is a difference between designing in a way that allows for future change and attempting to predict the future”


我最喜欢这一段,因为自己经常犯这样的错误,眼高手低。另外这一段还可以为 code refactor 辩护。既然 code change 可能带来 side impact,为什么要做?因为 bad smell 就在那里。长久以来的经验告诉我,感觉会出问题的地方,那就一定会出问题。因为这种代码都是没有考虑周到。结合这一段,感觉没有考虑周到的时候,实际上是在验证当前的需求,并不是尝试预测将来。

Chapter 4

这一章开始用几个文件的变更记录,来说明软件生命周期的特点 “时间越久,改动越多”。

我也对变更记录很感兴趣,但是 so what?必须有足够长的历史数据,才可以证明代码的质量是上升了还是下降了。然而数据的统计又很容易有出入;代码质量用其他方式更容易测量(目前用的是issue per feature)。这一章说“there is a lot more interesting analysis”,让人很 upset 因为自己完全想不到其他 make sense 的分析。

“Don’t write code until you actually need it, and remove any code that isn’t being used.

That is, you should also get rid of any code that is no longer needed

Code should be designed based on what you know now, not on what you think will happen in the future.

Here’s how we would use it to develop a calculator program that needs to add, subtract, multiply, and divide:
1. Plan a system that does only addition and nothing else.
2. Implement that system.
3. Fix up the now-existing system’s design so that it is easy to add a subtractionfeature.
4. Implement the subtraction feature in the system
...
In general, you should pick whatever is simplest to work on at each step, when you get there.”


这个与前一段一脉相承,不要预测将来。想得越多,浪费得越多。——然而不浪费几次,就不会有足够的经验和直觉,一上来就找到正确的方向。

幸好自己处在一个互联网的时代,做的产品也有很久的历史、比较大的团队,极多的代码可以借用,不用自己去碰头。然而如第一章所说,design 是个人负责任的事情。

Chapter 5

Do not repeat yourself


Chapter 6

"The ease of maintenance of any piece of software is proportional to the simplicity of its individual pieces."


所以要把部件做得更小、接口更明确、容易更换。这是接下来要努力的事情。

“if people are new to something, they probably don’t know anything about it.

(Emacs vs. Vi) ... the perceived simplicity of a tool has to do with familiarity—anybody who has used a particular tool for a long time has likely become very familiar with it, which makes it much simpler than any other tool, from that person’s viewpoint. In order for a new tool to seem equally simple, that tool would have to be extremely simple, and programmers’ text editors rarely are.
Non-programmers would likely consider both text editors to be complex beyond reason, which is another example of how simplicity is relative.

Many programmers are particularly bad about this with their code. They assume that other programmers will be willing spend a lot of time learning all about their code, because after all, it took a lot of time to write it! The code is important to them, so won’t it be important to everybody?

Now, programmers are generally an intelligent bunch. But it’s still a mistake to think, “Oh, other programmers will understand everything I’ve done here without any simplification or explanation of my code.” It’s not a matter of intelligence—it’s a matter of knowledge. Programmers who are new to your code don’t know anything about it; they have to learn. The easier you make it for them to learn, the faster they are going to figure it out, and the easier it will be for them to use it.

... None of us like being talked down to or treated like we’re idiots. And sometimes that leads us to create things that are a little complicated, so that we feel like we aren’t talking down to the user or to other programmers. We throw in some big words, make it a
little less than simple, and people respect our intelligence but feel kind of stupid because they don’t get it. They might think we’re way smarter than they could ever be, and that is kind of flattering. But really, is that helping them?”


我极其喜欢这一段。知道对方不理解,是因为 knowledge 不够,因而需要理解对方的困难,这样就不会苛求别人。反过来自己也可以不用怀疑需要继续补脑。

最近经常遇到 perception 这个词,因为比起谈人生、理想、情感,这个词听起来比较科学。一个人总会有自己的 frame,不乐意做什么、做不了什么,是有解释的。只要能解释就好。

Chapter 7

谈到关于 vendor lock-in,这个也是选择 Open Source 的理由。因为不会 worse off,所以大家都会选同样的软件,所以最终大家都不会被 vendor lock-in,反而可以共同达到 better off

“Never stop maintaining a system that is currently in use so that the programmers can rewrite it. Systems must always be maintained
if they are in use”


谈到 long term development。这个呼应第 2 章,因为软件是给人用的。对 Open Source 的要求可以低一些吧。。毕竟资源实在太有限了,所以 LTS 很难搞下去,不管是 Fedora 还是 GNOME,甚至 Android,都是最新版的才有最多 support,旧版直接放弃的。

Chapter 8

关于测试,也是公理。
Tags: fedora, reading, 广告
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 0 comments