今天跟一些朋友在信件里讨论C++的使用。一个还在学习C++的朋友，认为要把重点放在虚函数、多态性、STL上。我认为学习的时候这样考虑肯定是对的，但是真正开发的时候，不能因为你掌握了OO、generic这些先进武器，就非要用上这些东西，以示区别不可。谨慎合理地使用语言的机制是开发良好C++程序的关键，至少在心态上是关键。

下面是信件内容的摘选：

你写C++的时候，一定要想清楚，你是在做基础设施还是在应用。如果是基础设施，比如类库、框架、底层功能的class wrapper，那么可以允许你大胆地使用C++中的各种技巧，关键的要求是你得暴露出来一个clean的interface，让别人好用。这一点并不容易，特别是有的时候你觉得很好用的接口人家就觉得很别扭。所以比较省心的做法就是把接口设计成流行的风格。比如模仿STL的风格，模仿Java的风格，模仿COM的风格，甚至模仿MFC的风格，可能都比你自己发明一种新风格要“好用”。

可是做应用开发的时候，手就要把紧点，别自鸣得意地滥用高级技巧。应用开发很大程度上受基础设施的制约，总的来说，使用函数、POD对象、concrete class，从framework中派生出来的class，再加上一点点用来节省打字的template，足以满足应用开发的需要。特别是当你的下面没有很完备的class library或者framework的时候，千万不要一边写应用，一边又想着怎么让自己的这些东西“为万世开太平”，那样的话很容易就会把程序结构作的过于复杂。最后往往是应用没写好，也没有可复用性。以前我没有经验的时候，最容易犯的错误就是这个。

做基础设施的开发，那叫“设计”，是要为以后考虑的，为了长远利益可以牺牲眼前的进度、简单性。可是做应用，那眼前利益是第一位的，你先把手头的东西又快又稳地run起来，才谈得上以后有复用的可能。眼前的东西作的一塌糊涂，说里面有的模块设计得超级棒，绝对能复用，你自己都不相信。代码要一丝不苟，该写注释写注释，该写assert写assert，该怎么样怎么样，不能因为想着“反正也就是一锤子买卖”就马马虎虎。至于能不能复用，那是以后的事情。所谓Design for today, code for tomorrow，就是这个意思。

来自：http://blog.csdn.net/myan/archive/2006/05/25/754239.aspx

评论

#   钀ц惂澹?Url= 发表于2006-05-25 11:49:00  IP: 222.90.193.*

好

#   sevencat 发表于2006-05-25 11:55:00  IP: 58.246.57.*

C++能复用的很多是比较简单的，跟其他的类没啥关联的代码的类。 项目导向而不是技术导向。

#   tinyfool 发表于2006-05-25 14:02:00  IP: 219.142.220.*

受益

#   1000copy 发表于2006-05-25 22:55:00  IP: 222.210.92.*

核心是解决问题，而不是用什么工具，采用什么模式思考，用什么范式书写，采用什么case测试。

#   1000copy 发表于2006-05-25 22:57:00  IP: 222.210.92.*

以及用什么驱动，以什么为中心，按什么契约，做什么截取，搞什么视图，反转什么控制。

#   doggyzone 发表于2006-05-25 23:55:00  IP: 60.63.13.*

喔，common sense第一。写得多了自然知道怎么拿捏。写code这东西，学是学不会的。唯手熟耳。

#   IT专栏 发表于2006-05-26 09:56:00  IP: 218.4.93.*

好文章啊 －－－－－－－－－－－－－－－－ http://blog.csdn.net/fengyv

#   pripor 发表于2006-05-27 19:38:00  IP: 202.110.209.*

呵呵 myan的文章是越来越短了了 也远不如04年底到05初的那段时间的文章深刻 好像lippman就是那段时间来的吧 期待以后的好文出现

#   mcs51a 发表于2006-05-27 16:43:00  IP: 58.34.144.*

就是,就是.实现使用是第一的,能跑起来最好,安全耦合效率是其次的,再说俺们不是有重构吗.

#   ppwd 发表于2006-05-27 14:06:00  IP: 61.52.43.*

赞同楼主所说，呵呵

#   larrylee 发表于2006-05-27 22:02:00  IP: 58.213.12.*

我常在程序员杂志上看到孟老师的采访文章，呵呵 感觉很不错啊！看后觉得要好好学习c++了

#   Steve 发表于2006-05-28 09:44:00  IP: 218.82.124.*

说实话，这种时候真的麻烦，又不好太打击别人。这样的小朋友多数自尊很强，刚看了一点设计模式方面的书，就跃跃欲试。我跟他谈，充分肯定他的努力和探索，但也强调项目的时间紧迫，在工作中使用不熟练的模式$%&&#…………，呵呵，别人明的接受，但死不改悔，而且还洋洋自得，置项目的利益于不顾，沉醉在虚幻的自我满足感之中，好像自己已经成为pattern expert了。真是哭笑不得，和他沟通也很越来越困难。最后只是想通了，他们还像小孩子一样的充满了好奇和特殊的虚荣，多数这样的人可能还是性格问题，不容易成熟起来。

#   rollor_phoe 发表于2006-05-28 09:45:00  IP: 220.196.164.*

说得有道理啊。

#   YD 发表于2006-05-28 00:19:00  IP: 219.144.133.*

有力度

#   343 发表于2006-05-28 14:05:00  IP: 202.22.249.*

