为什么我选择重开博客？

上一次写博客的时候，我已经忘了是多久之前的。我印象中以前博客还是用来记录一些小技巧、记录摄影（其实只是胡乱拍拍）的点滴的。有了微博和朋友圈之后，基本上就转发到那里了，而且那里的受众还特别好（特别是微信，基于熟人社交嘛），价值观输出强烈。

但是感觉朋友圈更多是为了方便被转发、方便手机查看而设的，文章的专业性，尤其是对于技术人员想要上传代码到文章里面显得困难。这是功能上的原因，我觉得专业的技术资料还是应该留在专业的博客里面。在思想上，我觉得一直以来我自己积累下来的知识都没有一个整理的过程，我希望通过一个博客用更有条理的方式整理下来。

写博客最怕是没有时间维护。在写下这句话的时候，我正处于失业的状态中，算是比在上班的日子有更多的时间进行博客编写了。虽说我可以立刻去找一份工作，但是我还是觉得想要任性一次，先做一次从业以来都没有做过的技术沉淀。

我感觉入行以来，就软件开发技术而言我已经更新了三轮。第一轮是我从.NET C#开发C/S软件开始（这个S是指直接连接数据库），转到C#通过连接接口的方式（包括RPC调用、WCF调用和WebService调用）与服务端进行交互，客户端开发从C# Windows Form到ASP.NET再到WPF。第二轮是从.NET C#转到Java平台开发为主，从ASP.NET B/S开发模式转移到Java平台的前后端分离的Web开发、从单个服务端到分布式高可用高性能架构。第三轮是从互联网常用的分布式架构转移到我自认为更适应O2O行业的基于云服务的可伸缩架构。

在这三轮技术更新的过程中，企业通过软件盈利的模式也在发生变化。最开始是直接以软件项目合同的方式进行盈利。然后我加入到更高层次的企业，通过开发产品附带高附加值的软件，靠提升产品议价能力盈利。最后演变成目前以软件即服务的形式，目前的O2O基本上都是以这种方式，软件属于服务的一部分，通过线下服务和线上平台对企业和产品造成的估值溢价而盈利。我们从中学就开始学习了，生产力和生产关系其实应该是相互促进的关系。我目前在从事O2O软件开发为主的工作，而O2O的生产关系，我认为与我第二次更新技术后，主要从事的分布式高性能高可用架构还是有所不同的。换句话说，我觉得目前的生产关系（互联网+，尤其是中小企业要做O2O），反过来对生产力有不一样的要求，这是我想要把自己积累的东西对外公布、对外发声的重要技术原因。

我比较认同Ruby语言作者，日本的松本行弘先生的观点：未来的软件研发发展的方向应该是提高敏捷性、高度可定制化、通过提高机器的开销而节省开发人员花销的。这观点与当前国内互联网行业——偏爱重复制造车轮、多数公司为提高生产力首先考虑雇佣更多的开发人员和给开发人员开更高的待遇，是有明显的方向性差别的。尤其是对中小型企业而言，中小型企业首先融资困难，雇佣更多开发人员和给开发人员开出溢价的待遇是比较困难的。但在互联网+的趋势之下，IT已经越来越难以决定企业和产品的成败，它沦为了一种基础设施——没有不行，但是做得最好可能只是60分。尤其是对O2O来说，决定产品成败很重要的因素，是线下服务质量水平，线上IT平台只要能满足业务需要，技术上各种指标没有与主流软件形成明显差距，就可以初步满足中小型企业需要了。

知乎上有个比较火的讨论是：计算机业还能再火几年。其实楼主的意思应该是程序员就业还能再火几年。主要的高赞成答案不在这列了，不过其中有很多的答案我都觉得有意思，有一个是说目前的信息化程度还是严重偏低的，所以未来必须需要更多的程序员实现社会各行各业更高程度的信息化。而即便是目前信息化程度不高，但对程序员的需求也已经这么高了，那么日后对程序员的需求更高的情况下，程序员的稀缺程度会进一步加剧，而且大陆程序员的待遇会在一段长时间内保持缓慢增长逐渐追上欧美程序员的薪酬水平。即使我觉得目前的程序员收入仍然不足以回馈他们的工作水平，但对于企业来说，绝大多数的企业没有直接销售软件的能力，软件或IT平台的盈利需要通过提供非IT产品和服务的形式产生，盈利能力是否能够不断跟得上软件平台的成本增长呢？我认为目前已经成为了一个问题了。

