“防忽悠系列”的终结篇

最近一段时间总是写一些防忽悠系列的文章，比如《读弱智故事，享忽悠人生——如何防忽悠》这一篇，主要是讲如何用专业知识来防忽悠：对于外行人，似是而非的说法非常容易达到迷惑人的效果。

其 实本来开这个BLOG，只是想说说入行十来年的经验，同时写些科普文章，比如《科普一下算法的度量——Big O, Big Omega, Big Theta以及Udi Manber的大OO》和《浅谈OO编程中必不可少的手段：Multimethod》。但可能是我的风格实再不适合老是一本正经地写啊写的，所以最后就搞 成了这个样子。

这一系列的防忽悠文章还有几篇，比如：

《我为什么讨厌某些读后感》：这一篇主要是讲草率结论的问题。一种很容易在“读后感”一类文章中出现的，先有结论而后寻找论据支持，从二手或者三手信息中寻找出来的草率结论。在展示这东西的同时，也简单分析了为什么有时候这东西还会受到追捧。

《我们坐在高高的码堆旁边，听大师讲那成功的经验》：这一篇主要是提醒读者：“大师”们从成功项目总结出的经验并不可靠。有人看了这文章后，和我争论说，从成功项目总结经验绝对是众所周知的靠谱方法，如果禁止人们总结经验的话，就会导致软件行业的混乱，最终会没有项目能够成功交付，软件行业倒退20年……嗯，如果你看了前面这一句话之后在心里也同意的话，请你去面壁吧，或者去google一下什么是“逻辑错误”。我只想强调一下，除了所谓的“软件工程”之外，还有一种很靠谱的叫做“科学”的东西，它有一套相当靠谱的方法学。

《面对众多编程原则，你该如何使用》：这一篇主要是给想要拼命防卫自己的人敲警钟，同时也是一个防止被这种人忽悠的参考资料。同时实践一下某种古怪的书写风格。

为了让我的这个文章不仅仅个总结，特此奉献一篇经典好文作为本文的结尾：


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

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 write source code. You can do it, but you can't devote to it.
你的工作不是做编程示范。你可以做，但是不要全身心投入进去。

Bug 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 meat. (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 addict 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.
让你的设计是自然而舒服的；别跟程序员斗争，也别让他们和你的设计斗争。（参考QT的舒适与灵活，外加良好的命名和强大的功能）

It's too late when you realize to improve performance; design for it;
当你意识到应该提升性能的时候，已经太晚了。为性能而设计。


……嗯……如果你仔细数过了这些原则的数目，会发现其实只有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）

 

最后祝大家动脑快乐！拒绝忽悠！拒绝洗脑！