[zz]Your Architecture Sucks and I Don’t Care

duanjigang

作为一篇参考文章，提醒我们在架构设计或者选择时应该注意哪些问题，或者是哪些事情是重要的。
原文:http://friendlydingo.com/blog/20 ... cks-and-i-dont-care

By Ryan, January 3, 2011
Oh, your app’s architecture is perfect?  Well, that’s why you haven’t launched your app and you stay awake at night worrying about separation of responsibilities(instead of worrying about traffic and conversion rates).

Besides, who am I to say your architecture sucks? And why don’t I care?  Because I am your users, and I don’t care what your codebase looks like, I don’t care what it’s called, and I don’t care what language it’s written in.  I care that it solves my problem in the simplest and fastest way possible.


Your users don’t care about architecture, they only care if your app works.

I’ve fallen prey to this before.  In my startup before I began Friendly Dingo, I was obsessed with architecture. I wanted my code to be the cleanest code anyone had ever seen, and I wanted every file, dll, and class to be follow every coding standard you’ve ever heard of.  And it was, it was great.  But my products came out slow, and I spent more time tweaking my code structure(that nobody else ever saw, btw) then I did responding to customer requests for features.  The end result was mediocre product reviews and slow sales.  But man, was my code beautiful.

This time around, I picked an architecture in the first week of development and I’ve stuck with it since then.  As Friendly Dingo’s first product nears an initial release date, I feel confident that even though there are some things I don’t like about my code structure, I know that the features I’ve built are things that my USERS will actually want and care about.  The architecture is sufficient for what it needs to do, and nothing more.

So next time you find yourself refactoring code, stop and ask yourself if it’s something your users will benefit from.  Because in the end, that’s all that really matters.
oschina提供的中文翻译
你的架构很烂，但我并不在意

嗨，你的应用的架构很完美吗？对呀，这就是为什么你还没有发布你的应用的原因，你仍然在彻夜不眠的担忧着各个功能模块之间的责任分离(你没时间去关心应用的流量和访问率)。

可是，除了我之外，谁还会对你说你的架构很烂？为什么我要关心你的架构？因为我只是你的用户，我不关心你的程序长的什么样、如何被调用的、用什么语言写成的。我关心的是它能用最简单的、最迅速的方式解决我的问题。

你的用户并不关心架构的问题，他们只关心你的应用是否好用。

我以前就是一个不理解这个道理的受害者。在 Friendly Dingo 之前的一个公司时，我痴迷于架构。我希望我的代码对于任何人来看都是最简洁的，我希望每个文件、dll、类都满足你们曾经听说过的任何编码标准。而且我做 到了，很完美。但是我的产品却延后了发布，因为我要花更多的时间整理程序架构(顺便提一下，没有人知道我在做这个事情)，然后我才处理客户的增加功能的请 求。这最终的结果是一个中等产品评价和不好的销售情况。但是朋友们，我的程序是完美的。

到如今，在开发的第一周，我先架构选型，然后就搭建这个架构。当产品的首次发布日期快要到时，我已经很有信心，不再关心架构，尽管在某些方面还不尽如人意，因为我知道：程序的功能才是我做的所有工作中用户真正想要和关心的。架构能够满足应用的需要即可。

所以，下次当你发现自己在重构代码时，请停一停，问问自己你的用户是否会因此受益？因为最终，这才是最重要的。

一介村夫

做应用是这样的，但是做产品就不同了。
应用更关注的是客户的需求和最简洁的操作使用。
而对于产品来说，你的架构决定了你的产品能进行什么样的升级与发展。

duanjigang

阿村的应用指的就是一般公司称之为的“项目”吧？
我就是一直做这种项目的。。感觉项目一开始，很少有时间考虑架构，都在急匆匆的开发，除非你有以前积累好的模型，迅速能应用到新的项目中。
或者说项目有后期改进，可以从架构方面就行改进。
没做过产品。。。遗憾

一介村夫

阿村的应用指的就是一般公司称之为的“项目”吧？
我就是一直做这种项目的。。感觉项目一开始，很少 ...
duanjigang 发表于 2011-01-26 21:31

    是的。
一般的项目只要完成客户的需求，尽可能让客户觉得操作使用起来简单方便就行了，除非你的项目具有一定的普适价值。
具有普适价值的项目就要考虑一些架构问题了，因为不同的客户的需求会有差别，如果没有一个好的软件层次架构，就会在客户化实施时增大工作量。
产品的要求就更严格，因为产品面向的是不定客户群，要能适应各种需求，就要有强大的客户化二次开发能力（如MS Office中的VBA），这就对架构的要求更加苛刻。