[研发]周报第36期：Win8，微软的救赎吗？

来源： CSDN 作者： 夏梦竹   2012-12-03/11:42

操作系统 Windows 8 资讯 正文

我们挑选了本周研发频道的精华文章，推荐给您的绝对“有料”，闲暇时不妨来细细品味我们精心为你呈现的这份技术大餐，或许有您意想不到的收获。本期热点：微软在纽约正式发布Windows 8；在华正式首秀Windows 8微软打响帝国反击战；谷歌向开发者开放Coordinate API；软件开发者：猪与鸡的争论？

微软已经太久没有站在最大的聚光灯下了，从苹果引领移动互联网和触摸体验的热潮开始，微软长期扮演一个迟钝的看客角色，无力的注视苹果和谷歌的崛起。好在微软历来就有后发制人这一传统。无论是Windows、Office、IE还是Xbox，微软都是在市场稳定之后再真正发力给与对手痛击。熬到乔布斯离开世界，苹果愈显平庸后，Windows 8正式展开了绝地反击。

本期当属热点：

1. 历经12.4亿小时测试 微软在纽约正式发布Windows 8

北京时间10月25日晚间，微软在美国纽约召开发布会，正式了推出全新的Windows 8操作系统。Windows 8将分别为Windows 8(普通版)、Windows 8 Pro(专业版)、Windows 8 Enterprise(企业版)和Windows RT(ARM版)4个版本。Windows 8被认为是Windows 95之后微软最重要的操作系统，这也是微软首次基于触摸控制进行开发，将支持全屏多点触控和虚拟键盘，还可以支持Stylus手写笔操作。此外这款操作系统同时也可以切换到人们所熟悉的传统桌面模式，允许用户通过键盘和鼠标进行操控。

据Steven Sinofsky的介绍，在正式上市前，Windows 8已经经过了12.4亿小时的测试，新系统在多个方面进行了改进：具有更好的续航能力，启动速度更快，占用内存更少，并兼容Windows 7所支持的软件和硬件等。

四版本Windows 8比较 图片源引自搜狐IT

除了Windows 8版本自身性能的优秀、引入新的应用商店以及增加支持ARM架构的Windows RT版本是最大的改变。尤其是后两点对于微软来说具有革命意义。新的Windows 8应用商店将进入全球231个市场，同时也支持全球109种语言。微软并没有透露应用商店中应用的数量，但据第三方机构调查显示，目前微软应用商店中的应用数量已经超过4000款，其中中文应用约占三分之一。

2. 在华正式首秀Windows 8 微软打响帝国反击战

微软全球Windows与Windows Live事业部总裁Steven Sinofsky

软在上海1933老街坊举办Windows 8预展会，向中国媒体和合作伙伴展示了最新一代的操作系统。本次活动是Windows 8正式上市前全球预演活动的第一站，其真正发布还要等到10月25日在美国纽约的发布会。微软大中华区董事长兼首席执行官Ralph Haupter、微软全球Windows与Windows Live事业部总裁Steven Sinofsky、微软大中华区副总裁/市场战略部总经理谢恩伟、微软大中华区Windows产品部总经理韦青等高管共同出席了本次活动。

微软的意图是想通过Windows 8，全面融合“云+端”、“N屏+云”的生态系统。目前微软已经拥有Office 365、Xbox、Bing、Skype等六款云平台，PC、智能手机、平板电脑、电视、汽车、各种嵌入式设备等是N屏，都需要Windows 8去占领。因此，在架构设计上，Windows 8不仅所有版本（消费和专业版）的内核全部一样，还适用于所有的计算设备，同时包括Window Server 2012、Windows Azure，可帮助开发者轻松实现跨平台开发。

3. 谷歌向开发者开放Coordinate API

为了让开发者能够设计出更好的地图应用，谷歌再次向开发者开放Google Coordinate API（谷歌坐标API），允许开发者使用谷歌地图数据。有了Google Coordinate API，使得移动开发团队在开发地图应用时更为简单，允许团队中的每位成员都可以进行开发，相互沟通。通过地图了解每个人的地理位置并进行工作分配，开发者可以进行不断更新。这也是谷歌坐标API的一大新特性。

利用谷歌APIs检索网站，谷歌地图坐标API可以帮助开发者完成六件事：

coordinate.customFieldDef.list：为团队检索列表中的自定义文件； coordinate.jobs.get：检索工作，包括对该工作所做的所有改变； coordinate.jobs.insert：插入一项新工作，仅能在工作范围内设置； coordinate.jobs.list：给既定的时间戳进行创建或者修改检索； coordinate.jobs.patch：更新工作设置的范围内文件，这种方法支持补丁语义； coordinate.jobs.update：更新工作设置的范围内文件。

4. C++还是Java 哪个响应高频交易应用比较快？

如果你是一个典型的Java和C++程序员，并且用这两种语言编写过典型的面向对象程序。在相同的时间下面编写高频解决方案，Java程序员有可能会提前完成程序并且有时间调整应用程序。在这种情形下，恕我直言，Java应用程序的速度会快些。

