Good code is cheap code
好代码不值钱http://www.aqee.net/2011/03/16/good-code-is-cheap-code/http://www.aqee.net/wordpress/wp-content/uploads/2011/03/2465416_153513073_2-300x191.jpg
长久以来我一直主张：好代码是廉价的代码。
当我跟做开发的同事说出这话时，他们的第一反应是一种惊愕，然后是将近一个星期的嘲笑，把它当作一个笑话来讲。当他们走近看我的表情、知道我是认真的时，才收敛一点。
当最初的惊愕消退后，他们会用一些这样的话来反驳：“好代码不廉价，好代码是采用经过数十年计算机科学研究和积累得出的最佳实践设计模式和方法论建立起来的精心制作的程序代码。”
我只好继续解释为什么他们给出的好代码的定义有问题的原因是(这是很多开发人员都忽视了的一个原因)：知晓各种设计模式，框架，技术技巧只是事情的一方面，而知道何时该、何时不该应用他们才是更重要的问题。在不知道一种技巧方式如何能对系统的开发有帮助的情况下，这种模式方法极有可能成为一种开发的阻碍，而不是一种有益的帮助。
我还要解释说，我所说的“廉价的代码”是指这些代码只需要很少的人/天数就能开发出来，并不是说是由没有经验的开发人员、在很少的工资报酬下、用6个月封闭式、只有烤白薯和豆腐汤可吃的环境中开发出来的东西。
但是 … 设计模式毕竟是个好东西 … 不是吗？当然，但它们好在哪里？它们能提供什么好处？
[*]容易维护[*]产品更健壮[*]容易理解[*]易于日后的改进提高[*]更好的可跟踪性你会发现所有的这些最终都落到一点上：从长期的角度看，它们能让你更快的做事情。这事情有可能是系统迁移，或是增加一个新功能，不论是什么，通过运用这些方法模式，你会在时间效率上获得实实在在的好处。
这么说，我们观点一致吗？
怎么说呢，让我给你们说个例子，我们看看实现它的几种方式。
系统用PHP创建一个发邮件的表单，表单里有几个表单项，用邮件把这些数据发送给某个人。除此之外，表单里的内容还要存入MySQL数据库里。
现在，用什么方式实现它们最好？按照传统的说法，采用最好的实践设计模式，你可能会想到这些：
[*]MVC[*]N-层设计，包括数据库抽象层[*]对象关系映射(ORM)[*]可能用到的框架[*]XML配置和相关模型[*]等等.我可以说，这简直是疯了，客户的这些需求完全可以用10几行代码、一个小时里(包括测试时间)完成，而且所有的那些方法模式所希望达到的效果(诸如可读性，可移植性，稳定性)都有了。如果使用上面列出的那些，反而真正的会达不到这个目标，使代码复杂化，难于理解和维护修改。
那现在，假设客户又来了，要求做一些改动，比如要增加一个管理员的界面。这样的话，你就胜利了，你已经实现了很多很有用处的东西；然而这是因为你在第一次开发这个系统时付出了很大的代价。我要向你声明的是，即使我现在把这些简单的代码进行重构，增加一些简单的业务层，也仍然比按你要求的那种过度技术化的初始实现方案要简单的多。
再说了，如果客户要求的只是在表单里增加一个属性，那你的N-层设计方案会让你痛苦不堪，因为你需要改动各个层，包括那些CRUD代码。
SCRUM我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发；它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西；它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。
相反，在你需要的时候你才去重构。当然，这会有一定的风险，因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而，产品开发就像是一个沙漠中四处漂移的沙丘，你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。
复用性有些人会指出，我所说的方式产生的代码不具有太多的复用性，不能在新开发的一些其它系统中使用。我对这个问题的回复就是，在根本不知道某些东西是否/如何/在哪将会被复用的情况下去设计一个可复用的东西，这就跟去实现一些你根本用不到的功能或你的应用里跟本用不到的功能一样愚蠢而糟糕。如果你有一个清楚的远见，知道什么地方会复用这些东西，这就不同了，因为你确实有一个内部的业务需求在指导你正确的开发方向。
我的最后的思考 …[*]了解你的设计模式，知道它们各自的好处(我一直认为，好的程序员和伟大的程序员之间的区别就在于伟大的程序员理解他们的模式)；[*]让你的代码廉价：[*]当模式能够给你带来好处，而且为你省时时才去使用它们；[*]如果不是这样就不要使用它们(例如：想想你最近的一次为什么要把系统迁移到一个不同的数据库上？)；[*]当框架能够帮你提高开发速度时才使用它们；[*]在必要的时候重构，不要做一些超前性的开发；我想，如果你能按照这些指导原则做事，你会发现开发周期变短、实现的代码更简洁，易于调试，易于维护修改。 感嘆阿!
現在需要寫一個自用的程式，管理自家的資料庫，不得已要從0開始學ACCESS，連現在的電腦裡都還沒有裝上去。
一本書厚的和枕頭差不多，你們這些編程為生的，偶都視為高人------ :good :good
我觉得掌握了一定的设计原则和技巧之后，程序员面临的主要问题就是避免over design. 做好了减法的代码，才是真的好代码。
Bob大叔的书里有一个测试驱动的例子，一开始还是比较面向对象的设计，在不断的重构过程中最终变成了一段简单的“非面向对象”代码。这个例子我认为可以视作是减法的典范 :lol
程序员的一生，是与过度设计做斗争的一生:victory: 好代码最好自己做framework,这样就bu廉价
实现CRUD,还有个好办法, 自动代码生成... 原帖由 西澳瓶鼻海豚 于 21-5-2011 21:31 发表 http://www.freeoz.org/ibbs/images/common/back.gif
感嘆阿!
現在需要寫一個自用的程式，管理自家的資料庫，不得已要從0開始學ACCESS，連現在的電腦裡都還沒有裝上去。
一本書厚的和枕頭差不多，你們這些編程為生的，偶都視為高人------
干吗要用Access那么烂的东东？貌似微软都基本上不提这个了。
找找看有没有基于MySQL的开源软件吧，多半有符合你的需求的。 原帖由 coredump 于 21-5-2011 21:21 发表 http://www.freeoz.org/ibbs/images/common/back.gif
SCRUM我发现Scrum能吸引我的最大一个原因是它能迫使你敏捷开发；它能迫使你在每个Sprint结束的时候把东西都实现、发布。它不会让你做出目前用不到的多余的东西；它不会允许你在实现东西上有任何所谓“正确方式”的奢侈行为。
相反，在你需要的时候你才去重构。当然，这会有一定的风险，因为在实现某些功能上你会花去比当初已经做了一些基础工作的情况下要更长的时间。然而，产品开发就像是一个沙漠中四处漂移的沙丘，你永远不可能准确的知道一个产品在将来会做如何的改动。所有的你花在实现这些很有吸引力的各种模式上的时间很可能会成为一种完全的浪费。
这个作者有空去研究一下Techical Debt这个词。
另外，盲目乐观于快速成型代码，以与过份担忧“用心”设计出来的系统“过度设计”，
不是太有道理。
我现在手上有一大堆快速写成的过度设计的实现，
导致后来参与开发的人员不得不通过不断的copy & paste，在不求甚解的情况下型成了
大量的重复代码。再加上不求甚解的追求TTD测试覆盖率，导致代码过份膨胀，
整个开发已经到了泥足深陷难以自拔的地步了。 SCRUM又是一个大坑........... 我做了10年以上的软件，发现几乎所有牛B烘烘的“设计模式”、“管理模式”都是扯淡。现实中没看到多少接近那些模式的个案。当然各种成分肯定是有的，有点这个，有点那个。但是拿这些纸面上的东西来套现实……那个从客户需求到实际产品的秋千架的漫画可能是最好的注解。
我觉得LZ的论点，吸引眼球的成分更加多一些。
绝大多数的软件开发，都不需要创新。只要能够做到80%左右的的实际需求，恐怕就是个优秀的产品了。要做到这点，首要的是communication、communication、communication。当然技术能力也很重要——基本的能力，以免产生鸡对鸭讲的局面。至于设计和实现当中的取舍，其实只要有足够的经验，很少会碰到左右为难的情况，因为最佳解决方案只有一个——前提是你对需求和手头的资源有充分的了解。上帝早就给了你答案，问题只是你看不看得见。
回复 #9 tristone 的帖子
你说的是这个？http://ww3.sinaimg.cn/large/4b625dcfjw1dgkjlo66y5j.jpg 原帖由 sliuhao 于 3-6-2011 15:14 发表 http://www.freeoz.org/ibbs/images/common/back.gif
你说的是这个？
http://ww3.sinaimg.cn/large/4b625dcfjw1dgkjlo66y5j.jpg
是这个 http://juixe.com/techknow/wp-content/uploads/2010/05/software_engineering_explained.gif
页:
[1]