和Google互补的搜索引擎Wolfram|Alpha
Wolfram|Alpha与Google究竟是什么关系，Wolfram|Alpha自己是如何定位的？Wolfram|Alaph在多大程度上是语义网搜索呢？InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。
新闻
透视“语言大战”：C++呼唤敏捷实践
作者 Jeff Xiong 发布于 2007年9月15日 上午1时20分
以Linus Torvalds的一番言论为导火索，国内的技术博客们掀起了一场不大不小的“语言大战”。是否真如Linux之父所说的那样，“C++是一种糟糕的（horrible）语言。而且因为有大量不够标准的程序员在使用而使情况更糟，以至于极容易产生彻头彻尾的垃圾（total and utter crap）。”孟岩的切身经验颇值得玩味：
我早在N年前就发现自己写程序速度慢，我当时对STL远比周围人熟悉，照例说长缨在手，应该效率很高才对。结果发现不是，写程序的时候特别没自信，总在想：“这样固然是可以work了，但恐怕有更好的方案吧，会是什么呢？加个模板参数试试？要么抽象出一个基类？做一个bridge模式？那么Ownership的问题怎么解决？谁来负责回收内存呢？移植一个boost::shared_ptr过来吧！可多线程情况下会不会拖慢速度呢？应该不会，可是会碰到循环引用的情况。要么在中间搞一个weak_ptr把循环链断开？哎呀不行不行，太复杂，别人也理解不了。还是先这样吧，能work就行。” 就这样，兜了一个圈子回来。有的时候，这个圈子不是纯柏拉图式的，我会真的实现不少 “优化” 设计来比对，那个时间啊，花花的就耗在里面了。另一位资深的C++程序员刘未鹏则这样感叹：
群众是容易被误导的，我也曾经是。以为掌握了更多的语言细节就更牛，但实际却是那些语言细节十有八九是平时编程用都用不到的。C++中众多的细节虽然在库设计者手里面有其用武之地，但普通程序员则根本无需过多关注，尤其是没有实际动机的关注。一般性的编码实践准则，以及基本的编程能力和基本功，乃至基本的程序设计理论以及算法设计。才是真正需要花时间掌握的东西。显而易见，在C++这种语言上，人们投入了大量精力、撰写了大量图书和文章来关注它的语言细节，却对在真实环境下使用它解决问题的最佳实践重视不足。如果这还不够糟糕的话，不妨再看看C++在项目层面上的最佳实践——几乎没有任何成文的资料存在。当敏捷实践对于Java、.NET、Ruby等等社区的开发者逐渐成为常识时，C++程序员们还要花大把时间去学习摸索如何写一个好的makefile、如何组织自己的项目目录结构，更不用说持续集成和测试驱动开发了。
但C++团队仍然需要敏捷实践。据记者的了解，国内有多家从事电信、铁道等行业应用开发的IT企业已经痛感缺乏项目组织手段和质量保证手段带来的问题，并希望通过引入敏捷实践来改善项目质量，提高工作效率。在C++项目中引入敏捷方法，至少需要以下几方面的最佳实践作为支撑：
- 项目自动化：如何在make等现有工具的基础上，通过合理的项目组织，实现项目构建、集成、测试的完全自动化。
- 测试驱动开发：如何引入以CppUnit、CxxTest为代表的单元测试工具，并以测试驱动功能代码的开发。这个话题又可以引申出两个方面：
- 面向对象设计：针对某一特定领域的软件应用，如何进行合理有效的面向对象设计，使之有可能进行单元测试；
- mock：如何为C++应用引入mock技术（甚至是IoC容器），从而简化单元测试。
- 持续集成：如何加快集成的频率，将C++项目与现有的持续集成工具（例如CruiseControl）结合起来，使集成状态成为项目健康情况的重要标示信息。
- 重构：如何有效利用现有工具，对规模较大的C++程序进行重构；如何避免使用对重构构成障碍的语言特性。
自己动手，丰衣足食
发表人
tian chaohui
发表于
2007年9月16日 上午12时25分
-
一般性的编码实践准则，以及基本的编程能力和基本功，乃至基本的程序设计理论以及算法设计。才是真正需要花时间掌握的东西。 先赞一个。 对于热门的RUBY之类，好像C++的持续集成工具没有那么热，但不是没有。 1、项目自动化：在现有工具上，写一点脚本，胶水代码之类，不难吧。不要想着坐享其成。 2、测试驱动开发：不要想着如何如何，Cppunit之类已经比较不错了。TDD更多来自于实践，而非空想。当然重构工具缺乏，其迭代效率不如JAVA之类，但是不妨碍你实施想法。 3、持续集成和什么工具结合不重要，重要的是持续集成。我唯一不满的问题是当模板类大量运用的时候，编译时间实在是个大问题，这个可以通过管理改善一点。 C++上实践敏捷我已经有3年时间了，只能说这个领域不那么热闹，但是并不是一点办法没有。
1 条回复
关注此讨论 回复