回到上面松本先生的观点，其实就是通过提高软件开发的生产力、使用低成本的资源，降低IT平台的总成本。这里指的不是程序员工资降低，我一直都赞成程序员加薪，但程序员的薪酬毫无疑问是IT平台的绝大部分。我举个例，是我曾经工作过的一个项目组的情况，我来说明一下如何在不降薪的情况下降低整个平台的开销。先列出这个APP的人员总编制：

• 13个Java后端开发人员（包含架构师、开发经理）
• 6个Web开发人员
• 7个iOS开发人员
• 7个Android开发人员
• 3个运维工程师
• 8个测试人员

测试人员我们先不讨论，因为即便是目前顶尖的软件公司，仍然需要足够的测试人员进行黑盒测试以保证功能稳定，我们先讨论其他的36个人员。这里暂时没有讨论产品经理的功能输出，就以一个大版本周期需要完成150个功能点计算。

第一个大版本，首先13个Java开发人员需要做这么一套框架：

• 第一个模板之用的Maven项目，需要封装基础的HTTP REST接口操作、引用必须的Jar包，调用分布式RPC框架（Dubbo/DubboX等）
• 若干个基础项目，封装Quartz或者Crontab访问，进行定时任务触发；封装RabbitMQ或者ActiveMQ消息队列的接收和发送、封装短信和极光推送等
• 搭建NginX反向代理和负载均衡，控制生产线的IP黑白名单
• 数据库需要使用MyCat搭建分布式MySQL集群
• 需要搭建FastDFS用于文件上传

有一部分工作是运维人员协助完成的。运维人员还需要搭建Zabbix监控系统、Elastic Search+LogStash+Kibana的日志收集与查询系统，维护生产线、测试线、开发线等多套不同环境等。

第二个大版本，开发第151-300个功能点。这时候APP主界面上面九宫格已经有9个不同的业务了。13个Java后端开发人员需要做的是把每个单独的业务都进行单独的逻辑设计——分库分表、不同的业务逻辑设计在不同的数据库上，不同的业务相互之间不可以使用JOIN。如果确实是需要使用JOIN的情况，临时解决方法是直接使用MyCat的特性跨数据库查询，更好的解决方案是通过数据同步机制，把数据高速同步到不同的逻辑数据库上。

如果有比较了解的同行看了上面的描述，可能会明白为什么需要这么做，而且做了这些事情对于3个月内必须上线完这300个功能点，但还需要从零开始开发基础业务模块——用户、权限、基础数据等，这13个后端开发人员+运维人员是多么的吃紧。比较资深的同行应该会明白，这软件使用的是高性能高可用性分布式架构，优点就不在这阐述了。

这个APP编制已经达到了40个人左右的规模，算是一个中型团队了，但是在日后的迭代中，都受到了以上的开发框架的制约，新需求和旧的Bug修改越来越慢。尤其是后端开发越发吃紧，不但无法缩减人数，还需要增加编制才能满足每个月大概80个新功能点的增加。而这个技术团队按照广州的市场价粗略估算，每个人税前工资+五险一金，平均需要25万人民币一个人，按照40个人的规模估算，一年薪资的开销需要1000万人民币，3个月也起码需要300万的投入，而一个APP保守估计运营时间也得在一年以上。而且这些预算还没包括产品经理和调研需求的投入、运营团队和推广费用的投入。 

对于传统的中小企业来说，软件平台一年的开支超过150万以上，就会觉得非常难以承受了，尤其是收益可能来得很慢，甚至是没有直接收益。于是对于以推广为主的某些企业，直接使用了微信公众号的形式发布信息，节省了100%的开发投入。部分有更高要求的企业，购买了第三方开发的微信运营软件，打通微信公众号的API，一年一两万元的软件使用费就能够轻松搭建一个满足70%左右需求的微网站。

但这些事我只是为了说明企业难以承受一定规模的开发团队的支出所以采取的一些变通办法。决策人完全不懂技术，不懂得评估使用这些方法拼凑而来的解决方案，在数据的积累上、业务的扩展性上可能存在的短板吗？未必不知道，但是按照以上的开发方式（几乎成为了每个大型互联网企业的技术团队的标配）实在成本太高，只是不知道有没有更好的渐进式投入而已。

而这就是我想要做自己的技术积累并且公布发声的目的之一，我想要归纳出一种未必是高技术，但是是更加容易为企业接受的一种开发方式，更好地适应中小企业尤其是目前尚未进入互联网+的企业的需求。

当然，这仅是我一家之言。最近有朋友和某些渠道联系我工作，沟通后也有发现一些企业决策人不同意我以上的观点的。不过如果说我在个人简历里面要挑出一个相对有优势的地方，我觉得只能是“擅长中小型产品从无到有的开拓性过程”，大型分布式高可用高性能架构，继续留给其他同行去写吧。