软件开发是很分裂的，只有不断使用原则和规律，才能带来质量。
识别项目开发中的MVP
只要不是玩具性质的项目，项目应该可以大概划分为0-1，1-10，10-100三种重要阶段。其中，0-1是验证性的，只能算一种Demo。而1-10则可以让产品初步达到可以第一次发布的阶段，最后10-100则需要对项目做持续的迭代，完善项目的完整功能。
可以假设做项目的人一开始总是只能设计并控制到0-1阶段部分的需求。也可以直接假设项目的1-10总是被忽略，许多项目已开始就从0奔向100，导致项目开发必然的出现某种程度的时间、人力成本的失控。
究其原因，大部分人很难切好一个产品的MVP，只有保持对风险的敏锐嗅觉，才有很强的动力去死命的切出一个产品真正的MVP部分，也就是如下的阴影部分。这部分应该足以支撑0-1，以及1-10在可控的时间、人力成本下完成可发布版本。
如果需求、人力和时间之间没有做好严格控制，大概率就会延期，并且无法形成项目的良性的短周期设计-开发-测试-发布-反馈循环。特别是，如果第1阶段阴影部分只是完成了Demo能力，然后就想着马上就能得到整个金字塔，那就是灾难的开始，可以等着求开发者的心里阴影面积了。
区分前端开发/客户端开发/后端开发/核心开发
前端开发，指只做过HTML、CSS、JavaScript以及具备使用在此基础上构建的各种Web类型的UI框架开发的能力，例如React、Vue、Elm等Web框架，同时对NodeJS生态下的Gulp、Webpack等打包工具链、有所熟悉。前端开发人员还需要对PC端网页渲染、移动端网页渲染，或响应式渲染有所熟悉。必要的，前端开发人员还需要熟悉微信开发、微信环境的H5开发、以及各种小程序的开发等。
客户端开发，指完整的开发过PC端程序、移动端（Android、iOS、或者ReactNative等跨平台开发框架）程序的开发人员。客户端开发要处理的复杂度指数比上述前端开发人员高。客户端开发一般也会对UI层、逻辑层、数据层分离的构架有所理解，并能主动做此分类。客户端开发也可能需要处理多线程、本地文件读写、网络通信、多进程构架等问题。
相对来说，一个前端开发的熟手可能对Web的各种框架和工具链有熟练上的优势能力。但是另一个方面，前端开发相对于客户端开发来说，可能对端内的分层构架没有什么意识，对常见的OOP封装也没有什么概念，因为他们大量的精力都消耗在了如何调整Web组件、如何做好样式、如何写交互上。因此他们对如何做分层、如何做封装、如何做规约的经验增长的比较慢。
后台开发，需要掌握Linux上的各种基本命令，并以此为基础掌握这些系列的能力：网关配置，例如nginx，需要熟悉网关的服务路由配置策略、反向代理策略等；静态路由导向静态网站，反向代理则可能导向内部的Web服务，例如Java、NodeJs等内部起的Web服务；Web服务背后可能就是一系列Rest接口的实现或者RPC接口的实现；进一步背后可能有缓存层、数据库CRUD读写层。但这只是最基本的形式，后台构架会一步步演化，演化到最后又会变成开发人员只需要写业务代码，通过工具链一件部署等。
实际上后台这部分混合着基础组件的开发和业务逻辑的开发。业务逻辑层面的技术需求和基础组件的技术需求并不相同。基础组件部分，需要的是做云资源的资源抽象、虚拟化组件的掌握、调度、消息中间件等等分布式组件的技术，而面向业务，最常规的来说就是要对缓存、数据库的设计有良好的把握，以及一条完整业务流程全过程中，所有端的时序、事件、数据流的把握。
最后一个是核心开发。其实核心两个字具有骗人的作用，好像其他开发都显得无足轻重，其实不然。核心开发一般是指开发某种Kill级别的底层技术，例如Google的QUIC网络协议设计和开发、一种满足特定需求的存储系统/数据库、一个车辆识别系统等等。
理解和区别这些不同类型的开发，对于一个项目的人员安排和调度是必要的。我深刻理解到一个项目的延期时间基本上是由耗时最长的那个端决定的。能不能某些端放的人靠谱，某些端放的人不靠谱呢？有风险。基本上来说，要想做出高质量的项目，就需要在合适的端放上合适的人。如果人上面没有办法满足，意味着那个人在那个端上没办法独立Hold住一面，这个时候就一定要在整体上对那个端有一个经过设计的构架，把风险规约到构架里面，我想构架的作用在这个时候就会本质的显露出来必要性，而不是装饰性。
全栈是一个谎言，双拳难敌四手，TeamWork不应该是一个人把所有的事情都做了，这是不对的。好的软件开发过程，如果出现了一个人做了过多角色工作，一定是这个软件过程的警告信号，不是什么好事。
开发平台/私有部署/面向企业/面向个人
一项技术，实现出来，可以做成开发平台。但是如果开发平台没有某种方面的优势，例如成本优势、开发难度优势、适用范围广的优势、开发者信任优势。那么可能最后也没有办法基于这个平台形成生态和市场，不能形成生态和市场，意味着这上面没有好的商业模式。简单说，技术不错，但是赚不到钱。
那么，也许这个时候，需要的是把开发平台改成客户可以私有部署的产品。私有部署实际上需要更有质量的开发，内部的所有部署都要做成可分发的能力，需要把更多内置的组件做成软的，可配置或者可更新。私有部署更容易把技术售卖出去，这是从人对购买事物的信任上考虑的。
面向企业做产品和面向个人做产品差别很大。面向企业开发，要有很好的服务能力，这方面只有一些模糊的感觉。
估算时间依然是很难的
如果一个技术从来没做过，估计时间依然是很难的，有好多次我回答不出来“这个功能大概要多久”。因为问问题的人不需要去把东西做出来，而回答问题的人需要去把东西做出来。做出来是要消耗时间去摸索、验证、实现、测试、再解决各种错误处理，有很多假设和条件可能是不对的，需要翻掉重来的。只有做过1-2次的才能给出一个估计时间，但是，人们总是低估存在的问题，所以翻一倍时间都是常见的事。
把东西做出来的价值在哪呢？如果是一个科学研究，一个研究者把一个东西做出来，他会获得同行的赞赏和尊敬。但是开发活动常常是做了就做了，因为人们只关心结果，不关心过程中谁解决了什么问题。原因是，马上就有下一个新问题。已经解决的活在软件本身中。
这就是再次回到了经典的问题：“在一个开发周期中，要拒绝不在周期计划内的任务”，不坚持这个原则，就是一切混乱的开始。我发现，好的软件过程，都是因为坚持了原则，而不坚持原则，都必然会出现问题。然而，很多时候你没的选择，比如某个端就是没有靠谱的人负责，你就只能曲线救国，很多时候效果就是会打折扣；比如，人们就是要塞变化的需求，或者就是需求被低估了，或者根本不知道需求。不过本来很多事情就没有什么合理不合理，遇到了算倒霉，增长的经验用在下一次即可。
好的软件过程，要坚持用燃尽图，坚持用Issue管理。
--end--