{分享}{架构}转载：资深设计师的30条忠告
Kenny Yuan
Don't be too sure when it looks like true. Dig into the domain.
当某个东西看起来是真的时候，别那么确定就相信它。使劲去挖掘。
Experience is your treasure. And it is also your burden. (The design should be based on the problem domain, not what you have done in the past.)
你的经验是你的财富，也是负担。（设计是应该按照问题域来进行的，而不是根据你过去做的事情）
It's hard to say "I was wrong", but if you don't say it, you have to pay for it.
说出“我是错的”是很困难的，但是如果你（在该说的时候却）不说，你会为此付出代价。
It's not your job to show how to do coding. You can do it, but you can't devote to it.
你的工作不是做编程示范。你可以做，但是不要全身心投入进去。
Bugs fixing is also your responsibility, don't leave them to maintenance team alone.
处理BUG也是你的责任，别把维护团队扔到一边。
You are not a problem solver. Try to eliminate problems before they surface. (good design can eliminate problems; you're not a firefighter)
你不是一个专门来解决麻烦的。试着在麻烦出现前将它们干掉。（好的设计能消除问题和麻烦；你不是消防队员）
Design is a technical thing, avoid politics in your decision. But if it is stronger than you, negotiate with it to make things still work.
设计是一件技术活。不要让政治参与其中。如果政治力量比你强大，那就妥协以便让事情还能运转。
If your decision is based on some limitations, always remember the 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, or you can use it as a reminder.
如果你能在工作中总结出原则，就写下来。这样以后你就能知道你曾经如此地犯过错；或者你可以用它提醒自己。
If many programmers were waiting for your design, you're definitely dead man. (Human Resource driven is the sin)
如果有太多的程序员在等你的设计（来开工），你就死定了。（人办资源驱动是一种原罪）
Don't use lame metaphors; software is neither art nor brick building.
别用蹩脚的比喻；软件不是艺术，也不是砖墙。
Tell users what you can provide; don't ask them what they really want.
告诉用户你能提供什么；别问他们“你到底要什么”。
Quality is your responsibility, 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 dangerous enemy.
别搞小聪明。当你感觉自己像天才似地做出一个设计的时候，然后把它当成最危险地敌人来攻击。
Reuse is not your purpose, it's neither necessary nor sufficient to success.
“重用”不是你的目的。它不是“成功”的充分条件，也不是必要条件。
A language addicit will always be a slave. Try to become a sensai.
语言上瘾者永远是一个奴隶；尝试变成一个大师吧。
Solutions/Tools with high price guarantee nothing on productivity.
售价很高的解决方案/工具从不保证任何生产力。
Don't use "Microsoft did the same thing" to support yourself. It proves nothing. (Google/Facebook/Twitter/etc.)
别用“微软也这么干过”来技术你自己。它什么也证明不了（google/facebook/twitter也是如此）
Don't try to collect all information/requirements you need and decide later; welcome to the moving planet.
别尝试先收集所有的信息和需求，然后再决定；欢迎来到移动的行星！
There's no universal solution; A language sometimes can be the one; and we need lots of languages, right?
没有万能的解决方案；有时候编程语言是一个（万能解决方案）；我们需要很多种语言，对不？
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 implement. If it's too hard to you, don't count on others.
用你能实现的方式来设计；如果困难到你也写不出来了，那么就别指望其它人
Zenus didn't control everything; neither should you.
宙斯没有控制所有的事物，你也不应该
Inspect your design in each level.
在不同的级别下仔细检视你的设计
Understand the hardware; your system doesn't run in air. (Hardware will never be perfect)
要懂得硬件。你的系统不是在空气中运行的（但是可以Adobe Air）（硬件不是完美的，可能会出错）
Make you design naturally and comfortable. Don't fight with programmers, and don't let them fight with your design.
让你的设计是自然而舒服的；别跟程序员斗争，也别让他们和你的设计斗争。
It's too late when you realize to improve performance; design for it;
当你意识到应该提升性能的时候，已经太晚了。为性能而设计。
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
psychengchao
Bugs fixing is also your responsibility, don't leave them to
maintenance team alone.
处理BUG也是你的责任，别把维护团队扔到一边。
图灵刘江
Shuo Chen
Reuse is not your purpose, it's neither necessary nor sufficient to
success.
"重用"不是你的目的。对"成功"而言，它既不是充分条件，也不是必要条件。
另外，试改这一条：
There's no universal solution; A language sometimes can be the one;
and we
need lots of languages, right?
没有万能的解决方案；有时候编程语言是一个（万能解决方案）；我们需要很多种语言，对不？
没有万能的解决方案；当然，每种编程语言都能解决一些问题；不过我们得用很多种语言才能解决全部问题，不是吗？
On Apr 8, 5:03 pm, Kenny Yuan <yuankain...@gmail.com> wrote:
lbaby
当你意识到应该提升性能的时候，已经太晚了。为性能而设计。
过早的优化是万恶之源
要么翻的有偏差？设计中考虑他们？
James liu
sagasw
Kenny Yuan
不过引文中提到的这一条，并不是“过早优化”，“过早优化”更多地是编程实现中的问题。“为性能而设计”是另外一回事，举例来说吧：比如你要在设计的时候就考虑使用什么算法（Big Theta指标），如何分布运算资源（Client CPU vs Server CPU），是否使用批处理，要考虑是否使用缓存，是否要使用高性能的库和组件，要对接口进行性能规定（比如：number of IOs per second, bytes per seconds）——所有这些，在问题很确定并且许多的条件是已知的时候，不去考虑它就“相当于犯罪”。同时要澄清一下，“为性能而设计”绝不是说在“还不了解情况”的时候，就去防范性地使用以上提到的这些手段。
limodou
> 呵呵，声明一下，我的翻译就是一遍翻过来的，边看原文边打字，然后就直接发了，所以前面才说“要看原文”
>
> 不过引文中提到的这一条，并不是“过早优化”，“过早优化”更多地是编程实现中的问题。“为性能而设计”是另外一回事，举例来说吧：比如你要在设计的时候就考虑使用什么算法（Big
> Theta指标），如何分布运算资源（Client CPU vs Server
> CPU），是否使用批处理，要考虑是否使用缓存，是否要使用高性能的库和组件，要对接口进行性能规定（比如：number of IOs per second,
> bytes per
> seconds）——所有这些，在问题很确定并且许多的条件是已知的时候，不去考虑它就“相当于犯罪”。同时要澄清一下，“为性能而设计”绝不是说在“还不了解情况”的时候，就去防范性地使用以上提到的这些手段。
>
非常认可最后一条。能做在前的，而且又有清晰思路时就尽量去做。
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
UliWeb <<simple web framework>>: http://uliwebproject.appspot.com
My Blog: http://hi.baidu.com/limodou
居振梁
语言上瘾者永远是一个奴隶；尝试变成一个大师吧。
--
自学走了不少弯路，更浪费了太多的时间，寻找良师益友。
追求黑客精神和清心寡欲的心态。
中文博客：http://wargrey.yo2.cn
英文博客：http://wargrey.blogspot.com
研究方向：基础[Unix/GNU Linux]、主观[人工智能]、可选[虚拟化]
其他兴趣：数学、物理、心理学、武术、自然语言
Leon
图灵刘江
Kenny Yuan
ysq
want.
告诉用户你能提供什么；别问他们“你到底要什么”。
这句我觉得值得商榷,一般来说需要搞明白客户的需求到底是什么,用技术来配合服务.
只在某些特定的场合才能don't ask them what they really want.
wing fire
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
焚符破玺，而民朴鄙；掊斗折衡，而民不争；
殚残天下之圣法，而民始可与论议。
It's too late when you realize to improve performance; design for it;-- 这一条怕是不能同意，是应该注意性能，但不应该为性能而设计
当你意识到应该提升性能的时候，已经太晚了。为性能而设计。
过早的优化是万恶之源
要么翻的有偏差？设计中考虑他们？
tommy xiao
我理解这句话的意思应该是客户永远不会知道自己缺什么，你做出来给他们就知道他们要不要了。
例如：iPod的模式，场景是已经有mp3了，apple还推出新的mp3 player，为什么，因为它的容量非常大。
--
tommy xiao
QQ: 2667799
MSN Messenger: xds2000ATmsn.com
E-mail: xiaodsATgmail.com
Jeffrey Zhao
wing
就如不要过度设计，与充分考虑扩展性一样，二者看似对立，也并无矛盾，只是一个颗粒度和抽象度的问题，至于到什么样的维度是好的，高了也许就抽象过度，毫无价值，低了就掺杂太多的细节，陷入过度设计或过早优化，二者没有绝对的界限，这里看的就是架构设计者的经验和功力了。
--
wing
wing9...@gmail.com
Hope is a good thing, maybe the best of things.
Shuo Chen
On Apr 12, 12:14 pm, wing <wing922w...@gmail.com> wrote:
> 从架构的角度，对性能问题必须始终考虑，这和实现上，过早优化是万恶之源是没有矛盾的，架构考虑的无非就是性能、扩展、健壮、安全这些东西，如果不考虑性能，后期发现无法通过优化实现来满足需求，就只能推倒重做，这在实践中不是没遇到过。
> 就如不要过度设计，与充分考虑扩展性一样，二者看似对立，也并无矛盾，只是一个颗粒度和抽象度的问题，至于到什么样的维度是好的，高了也许就抽象过度，毫无价值，低了就掺杂太多的细节，陷入过度设计或过早优化，二者没有绝对的界限，这里看的就是架构设计者的经验和功力了。
>
> --
> wing
Aladdina
图灵刘江
如果它是某个同学愚人节弄出来的东西，半真半假呢？
这里面的英语就有一些语病，感觉不是英语母语的同学写的。当然，中文翻译问题
就更多。
On 4月10日, 上午8时49分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 很重要否？
>
> 2009/4/10 图灵刘江 <liuj.tur...@gmail.com>
>
> > 原文链接？
edwin
sagasw
Jeffrey Zhao
Kenny Yuan
rockeet
want.
比较赞这句话
On 4月13日, 上午9时59分, Kenny Yuan <yuankain...@gmail.com> wrote:
> Bingoooooooooo...
>
> 2009/4/13 sagasw <sag...@gmail.com>
>
>
>
> > 感觉和一些所谓的畅销励志书一样，说的都是有些哲理但是又不着边际的话。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
徐建忠
want.
图灵刘江
也不能做，我找你干嘛？
Kenny Yuan
再次重申，我严重鼓励怀疑精神（胡搅蛮缠的不算！）
P.S. 原文那一条的意思是说，在某种情况下，当用户说不出他想要的东西的时候，他会想像和描述某种东西，但是这种东西其实并不是用户想要的。在这种时候，作为设计师，你要敏锐地查觉到这种情况，并且替用户想出来解决问题的方法，然后拿给用户去看。这时候用户才会明白，其实他要的就是你展示的那种东西。在这种情况下，如果还去不停地追问用户“你到底想要什么”，则是低效、无果，甚至会产生负面影响的。这方面的例子我就不举了，常和用户打交道的人应该都能说出一大堆来……（欢迎反例）
pf_miles
On 4月8日, 下午5时03分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 阅读提示：中文是我翻译的，最好看原文，最能表达原意
>
> It's too late when you realize to improve performance; design for it;
> 当你意识到应该提升性能的时候，已经太晚了。为性能而设计。
我以为，设计一定是为了可维护性第一，可扩展性第二来的；性能是什么时候考虑的东西？当你真正需要抠性能的时候。
其实设计的过程当中，如果没有犯低级的、原则性错误，性能一般是没有什么问题的，所以设计的过程中“性能”的考虑应该让位给维护性。
而真正做到了“可维护性”和“可扩展性”的设计，当后来发现需要抠某一部分的性能的时候，也是很容易做的，起码能把变更控制在一个可接受的范围内。
Jeffrey Zhao
一定范围外的性能需求，不行。
例如，一个分布式的系统中，Scale-out-bility一定是要提前设计的。
Jeffrey Zhao
Blog: http://jeffreyzhao.cnblogs.com
Twitter: http://twitter.com/jeffz_cn
--------------------------------------------------
From: "pf_miles" <Miles...@gmail.com>
Sent: Tuesday, April 14, 2009 6:39 PM
To: "TopLanguage" <pon...@googlegroups.com>
Subject: [TL] Re: {分享}{架构}转载：资深设计师的30条忠告
>
>
Fox Wu
非常赞同“当用户说不出他想要的东西的时候，他会想像和描述某种东西，
但是这种东西其实并不是用户想要的”。
--
爱生活，爱FOX
Sent from Beijing, China
LnXer
如果你设计一个web server，你会不会到真正需要抠性能的时候才考虑性能？在我看来，没有one fits all的设计规则，所有的设计都需
要针对特定的问题域进行仔细的考虑/权衡,其中要用到不仅仅是和你的业务能力，还需要用到你对于特性平台(Win, Linux, J2EE,
etc)的熟悉程度。就非功能性设计这块来说，对于服务器的设计而言，如果你在设计过程中不好好考虑/权衡非功能性需求(performance,
scalability, supportability, etc)，那么到了产品开发后期或者发布之后，你会发现你为了提升产品性能所花费的成本是
相当的高。
qiaojie
为性能而设计不等同于优化，性能问题在设计的初期就要考虑的，比方设计一个搜索引擎就要根据性能来考量选用什么算法和架构，如果
这些没事先考虑过的话，等到你把搜索引擎都做完才发现性能远达不到要求，那只有推倒再重来了。而优化则是在已有的设计上做些调整
使得性能更好，如果设计错了，再怎么优化都是没有用的。
图灵刘江
我单看那句话，得出了那个结论。没有上下文，曲解是很容易的。所以我问你
出处嘛。
On 4月14日, 下午3时47分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 合理怀疑是一回事（我挺鼓励怀疑精神的），但是用错误的逻辑来反驳可就是另一回事了，引文中的那个说法（“*我想要的东西，你这也不能做，那也不能做*