任务工程化，数据结构化，服务平台化，业务流程化
在日常的软件开发中，尤其是国内的职场环境，过于追求高效率和所谓的“敏捷开发”，在“没有学会”的情况下，“敏捷开发”导致了很多人为的灾难。这里我将“没有学会敏捷开发”带来扎心的后果的开发模式戏称“过敏式开发”，一味的追求“敏捷”最终带来的后果像皮肤过敏一样体验，时不时这里抓一下哪里挠一下，关键是挠完不一定“止痒”。于是就有了：“敏捷开发”就像皮肤过敏一样，你永远不知道下一次会挠在哪里！
这一点在小公司里尤为明显，通常情况下项目无法按时交付或者项目质量很差，每个参与者都能说出一大堆原因，单独看每一个原因都觉得很有道理。假如你让每个提出问题的人尝试给出一个对应的解决方法，那么你会得到一些针对性强、较为青涩的解决方法，作为一个致力于解决这一现状的人，你需要让这些解决方法“发酵”一下。每个深陷其中的人更多看到的是与自己相关的问题，缺乏全局分析问题的高度。不能只是腿坏治腿，手坏治手。出现这种问题的根本原因在于没有“设计”，没有完善的顶层设计、没有个性化的针对性设计、最重要的是没有时间设计。在没有设计的情况下开工就是砍柴不磨刀，再好的樵夫对质量和效率都无济于事。以下我将基于实际经验的思考做一点总结，纯属个人观点，有限的数据支持，有纰漏请指正！
1.任务工程化
为什么我会将软件工程中的进度和质量问题用：任务工程化，数据结构化，服务平台化，业务流程化。来总结呢？首先解释一下我所谓的“任务”的概念，任务我们可以理解为现实需求到信息化的过程，任务可以很大也可以很小，例如：将数据集合甲对应集合乙做运算得到结果。那什么叫“工程化”呢？工程就意味着：规范、规模、影响力的范围大。在软件工程中与之相对立的我认为是“脚本化”，脚本就是：针对性强、注重处理流程、影响力范围小。在现实工作中，我们有很多的大任务都是以脚本的思路来完成的，这样会造成本应该悉心设计的地方用最具象的代码去实现。好处是当时能奏效，一旦需求频繁发生变化时，你的"script"就应该翻译成“草稿”。说回解决方法，工程化可以用WEB中前端工程化以前和以后举例，前端工程化以前html、css、js都只是在前端工程师写完页面那一刻是完美的，经过后端工程师一顿模板渲染后语法看起来乱七八糟，而且前端工程师代码片段的复用成本高。当前端工程化以后，前后端分离，前端代码前端组件化，复用成本变低，二次开发变得简单。这里举例可能有不恰当的地方，但我想表达的是工程化是规范的、能应对大规模的需求、能够承担很大的责任与实现更复杂的功能而不至于身陷泥潭无法自拔。总结一下，任务先分析大小和影响力的规模，选择是否工程化和脚本化，这样不至于身陷泥潭。
2.数据结构化
众所周知，数据结构是算法的基石，算法是程序员的孙子兵法。大家都会强调算法的重要性，但我看过这样一个观点：算法是程序的核心，但在一个蹩脚的数据结构之上再精妙绝伦的算法也会大打折扣。这样的一个观点当然是我浓缩的，原来的文章内容我已经忘记了，但他要说明的是：在强调算法重要性的之前，一定是选择合理科学的数据结构，不能只针对局部而忽略全局。
我记得我们之前有一个任务是这样的：从医院IT部门以规定的Excel格式的形式收集数据，然而录入系统展示并提供在提系统上修改的任务。然后这个任务最后出现哪些状况呢？①Excel数据内容混乱，各种数据缺省，需要人工校准和脚本校对； ②设计了一个不合理的mongodb的数据结构，导致更新时的目标路径由数据内容拼接，因此不得不写一个语法生成引擎。在这个任务的初期我并没有参与，等到我参与的时候才发现做了大量不合理的工作，项目交付截至日期正在靠近，我没有足够充分的理由和足够高效率的新方案游说我的领导返工。最终是能硬着头皮写校对脚本，辅助Excel数据入库，然后调试一个本可以不写的语法生成引擎。这一次的经历，我马后炮的总结是：①往后收集数据并且要在系统中增、删、改、查的任务，确定好Excel的格式后直接开发这一部分功能作为数据收集系统。第一个是保证数据的准确有效，第二个是可以直接移植到最终的系统中； ②往后mongodb的文档结构设计的时候坚决不要用带有业务实际意义的参数文档的key，第一个是为了文档足够抽象，第二个是为了避免写语法生成引擎（当然这是一个乍一看挺不错的程序，但实际真没有必要）。这个案例是从程序和软件工程的角度来分析它的影响，因为数据结构的设计不合理而带来的额外工作，导致项目进度有很大的影响。单从程序的角度来说，更好的案例佐证应该是不合理的数据结构对不稳定算法的时间/空间复杂度和整体程序性能的影响。
3.服务平台化
我们作为小公司的开发人员，过去我们也对市场主流的技术栈和平台都做过靠拢的计划，但在实际的开发过程中一直日复一日的做琐碎的事情，我将其戏称为“织毛衣”。不是我们没有理想，也不是我们迂腐。过去工作中建立的技术理念无法转化为实际的项目，我觉得这个责任在于领导层对业务、项目以及公司定位的认知问题。嘴上全是主义，心里全是生意。业务固然是需要及时推进的，但作为领导层应该有更多的思考，羸弱的生产力高强度的人工“织毛衣”，又何谈开发团队能够创造性的研发强大的PaaS（Platform-as-a-Service[平台即服务]）对专业领域的业务支持呢？
前段时间我们公司与一个做医疗管理的上市公司有战略合作，在这个过程中对方公司的一个的副总（做架构出身而且还能跨医疗管理学科）与我们开发人员有过一些交流，整体下来的感受是：之所以别的公司能够做更多的业务，完全取决于他们把所有的服务做成平台，理论上平台可以给无限个项目赋能。当然这一切都是基于财力雄厚的基础之上，在交流的过程当中还有一点的感受就是：越是没时间、没有机会做架构设计，越是要做架构设计。这个总结听起来像毒鸡汤，就像机会永远是留给有准备的人！实际对于没有准备的人那只被上了一课而已！
到此我总结一下应该如何避免“织毛衣”，站在技术管理者的角度或者说公司CTO的角度。公司一定要设计技术架构的蓝图，把我们的在某个领域即将做的很多的事儿都考虑进来，留出一部分时间用来思考将服务做成平台（PaaS或者说为中台提供基础服务的平台），只有我们服务平台化才能将我们的项目经验结晶为一种技术资产，这种资产不仅可以整合为各类中台也能作为服务给其他企业提供赋能并实现盈利。
4.业务流程化
在过去我的一些同事们经常会陷入一种状况：数据细节经常由方法学团队（决定产品核心的业务逻辑的同事们）直接找到后端或者前端要求修改数据结构以达到要求，或者经常性在ddl（deadline，截止日期）快到的时候最终拍板。这样的一些状况根本上就是混沌的，完全没有流程可言，对于开发团队来讲是不可接受不可理喻的。当然我们也应该理解方法学其中苦衷，大家应该一起以解决问题为首要目的，有流程上、制度上的问题我们也不能够忽视。
在我经历的小公司中大部分在制度和流程上都是不够完善，所有的管理公司的条例都写在一个类似于软件的√我已知晓并同意的员工手册中。然后无论是否合理都不会轻易的在改变，甚至会不停的追加条例。我听说过这么一个理论：制度管人，流程管事。被限制的不应该是人，而是要做的事，要做的事不按流程来，遇到麻烦事就跳过流程直接上手改东西，短期有利长期有弊。这里我又联想到了罗翔老师说的：“对于私权而言，只要法律没有禁止的，就是我们的权力，对于公权而言，只要法律没有授权的就是被禁止的”。类比到这里：对于制度没有限制的，人就可以去行使权力；对于流程没有授权的，就不能发挥想象力去做事。还有更实际的情况，由于我们做的To G（government）类型的项目，在这个过程中姿态事很低的。经常系统上明明又提供的功能，对方会给到一个Excel让更新系统的数据，类似于这种事情太多了。如果我们做的是To B（business，商业公司），只要我们的产品是足够有价值的都不会那么低的姿态，甚至可以用我们的流程去规定这个对接的过程。无论怎样，规范的流程化对公司内部的管理是短期有弊长期有利的事情。
总结
就像简介里面写的一样，这个世界的本质就是混乱的，为了提高效率我们就必须要与这种本质的混乱作斗争。我所说的一定不是完全正确的，但都是我基于实践得到的反馈总结出的结论，我会一直去检验我得到的经验的适用率，并不断的去充实和完善它。讲了这么多，我最终要表达的是：我们应该站在全局去思考问题，分析问题的矛盾点，分清楚矛盾的主次，看透问题的本质，底层逻辑清晰处理大部分情况都不会没有头绪。还有一个观点：站在公司的角度去思考问题，我们能够提供的最大的价值是什么？如何利用有限的资源，去创造无限的可能性，虽然最终的转换结果是有限的，但可能性是无限的！这个看起来有点像pua（精神控制），但我认为这是我自己的追求，跟老板画不画饼没有关系，一旦我的目标实现了或者是老板无法为我提供实现目标的平台，那你说什么都无济于事。
