技术改变世界 创新驱动中国 – 《程序员》官网

提问嘉宾：

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi在中国的推广起到了很大的作用。

回答嘉宾：

黄冬，有多年软件开发、系统架构、系统运营的经验验。长期关注于高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统，也是中国FreeBSD、Python社区的发起者和积极参与者，也是国内啄木鸟（http://www.woodpecker.org.cn）社区的创始人之一。现在正在北京从事系统架构咨询及系统运营外包的的创业之路。

林昊：随着数据量的不断增长以及前端应用的不断水平扩充，数据库的压力会成为明显的问题，这个时候常用的方案是数据拆分，在数据拆分时有些什么较好的拆分方式，以及如何能够做到数据拆分后对已有程序不产生影响或产生很小的影响？

黄冬：这个拆分以应用的特性为主，从业务的特性出发更为重要，不是一个技术层面的通用解决方案，一般来讲先会从业务自身分析，已经有人总结过数据库做拆分的几种方式： 阅读全文 »

一些敏捷团队在实施敏捷开发中忙于编码、忙于Unit Test、忙于沟通、忙于Build等，虽然也有编码审核阶段，但大都浮于表面，流于形式，效果不佳。本文结合实践，介绍笔者对敏捷开发中CodeReview的理解和相关经验。

文/陈序明 黄彦军

敏捷开 发中Code Review的目的及内容

做任何事情，首先要清晰为什么要做，才能有目标和动力把事情做得更好，Code Review 也是如此。只有清晰明确了敏捷团队进行CodeReview 的动机，才能以此为方向开展后续工作。下面我们推荐的敏捷开发中常见的Code Review的目的：

设计合理性Review

在笔者的另一篇文章中《敏捷开发中的架构设计》谈到，敏捷开发中崇尚Code is design，对开发人员提出了比以往更高的要求，即需要开发人员不断地重构出合理的设计。所以敏捷开发中的Code Review也需要承担一部分“结对设计”和“设计把关”的职责。

这部分的Code Review 包括：设计的合理性（如实现方法，数据结构，设计模式，扩展性考虑等），是否存在大量重复代码和其他组件是否有重复的代码，包结构设计是否合理等。

笔者了解的一些项目中， 进行敏捷开发后， 提高了开发效率， 但是设计的质量却下降了。如Repeat Yourself 的现象（特别是跨组件之间的Repeat Yourself 现象）；更有甚者，在笔者看到一个某银行的应用中（不是国内的），数据库连接和操作是直接在JSP中写SQL语句。

像这些Bad Design 的例子还是很多的。这些在重构的时候应该由开发人员解决。但考虑到不同开发人员之间技术功底不一，很有必要在Code Review阶段进行Review和讨论。 阅读全文 »

一个成功的产品就像一个人的成长过程一样，会经历孕育、婴儿、少年、青年、成年、老年等几个不同的阶段，而产品经理就像无数操心的父母一样，在不同阶段要有不同的心态和处理方式，以帮助产品茁壮成长。

文/Eric Sink 译/顾全

在我贴出的一篇博客中，有这么一段：

最后说点完全不相干的事，别错过了6月3号微软技术大会上的即兴演奏会。我们几个SourceGear来的小跟班儿打算上台表演一曲Pinball Wizard。我弹原声吉他，我们的开发经理Jeremy Sheeley 弹贝司，而我们的产品经理Paul Roub弹EvilMastermind Schecter PT。

话说回头，那篇博客的第一个读者评论写道：

3个经理。哇。你们公司肯定还在增长，要么就比较大。

发表评论的仁兄很可能是用“经理”一词来指代“管人的人”。如果是这样，那是没错，我们公司的经理不止3 个，但是演奏Pinball Wizard 的3个并不都符合这一名号：

• Jeremy Sheeley的确是个经理。他管理着Vault 和Fortress 开发部门。
• 严格说来，我觉得我是经理。但是认识我的人会说，把我当成经理实在太抬举我了。
• 但是Paul Roub是“产品经理”。在SourceGear（还有我所知道的大多数其他公司）这里，产品经理并不[必然]管理他人。

产品经理是什么？

简而言之，产品经理是市场营销人员，他们关注于战略和产品特征之类的东西。

人们一想到市场营销，念头就跑到标识、图形设计和广告等事情上去了。这些是市场营销中的沟通传播一面而已，也就是所谓的“营销传播”（marcomm）。

市场营销的其他方面是那些更关注产品本身的东西：

• 市场定位
• 产品差异
• 功能特性
• 竞争状况
• 市场研究

这些活动都是产品经理的领域。 阅读全文 »

P2V（Physical to Virtual）是将实体机转换为虚拟机的一种技术，是所有企业虚拟化的第一步，但并不是每个企业都能顺利进行P2V的。本文从P2V的应用场景出发，为您介绍P2V实施过程中的重点与难点。

文 / 胡嘉玺

小张是公司的IT主管，常常要应付老板对新科技的要求。当虚拟化成为新潮流时，也成为小张的新功课了。老板要小张评估公司是否可以进行虚拟化，希望能赶上节能减排的新趋势。

