CS巴别塔(1)

资深架构设计师的30条忠告

Posted in Uncategorized by Kenny Yuan on 2010/10/18

UI really matters!
界面真TMD不能忽视!

The design should base on the problem domain, not on what you have done before.
设计是应该按照问题域来进行的,而不该根据你过去做的事情为蓝本。

It’s hard to say “I was wrong”, but if you don’t say it, you’ll have to pay for it.
说出“我是错的”是很困难的,但是如果你(在该说的时候却)不说,你会为此付出代价。

It’s not your full time job demonstrating how to write code. You can do it, but not all the time.
你的工作不是做编程示范。你可以做,但是不要全身心投入进去。

Bug fixing is also your responsibility, don’t leave it to the maintenance team.
处理BUG也是你的责任,别把它扔给维护团队就不管了,要不然你的设计会被维护团队搞得面目全非的。如果写烂代码更方便的话,维护团队一定会写出大堆的烂代码的。作为架构师,你要去控制修改代码的成本,让成本最低的那一个成为你所期望的那一个(借鉴一下经济学)。

You are not Winston Wolf. Try to eliminate problems before they surface. (good design has less problems; you’re not a firefighter)
你不是一个专门来解决麻烦的(见《低俗小说》)。试着在麻烦出现前将它们干掉。(好的设计能消除问题和麻烦;你不是消防队员)

Design is technical, try to avoid politics. Or negotiate with politics to make things still work.
设计是技术问题。不要让政治参与其中。或者适当妥协以便让事情还能运转。

If your decision is based on some limitations, always remember those limitations along with your decision.
如果你的决策是基于某些限制的,那么在记住你的决策的同时,要记住这些限制(不要直接记住结论)

If you can summarize principles from your work, write it down. Then sometimes you’re able to know you were wrong.
如果你能在工作中总结出原则,就写下来。这样以后你就能知道你曾经如此这般地犯过错(我打赌你写过的多数都是错的,除了OCP,但那不是你发明的,嘿嘿)

If there are many programmers awaiting for your design, you’re definitely dead meat. (Human Resource driven is the sin)
如果有太多的程序员在等你的设计(来开工),你就死定了。(人力资源驱动是一种原罪)

Prevent lame metaphors; software is neither art nor brick building.
别用蹩脚的比喻;软件不是艺术,也不是砖墙。

Tell the user what you can provide; don’t ask them what they REALLY WANT.
告诉用户你能提供什么;别问他们“你到底要什么”。

Quality is your responsibility too, don’t hand it over to QA. (Design in the robust way)
质量也是你的责任;别把它们交给QA。

Don’t get smart. Write it down when you feel like a genius, and attack your idea as the most dangerous enemy.
别耍小聪明。当你感觉自己像天才似地做出一个设计的时候,要把它当成最危险的敌人来对待。

Reuse is not your purpose, it’s neither necessary nor sufficient to success.
“重用”不是你的目的。它不是“成功”的充分条件,也不是必要条件。别单纯为了重用去设计,别忘了重用是为了达到什么样的目的。

A language addict will always be a slave. Try to become a sensai.
语言上瘾者永远是一个奴隶;尝试变成斯普林特老师吧!

Solutions/Tools with high price guarantee nothing on productivity.
售价很高的解决方案/工具从不保证任何生产力。

Don’t say “Microsoft did the same thing”. It proves nothing. (Google/Facebook/Twitter/etc.)
别用“微软也这么干过”来支持你自己。它什么也证明不了(google/facebook/twitter同理)

Don’t try to collect information/requirements first and decide later; welcome to the moving planet.
别尝试先收集所有的信息和需求,然后再决定;欢迎来到地球——这颗移动的行星!

There’s no universal solution; The programming language sometimes can be the one, unfortunately we have lots of languages.
没有万能的解决方案;有时候编程语言可以是一个(万能解决方案),不幸的是我们有很多种语言

Age and experience are not the right way to defend yourself in an argument.
在争论中,年龄和经历不是你证明自己的正确方式(以德服人,以理服人)