这个，看能力拉，能力足够的情况下设计模式非常的重要 我就见过人家两个项目，一个结构设计的不错。另一个则设计的很差。结果是，之后的对项目的维护，本来是差不多的事情，一个人只用一两天，而且不容易出BUG，另一个往往要几个礼拜，而且BUG到处都是，让人很难放心。而且这个问题越到后来越严重，最后的结果就是一个项目一直都有很好的可维护性，另一个已经没办法改了。后来那个设计的好的项目的经验和代码被很多后来的项目用到，另一个完全就象垃圾一样扔在那里，送人也没人要了。

#   小蔡 发表于2006-05-28 16:39:00  IP: 58.49.155.*

其实vc就想你们说的那样,不是自鸣得意地滥用高级技巧,而是自己要去找到一个符合用户要求界面接口,去实现他的功能,

#   风 发表于2006-05-28 19:48:00  IP: 222.183.184.*

适合的才是最好的. 就象要JAVA里面, 在你学习是花时间可能最多的EJB, 可能用得很少, 把你弄得焦头烂额的实体Bean, 可能你一辈子也用不上. 但, 从学习这些东西过程中越渐清晰的编程思想却是你受用终生的.

#   jason 发表于2006-05-29 09:48:00  IP: 58.247.17.*

解决问题是关键. 目前一般的应用开发其实很多特定的技术是用不到的.

#   乱批一气 发表于2006-05-29 09:06:00  IP: 221.237.165.*

现在中国程序员写的大半是应用，类库框架好像与我们无缘，除非自己搞一个开元项目，奈何大半也只能胎死腹中，看来我们注定只能像m兄说的，让它run起来再说，但是又有多少再说的机会呢，只有默默想着下一个项目我一定...

#   Hi_Jack 发表于2006-05-29 11:58:00  IP: 59.108.33.*

环境在很大程度上决定了我们的角色

#   zcpro 发表于2006-06-19 13:44:00  IP: 60.176.140.*

唱一下反调，上面都是附和的 做应用的时候不想着代码复用，那么你永远也不会有想到写库或者学会怎么写库的那一天。就像当兵一样，不想当将军的士兵不是个好的士兵，只要遵守纪律就可以了。我的体会是做应用的时候要多思考复用的问题，但是不要钻牛角尖，够用就好，等项目做多了，总能整出个库来的。 写程序就是做选择，关键是合理，难点就是怎么把握这个度

#   yayanyang 发表于2006-06-19 17:41:00  IP: 222.212.110.*

如果说我要做的是没有基础设施，类库可以利用的东西。碰巧它又不大不小，而且也能够预期以后多多少少还是要用到它的，这时候改把它当应用做了，还是“设计”? 的确很难决断哦！

#   xiaosan_zl 发表于2006-06-26 14:33:00  IP: 202.105.139.*

在下无名鼠辈一名.留下几个字也算到此游吧. "应用开发"并不是如此简单,大部分情况下没有好的"设计"最后很难"又快又稳"的run起来.往往RUN起来的是一个丑陋的不能用的东西.当然,个人的小实验,小工具规模的东西除外

#   zengyi 发表于2006-06-26 21:16:00  IP: 202.120.38.*

所谓Design for today, code for tomorrow，就是这个意思。 写反了？

#   肉骨头 发表于2006-06-30 00:19:00  IP: 61.51.81.*

急，功，近，利 鼠，目，寸，光 没有实践，哪有经验？ 没有失败，哪来教训？ 钢铁，不是一天炼成的。

#   肉骨头2 发表于2006-06-30 00:43:00  IP: 61.51.81.*

从项目的角度,您是对的,项目进度是第一位. 但这并不能保证最后那个东西稳稳当当, 好多时候是晃晃悠悠,心惊胆战。 立足长远, 当然如果有长远打算的话, 请design for tomorrow.

#   winking 发表于2006-07-01 12:48:00  IP: 218.82.85.*

说得太好了。事实上软件需求总是在变化的，你永远不知道明天的软件需要什么样的功能。设计时应该做满足目前需求的最简单设计，避免over engineering。需要变化？需要扩展？我们还有一种武器叫重构。

#   pighead 发表于2006-07-01 17:10:00  IP: 221.219.245.*

紧张的项目基本上不可能给你重构的时间，甚至局部的重构也不允许。 规模庞大的项目，即使滚瓜烂熟也只能细致末叶的修修补补。重构？烧糊涂了，回家歇着吧。

#   xiaosan_zl 发表于2006-07-05 13:46:00  IP: 202.105.139.*

TO pighead： 兄弟果然是人如其名呀，佩服！

#   刘典 发表于2006-07-08 13:27:00  IP: 221.9.35.*

to pighead： 为什么项目紧张？ 为什么没有时间？ 想过这些问题没有？ 明明是代码结构混乱 不合理导致项目时间不够，重构给你一个节省时间的途径 你还不接受。

#   pighead  发表于2006-07-10 13:29:00  IP: 221.122.38.*

我说的是客观因素（项目计划）造成的时间紧张，您说的是人为因素造成的项目进度滞后。 我的意思是：从一开始，在项目计划中就没有给你重构的时间——为了取得客户的注意并赢得项目，能砍掉的时间都砍掉。 如果您的项目都有重构的时间，您真的好幸福，我羡慕死。 如果您没有做过“紧张的项目”，我也羡慕死。 如果您没有做过项目，我……

分类： 编程语言 C/C++编程语言 修炼之道