服务器合并是虚拟化的第一步，小张当然也是从这开始做的。但全公司都是一台台的服务器，不管是数据库、邮件服务器、网页服务器、代理服务器，晚上还得和国外的公司进行数据交换，所有的服务器是一刻不能停的，怎么可能说虚拟化就虚拟化呢？

此外许多系统已经是NT或Windows 2000的老系统，要安装上虚拟机还得重装系统，但是已经找不到光盘或是驱动程序了，因此重装系统是无法成功的，要将旧服务器虚拟化，最好的办法就是实体机转换（Physical to Virtual, P2V）。

P2V是所有企业虚拟化的第一步，但并不是每个企业都能顺利进行P2V的。首先要考虑的，就是实体机上的数据。如果你的实体服务器的OS是安装在实体机的硬盘，数据也没有放在网络储存上，那P2V就是最坏情况了。如果你将OS安装在FC SAN上，并且将数据存放在网络储存设备上，那么只要利用对应的方式就可以在很短的时间内将实体机转到虚拟机上，有时甚至只需花费几分钟的时间。

利用专业工具进行P2V的方法

将实体机的磁盘数据转换成虚拟机格式，一向是相当耗时的工作，一般是使用FC SAN加上虚拟机产品的快照机制，但如果你的公司没有FC SAN，也可透过快照与成本较低的iSCSI机制，加速实体转换虚拟的工作。P2V主要的重点就是硬盘。由于虚拟机能仿真出CPU和RAM，但硬盘中的数据会从分区变成文件，因此完整的P2V过程，就是将实体机器转换到虚拟机环境中，最后将实体机器的磁盘区转换成虚拟机可辨识的文件格式，才能为虚拟机所用，这是需要专业工具的。 阅读全文 »

提问嘉宾：

黄冬，多年软件开发、系统架构、系统运营的经验。长期关注高可用性、高可扩展性的系统架构设计。主持设计和运行过多个大型高容量产品和系统。是中国FreeBSD、Python社区的发起者和积极参与者，也是国内啄木鸟（http://www..woodpecker.org.cn）社区的创始人之一。现在北京从事系统架构咨询及系统运营外包的的创业。

回答嘉宾：

邓毅，网易有道技术总监，负责新技术与应用研究团队的工作，带领很多有道核心技术的开发。清华大学计算机系博士学位，在模式识别、计算机视觉等领域有丰富的研究经验。

黄冬：互联网在过去的数年中发展迅速，交换带宽已经从10M迅速提升到了万M，而计算机的总线、CPU计算能力出现了很多瓶颈。经常会发现一台服务器的带宽有千M甚至更高，而使用的却不足，在架构上有什么考虑，让一台服务器能更多用起这样的带宽来？

邓毅：网络技术的高速发展的确使得单台服务器的带宽有了很大的提高，这可以使得一些以前不太好做的事情更容易的实现。

一方面，对于后台计算服务部分，高速的带宽使得我们可以把更多的服务器通过以太网连接起来，进行大规模的分布式运算，让不同的机器处理大数据的不同部分，再通过网络把数据进行汇总，从而得到以前需要大型机才能获得的超大规模的计算能力，这让我们可以从海量的数据中分析出更加有用的信息。此外，通过网络，我们可以把多台机器联合起来组成分布式的存储系统，从而提高系统的存储容量、访问带宽以及可靠性。

另一方面，在前端与用户直接接触的部分，由于带宽的提升、网速的变快，用户的客户端程序可以更加频繁的与服务器进行通讯，传输更多的数据，“云计算”或者“软件加服务”的模式，使得原来单机服务无法实现的功能或者服务质量得以实现。例如有道的词典，当存在网络连接的时候，客户端的软件会把查询需求发送到服务器端，服务器端可以在一个非常大的词库中进行查询，还可以做一些智能分析的操作，从而在不占用用户本地资源的情况下，大大提升用户的体验。另一个例子是类似“云杀毒”之类的应用，通过网络把数据传回服务器进行杀毒，也是充分利用当今互联网的带宽。

阅读全文 »

编程习惯

文/Alexey Radul 译/程显峰

近年来，我对编程艺术有很多体会。过后，我发现有些体会是错的；有些体会我遗忘了但又重新感受到；而另外有些则是必然会发现的。我还完善了一套项目管理的好习惯，这些习惯包括我自己的，或者小组的，抑或是更大的,公司内部的。一方面，这些习惯对软件的成功开发是至关重要的（太小或者纯粹巧合的不算），另一方面，这些习惯也不是什么高深莫测的东西，较小的篇幅就可以说清楚了，第三，这些习惯都没有得到应有的重视。所以我把这些写下来，而你呢，正读着呢。

本文包含很多零散的个人建议，有六大块，各讲一个方面。因为建议很多而且相互联系紧密，所以不太好把他们逐条陈列。这样写还有一个好处就是你可以有所挑选的阅读，把你所知道的部分跳过去，把你想重新思考的部分温习一下，或者只是简略的阅读提纲不深入研究具体内容。 阅读全文 »