作者 陈怀临 | 2012-04-23 07:41 | 类型 专题分析, 弯曲推荐 | 39条用户评论 »
工具箱 本文链接 | | 打印此页 | 39条用户评论 »
“《系统设计黄金法则 : 简单之美》”有39个回复
好文!!!
在弯曲这么多文章中,这篇文章觉得最优价值!
“它很老,但很可靠”
这篇文章忽略了先简单->复杂->才能简单这么一个前提,如果一味的求简单和权衡,对很多资历不深的人来说是一种误导。
如果不加这个前提的情况下,我更倾向于这是一种综合工程的说法,或者说是经理/架构师们在商业/局面控制等外界因素压力下的一种追求快速和稳定之间适度权衡的一种以满足商业需求和后续维护的开发方法,但仅此而已,尤其是当前互联网科技发展如雨后春笋的情况下,更容易产生这种浮躁。我觉得这种思维下产生的东西会很快被淹没在人类发展的潮流中,相反哪些以追求卓越设计思想下的产物更容易促进人类思维发展和社会进步并永久长存,这样的例子数不胜数,大家最熟悉的就是jobs的系列产品设计。卓越是优秀中的最优。在追求卓越的思维方式下是更能将人这种动物潜在能力发挥到极致的一种状态。
不能光简单,同时也要巧妙
说白了就是close form 的另一种表达
真正掌握了“道”的人,简单复杂存乎一心。调试一下复杂系统的时候,有些轻微的错误你可以略过去,看主要的问题,但是有时候真正的关键问题就在某个细小的问题上。懂的人自然知道哪里简单,哪里该省略。不懂的人看了这篇文章之后,只了解了简单的原则,应该也不知道哪里或者什么时候用这个法则。
人类渴望的终极目标,即“知道该怎么样,知道不该怎么样”,也就是事物的本质,人类和自然界都在一直没有停止过在各领域对这个问题探索,楼上提到的“知道哪里简单,哪里该省略”的境界,是需要对一个领域经过深入的研究理解、数次探索上的锤炼和醒悟、谦逊和敬畏的态度才能换取来的。
真正简单的系统是经过从千丝万缕的头绪中找出了那几根最重要的。但简单只是“果”,“因”在于你对自己高标准高要求的复杂艰辛的探索和努力,相对于果,因更加不可忽略。
本来一件很简单的事情,经过你们上面一解释,又复杂了
我一直想将做的事情简单化,这篇文章对我有很大的指导意义! 赞一个!
末学才疏学浅,Panabit见笑了。知道弯曲有不少年轻的读者,很多刚毕业的,我想以自己的经历能够给他们提供另一个看问题的着眼点,仅此而已。
这个必须得顶一下!犯过几次类似错误,最后自己也把这个道理悟出来了.
其实就是Yale Patt经常提到的Speed Demons和Brainicas的区别。最简单的例子就是James Smith的Trace Cache和Sanjay Patel的Trace Cache。
回10楼:小joke而已,不当之处,见谅!:)
抓主要矛盾,快速实现,逐步演化,KISS是我做系统设计时首要的信条。 对于本质的认识需要很多的时间和精力,要认识到认识的过程是漫长的,所以不能等认识到本质才开始做东西,只能就目前理解的程度把东西弄出来,这才是商业系统的一般做法。 C++语言在速成生成力这方面就远远比不过C语言,这个也是他被我抛弃的原因。
有一句不错的广告词叫简约而不简单,原来吴海军的数学之美里也有关于简单设计很好的描述,但确实,都希望能学到举重若轻或者举轻若重的葵花宝典,说出来并不神秘,但真正演练起来,并不是那么容易,还是要付出很多,并且还不能保证成功:)
说起来容易做起来难,最经典的例子:麦克斯韦的叉叉
抓不住核心矛盾的喜欢找各种借口。市场,时间……殊不知很多关键的工具在手,核心就在手。
竞争就是看谁能在最短时间找最核心的部分。
额。。俺发言跑题了。请无视。
赞成理客的说法,葵花宝典非一日之功,速成论可怕。
参考阅读: “LISP: Good news, bad news, how to win big”.
unix/c的方法更成功,更容易成功,更快能见到效果,也更容易做到(实现)。
设计中应该解决主要问题,使用最简单的方法达到目标。细枝末节可以先不考虑,后续单独解决(先实现功能,可靠性、成本、安全性、美观、维护等可以先不考虑)。
这是弯曲评论上最有意义的一篇文章了,真的称得上是黄金法则,没有丰富实战经验的人是理解不了的,而且也无法把握好这个度。
学术讨论还是拿点真材实料出来,请求楼上结合自己的经历给”你指的这些没有丰富经验的人”授道授道。
好文!
能做到简单的实现当然好,但实际上,要做到真正的简洁是非常难的。
同意aaa的说法,有些解决方法看起开很简单,但实际上背后是经过了无数次复杂的尝试。想要简单,先要复杂,我认为这个过程必不可少。
现实就是很多对矛盾的组合:安全、麻烦;功能强大、操作简便。。。。。。 只讲一面,是书生意气,会误导新人
做学术的可以严谨与简单并存,搞互联网的以简单快速来抢占市场份额,可是一旦涉及安全的问题,简单是系统设计最后才想去考虑的元素。这几天才看了一则新闻,凯迪拉克已经开始对旗下全新的 Super Cruise 半自动驾驶技术进行上路测试。
方滨兴一定是这种理论的支持者,胡萝卜都被墙。
楼上这么说,真是侮辱了这篇文章!
个人拙见,正确性》完整性》简单性》一致性, 简单不是最重要的,方滨兴搞不定正确性,所以用简单来代替了。
好文,顶一下,露个脸
真正的好文,这里的简单性不能理解为一个通用的功能,有人用1000行代码实现,而另外一个人则用100行就实现了。这种简单性就像前面有人说的,那是需要功力的,一定要经历过复杂之后,最后才能做到简单。 这里说的简单性,就是指如果我要把某个功能的正确性,一致性,完整性都保证了,可能需要1000行代码(即使对于牛人),而如果我适当放弃这些(假设影响不是那么大),那我就放弃他们,保证简单性,因为简单性就意味着系统稳定性,可读性,可维护性
跟Eric Raymond的The Art of UNIX Programming一个意思,aaa你觉得本文作者和译者会没有想过你说的那些问题?
楼上的二子,我就先赞同你说的“本文作者和译者会想过我说的那些问题”。但是你M写文章直接出个结论让像你这样“高高人”喝彩?让我们这样的下三滥误解,是么?二子,懂不懂修辞和铺垫?还反问,问你妹。
这个?aaa你受啥刺激了?前面是有高人出来,跟我有啥关系?倒是你以高人自居,把楼主批判一番吧?你又拿出什么干货了?出口成脏,你妈怎么教育你的?
是你毫无根据的在质疑别人吧?我说出了我的理由,你自己瞎子?我出口成脏能比你动不动就带上MA厉害,没教养的是你吧?
受不了你这种人,说不出个吊理由,还一副讥讽得意的样子,劣根啊。说别人没礼节,自己还“娘妈”扯个不停,你自己二得要死还显摆,赶紧钻地洞吧你。
这个思想和时下各大公司主推的敏捷开发模式有共通性,一个是设计思想,一个是开发模式,也可以说敏捷开发模式中需要这种设计思想
好文!!!
在弯曲这么多文章中,这篇文章觉得最优价值!
“它很老,但很可靠”
这篇文章忽略了先简单->复杂->才能简单这么一个前提,如果一味的求简单和权衡,对很多资历不深的人来说是一种误导。
如果不加这个前提的情况下,我更倾向于这是一种综合工程的说法,或者说是经理/架构师们在商业/局面控制等外界因素压力下的一种追求快速和稳定之间适度权衡的一种以满足商业需求和后续维护的开发方法,但仅此而已,尤其是当前互联网科技发展如雨后春笋的情况下,更容易产生这种浮躁。我觉得这种思维下产生的东西会很快被淹没在人类发展的潮流中,相反哪些以追求卓越设计思想下的产物更容易促进人类思维发展和社会进步并永久长存,这样的例子数不胜数,大家最熟悉的就是jobs的系列产品设计。卓越是优秀中的最优。在追求卓越的思维方式下是更能将人这种动物潜在能力发挥到极致的一种状态。
不能光简单,同时也要巧妙
说白了就是close form 的另一种表达
真正掌握了“道”的人,简单复杂存乎一心。调试一下复杂系统的时候,有些轻微的错误你可以略过去,看主要的问题,但是有时候真正的关键问题就在某个细小的问题上。懂的人自然知道哪里简单,哪里该省略。不懂的人看了这篇文章之后,只了解了简单的原则,应该也不知道哪里或者什么时候用这个法则。
人类渴望的终极目标,即“知道该怎么样,知道不该怎么样”,也就是事物的本质,人类和自然界都在一直没有停止过在各领域对这个问题探索,楼上提到的“知道哪里简单,哪里该省略”的境界,是需要对一个领域经过深入的研究理解、数次探索上的锤炼和醒悟、谦逊和敬畏的态度才能换取来的。
真正简单的系统是经过从千丝万缕的头绪中找出了那几根最重要的。但简单只是“果”,“因”在于你对自己高标准高要求的复杂艰辛的探索和努力,相对于果,因更加不可忽略。
本来一件很简单的事情,经过你们上面一解释,又复杂了
我一直想将做的事情简单化,这篇文章对我有很大的指导意义! 赞一个!
末学才疏学浅,Panabit见笑了。知道弯曲有不少年轻的读者,很多刚毕业的,我想以自己的经历能够给他们提供另一个看问题的着眼点,仅此而已。
这个必须得顶一下!犯过几次类似错误,最后自己也把这个道理悟出来了.
其实就是Yale Patt经常提到的Speed Demons和Brainicas的区别。最简单的例子就是James Smith的Trace Cache和Sanjay Patel的Trace Cache。
回10楼:小joke而已,不当之处,见谅!:)
抓主要矛盾,快速实现,逐步演化,KISS是我做系统设计时首要的信条。
对于本质的认识需要很多的时间和精力,要认识到认识的过程是漫长的,所以不能等认识到本质才开始做东西,只能就目前理解的程度把东西弄出来,这才是商业系统的一般做法。
C++语言在速成生成力这方面就远远比不过C语言,这个也是他被我抛弃的原因。
有一句不错的广告词叫简约而不简单,原来吴海军的数学之美里也有关于简单设计很好的描述,但确实,都希望能学到举重若轻或者举轻若重的葵花宝典,说出来并不神秘,但真正演练起来,并不是那么容易,还是要付出很多,并且还不能保证成功:)
说起来容易做起来难,最经典的例子:麦克斯韦的叉叉
抓不住核心矛盾的喜欢找各种借口。市场,时间……殊不知很多关键的工具在手,核心就在手。
竞争就是看谁能在最短时间找最核心的部分。
额。。俺发言跑题了。请无视。
赞成理客的说法,葵花宝典非一日之功,速成论可怕。
参考阅读: “LISP: Good news, bad news, how to win big”.
unix/c的方法更成功,更容易成功,更快能见到效果,也更容易做到(实现)。
设计中应该解决主要问题,使用最简单的方法达到目标。细枝末节可以先不考虑,后续单独解决(先实现功能,可靠性、成本、安全性、美观、维护等可以先不考虑)。
这是弯曲评论上最有意义的一篇文章了,真的称得上是黄金法则,没有丰富实战经验的人是理解不了的,而且也无法把握好这个度。
学术讨论还是拿点真材实料出来,请求楼上结合自己的经历给”你指的这些没有丰富经验的人”授道授道。
好文!
能做到简单的实现当然好,但实际上,要做到真正的简洁是非常难的。
同意aaa的说法,有些解决方法看起开很简单,但实际上背后是经过了无数次复杂的尝试。想要简单,先要复杂,我认为这个过程必不可少。
现实就是很多对矛盾的组合:安全、麻烦;功能强大、操作简便。。。。。。
只讲一面,是书生意气,会误导新人
做学术的可以严谨与简单并存,搞互联网的以简单快速来抢占市场份额,可是一旦涉及安全的问题,简单是系统设计最后才想去考虑的元素。这几天才看了一则新闻,凯迪拉克已经开始对旗下全新的 Super Cruise 半自动驾驶技术进行上路测试。
方滨兴一定是这种理论的支持者,胡萝卜都被墙。
楼上这么说,真是侮辱了这篇文章!
个人拙见,正确性》完整性》简单性》一致性,
简单不是最重要的,方滨兴搞不定正确性,所以用简单来代替了。
好文,顶一下,露个脸
真正的好文,这里的简单性不能理解为一个通用的功能,有人用1000行代码实现,而另外一个人则用100行就实现了。这种简单性就像前面有人说的,那是需要功力的,一定要经历过复杂之后,最后才能做到简单。
这里说的简单性,就是指如果我要把某个功能的正确性,一致性,完整性都保证了,可能需要1000行代码(即使对于牛人),而如果我适当放弃这些(假设影响不是那么大),那我就放弃他们,保证简单性,因为简单性就意味着系统稳定性,可读性,可维护性
跟Eric Raymond的The Art of UNIX Programming一个意思,aaa你觉得本文作者和译者会没有想过你说的那些问题?
楼上的二子,我就先赞同你说的“本文作者和译者会想过我说的那些问题”。但是你M写文章直接出个结论让像你这样“高高人”喝彩?让我们这样的下三滥误解,是么?二子,懂不懂修辞和铺垫?还反问,问你妹。
这个?aaa你受啥刺激了?前面是有高人出来,跟我有啥关系?倒是你以高人自居,把楼主批判一番吧?你又拿出什么干货了?出口成脏,你妈怎么教育你的?
是你毫无根据的在质疑别人吧?我说出了我的理由,你自己瞎子?我出口成脏能比你动不动就带上MA厉害,没教养的是你吧?
受不了你这种人,说不出个吊理由,还一副讥讽得意的样子,劣根啊。说别人没礼节,自己还“娘妈”扯个不停,你自己二得要死还显摆,赶紧钻地洞吧你。
这个思想和时下各大公司主推的敏捷开发模式有共通性,一个是设计思想,一个是开发模式,也可以说敏捷开发模式中需要这种设计思想