Yesterday’s workaround is tomorrow’s limitation.
昨天的Workaround就是明天的限制

Good design evolves; bad design patches.
好的设计在进化,坏的设计不停地打补丁

Design what you’re able to write code for it. If it’s too hard to you, don’t count on the others.
用你能实现的方式来设计;如果困难到你也写不出来了,那么就别指望其它人

Don’t be the captain in the engine room.
不要成为引擎室里的船长(把船开好是你的职责,而添煤则不是)。

Inspect your design in each level.
在不同的级别下仔细检视你的设计。

Understand the hardware; your system doesn’t run in air. (Hardware goes wrong too)
要懂得硬件。你的系统不是在空气中运行的(但是可以Adobe Air)(硬件不是完美的,可能会出各种错误;)

Make your design natural and comfortable. Don’t fight against programmers, and don’t let them fight against your design.
让你的设计是自然而舒服的;别跟程序员斗争,也别让他们和你的设计斗争。(参考QT的舒适与灵活,外加良好的命名和强大的功能;另参见最小惊奇原则)

It’s too late when you realize it’s slow; design for performance;
当你意识到速率太慢的时候,已经太晚了。为性能而设计。

……嗯……如果你仔细数过了这些原则的数目,会发现其实只有29条。第30条我没有写,其实原打算是这样的:

(30)这篇文章是由Kenny Yuan在1.5小时内直接敲出来的,其中英文敲了一小时左右,中文翻译了半小时左右;他写这篇文章是为了说明:滔滔不绝地谈论具有迷惑性的原则是多么的容易!而且居然还能骗到一部分人哩……

(P.S. 之所以选择从“架构”这个角度来忽悠,是受到以下这个的启发:http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book)

最后祝大家动脑快乐!

(P.P.S. 此为旧文,一直在草稿里忘了发。现在编辑一下发出来,其目的,当然是想要给大家的Google Reader再添一个未读数,嘻嘻——嗯,要keep it on the down low…)

Advertisements

SEMAT – 软件工程方法和理论

Posted in Uncategorized by Kenny Yuan on 2010/04/07

无责翻译:SEMAT – 软件工程方法和理论(终于醒悟了?想起来理论的缺失了?)


在当今这个摩登时代,非常幼齿的实践方法几乎埋葬了“软件工程”,特别突出地,有下列问题:
* 本来应该是德国式的严谨工程纪律,结果搞成了法国式的时尚随意流行
* 没有坚实的、被最广大人民群众接受的理论基础(就是说现在还是不明真相?)
* 实践方法千万种,其实没有多少能让人搞明白的差别,但却被人搞得和iPad一样大(蘑菇处处有啊——每个人的心中都有一颗大蘑菇)
* 没有可信的实验进行评估和验证(证伪原则!召唤软件工程行业的波普尔)
* 学院派搞理论的玩儿一套,工业界搞实践的玩儿另外一套,完全割裂开来了。(本来理论界应该是工业界的“大后方”才对)

我们吐血推荐去建立这样的“软件工程”:建立在坚实的理论基础之上的,有真正管用的原则的,有最好实践的:
* 由人人承认的要素构成它的核心,对特殊用途也可以扩展(一个中心,一个基本点)
* 应对处理两种问题:技术和人员(其实领导搞破坏比小兵要厉害多了,应该写上这一条)
* 工业界,学术界,研究者,用户都支持(千秋万代,一统江湖)
* 需求和技术变换不影响它的本质层面,只需要改动一下外表,不伤筋动骨(九头鸟,百足虫)

P.S. 圆扩号中的是我写的评论,原文请见(http://www.semat.org/bin/view)。在这里多说一句:其实,只要脑子不笨的人,都能明白这里面的道道儿;但是换了一批“大师”来搞这个东西,估计效果会不一样吧? 当然,我过去碰到的那种不敢大声说“影帝是裸体的”人也不少,不过这种人还是容易被“大师”忽悠的,嘿嘿……

P.P.S. 这个东西从图老师的TWITTER看到的——感谢国家!