LOADING

Follow me

【转载】国内为何孕育不出震惊世界的软件产品
四月 23, 2017|DockerPaaS

【转载】国内为何孕育不出震惊世界的软件产品

【转载】国内为何孕育不出震惊世界的软件产品

    软件行业已经成为除了金融投资行业外另外一个高薪的行业。但是,目前为止,业内层出不穷的优秀软件,由国人发起的少之又少。国内软件行业虽然起步较为缓慢,但是,国内对软件行业的支持力度已经很大了。政府对这个行业的支持,社会上培训机构林立,国内高校更是大力推动。再者说,如此之大的人口基数,为何就孕育不出一个能够震惊IT行业的项目?

    最近拜读了Martin Fowler blog中的《微服务》(链接文底会给出)其实架构的设计虽说给了我在工作上一定的帮助,当时更让我震惊的反而是一个貌似空洞,但是极有哲理的一句话:

    Products not projects

    Thoughtworks 作为全球顶尖的软件设计和定制公司,秉承着这位首席科学家的这种理念。团队在构建(需求分析,项目设计,项目实现,etc…)项目的时候,把项目当成产品去对待,即使只是项目的开发,在开发迭代过程中如果感觉到项目设计不合理,都可以直接提出,并且修改项目设计。一般来说,软件开发完毕,会经历测试,测试通过即交付。交付完成后,开发不再参与到软件的运维过程中。而Martin Fowler借鉴,亚马逊开发理念 you build, you run it.倡导一种devops模式。要求开发直接对软件的整个生命周期负责。致力于不仅能够在交付出满足用户需求的优秀软件,并且能够在软件交付后的运行的的表现,为用户增加更多的更贴近于用户的产品。而国内开发软件大多对软件生命周期内的各个时间段进行模块化,人员也模块化,所谓的一个萝卜一个坑模式。开发人员更是在完成自己的功能点后,认为大功告成,万事大吉。开发人员更是以功能模块为自己工作的全部。交付后,就被安排到其他的功能模块。虽然,这种模块化的模式下,产品交付速度得到提升。但是,对于整个产品的品质的提升,我个人认为是有害的。尤其是在产品本身体量很大,环节众多,耦合度较高的场景下,团队人员分工过于明确职责太过清晰,这种缺点体现的愈加明显。产品经理虽然能够清楚的把握整个项目的整体,但是缺乏对实现环境的把控,开发如果在实现的过程中只关注于功能点的完成,细节的地方得过且过,产品设计的初期过多的实现细节的忽略会在产品实现过程中被无限放大。导致最后产品的质量差,甚至不可用。

    Google的大型容器管理方案Kubernetes的前身Borg。在Google内部运行了10年之久,最后对Borg进行重新定义,开发并且开源。在漫长的运行过程中,该软件在进行着不断的重定义,甚至是重新设计。虽然Borg只是Google-GCE的内部使用软件。但是,Contributors仍然把它当作自己的产品在开发,维护,最终在容器时代掀起巨大的浪潮。国内软件虽然也有像Borg模式比如阿里的dubbo,在开源后,也已经不再继续迭代了。其他的公司,却忙于接新的外包又或者忙于开发新的产品,无法关注在一个项目上,做长做久,孕育出能够震惊世界的产品。

no comments
Share

发表评论