以我的经验，Java在执行上会好于C++，因为Java无需检查代码，尤其是微基准测试，其实它没有做什么事情。但是如果没有时间限制，对Java和C++程序进行调优，那么C++程序会快些。然而，考虑到有限的资源和不断变化的环境，一个充满活力语言可能会超常发挥，即在现实世界中应用。

在超高频率下，核心引擎将会超过C，组装和自定义的硬件可能会比面向对象的C++或Java更快。在市场对延迟要求不太高的前提下，C++和低GC的Java是不错的选择。由于延迟需求越来越不太重要，Java和其他动态语言会更富有成效。在这种情形下，选择Java就可以轻松帮你应对不断变化的市场/需求。

5. JavaScript真的需要类吗？

无论你喜欢与否，ECMScript 6中将会包含类(class)的概念。在JavaScript中，类的概念一直是两级分化的。由于JavaScript与其他语言的不同，有些人喜欢JavaScript的无类特征；另一方面，也有一些人讨厌JavaScript的无类特征。那些从C++或者Java转到JavaScript的人，需要克服的最大心理障碍就是接受JavaScript的“无类特征”，这或许也是许多人不喜欢JavaScript或者不学习JavaScript的原因之一。

在JavaScript中并没有正式的类定义，也有一些JavaScript书籍和文章讨论过如何在JavaScript中定义类，其实那些只是自定义的构造函数。在JavaScript中，引用类型是最接近类的东西。

所以，JavaScript真的需要定义类吗？答案当然是不，JavaScript需要一个简洁的方法来定义自定义类型。刚好，ECMAScript 6里面的“class”提供了这样的方法，并且如果这个“class”能够帮助开发人员轻松地把其他语言转换成JavaScript，那么，这绝对是个好东西！

6. Spring抛弃OSGi，转向Gradle

SpringSource从一年半前开始由Maven转向使用Gradle来构建系统，Gradle是Groovy的一款开发工具。现在，3.2版已接近尾声，在该版中会停止向Maven Central中生成OSGi元数据。

曾经，OSGi的强有力支持者SpringSource已经渐渐抛弃使用OSGi框架和模块化技术。尽管像Spring Roo（2010年运行在OSGi上）和Spring Dynamic Modules（2008年发布）这些Spring产品在初期都选择使用OSGi生态系统。然而差劲的设计决策，例如试图紧紧地约束依赖包名称和确定确切的版本号（而不是使用导入包这种更加宽容理智的方式来确定版本范围）这些都阻止了对OSGi技术的采用。这些失败的设计在SpringSource EBR上都能活生生地体现。

7. 软件开发者：猪与鸡的争论？

一天，一头猪和一只鸡在路上散步。鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”

前面一个故事往往被用作在管理和营销上来说明一些道理，而后面这则故事应用在敏捷开发，用来说明不同角色的职责。在Scrum过程中，“猪”是在Scrum过程中全身投入项目的各种角色，他们在项目中承担实际工作。而有的像上面笑话中的“猪”要把自己身上的肉贡献出来。“鸡”并不是实际Scrum过程的一部分，但是必须考虑他们。（注：在Scrum团队中，ScrumOwner（产品经理）、ScrumMaster（项目经理）、开发者、需求分析师为猪类角色，而测试工程师、UI工程师、QA、客户等为鸡类角色。）

当设计到给重大产品做决定时，谁拥有最终的决定权，是全身心投入开发软件的程序员还是将软件变成公司产品谋利的业务人员呢？对于该话题常被引用这则笑话而引发广泛讨论。反思，难道这个问题真的只是集中在最终创建一整套新措施上吗？开发者如何划分，是“鸡”还是“猪”呢？如果该产品不成功谁来为其擦屁股？

8. 是时候清除你的僵尸代码了

随着万圣节的临近，是时候讨论一下软件开发中广泛存在的问题了：僵尸代码。我参与的每一个代码库中都或多或少被注释掉的代码，也就是所谓的“僵尸代码”。

//暂时关闭这个特性吧，Jimmy在写这段代码的时候肯定是喝醉了。 //想想一下这段代码的可怕……不过至少它被注释掉了。

那为什么叫它们僵尸代码呢？因为僵尸并没有真正死去，正如恐怖电影上所呈现的，尽管僵尸已经死了，但它仍然足够困扰我们。某种意义来说，僵尸代码实际上介于活与死之间……只是等待某一天来毁掉你的生活。说注释掉的代码是活的，因为它还存在在代码库里，程序员会在维护和重构过程继续与之打交道，也许只是扫一眼，或者出现在某个关键字搜索的结果中。但它也是死的，因为它并没有真正在产品里起作用。因此需要尽快地把它埋葬掉！

如果你打算注释掉代码，先问问自己：

1.如果需要，应该什么时候取消注释？

2.有必要的话，我以后能通过版本控制再找回这段代码吗？

3.这个未完成的工作应该放入一个分支中吗？

4.这个功能可以通过配置开启/关闭吗？

5.我会为这段代码重构需求吗？

让我们把这个一年一度的万圣节变成僵尸狩猎之夜吧！

相关阅读：[研发]周报第35期：优化HTML5编码的8个最佳实践