关键词：Java 应用、架构提炼、技术沉淀、通用技能
一、想法的萌芽
写了这么多年代码，经历了太多从 0 到 1 的应用技术项目，这种重复性的行为，不禁也让我感叹，工作到底是正弦函数，往复循环；还是一次性函数，日日精进......
在一个不经意的瞬间，内心深处萌发了一颗种子。 它告诉自己，你应该从大局、宏观的角度， 做一个深度的提炼； 将这些经典，可参考的、可复用的，不管是思想、还是方法，做一个沉淀。
二、架构的理解
在软件行业这么多年，时不时被问到，什么是架构?
今天我想用不一样的想法来阐释这个词： 用经验搭建出一套非常牢固的架子。
图示：就像建筑房屋一样，需要先搭建牢固的整体结构
经验是什么： 经得起推敲、经得起考验的场景解决方案，干脆就叫它“套路”。踩过坑、有最佳路径。可谓是“老马识途”。将我们做过的这些项目进行总结归纳，为下一个项目提供参考，这就是经验！
牢固是什么：经典起推敲，并能够在一定的生命周期内屹立不倒。
架子是什么：最终的形状，架子就是骨架，是结构，也即软件的核心， 架子有了，软件就基本成型了。
图示：在架构搭建好的基础上，再填充各种装饰细节，就形成了不同的漂亮房子。
不可否认，软件项目就跟建房屋是一样的，每建一栋房子和每开发一个项目软件，它们都有相似的项目流程，包括设计、落地，整个生命周期管理。 开发软件就像是一堆人拿着施工图纸，夜以继日地添砖加瓦。
不管是建房还是开发软件，都会沉淀出它们各自的方法论；同时也一样会沉淀很多经验，以及避坑指南。
今天就尝试去扒开那些软件外衣下不变的东西。就像下图一样，褪去叶子后的枝干。
三、软件开发环节
软件开发有很多环节，有一些点可以讨论一下。
3.1 正确把握需求
对于开发同学，是否需要做需求分析
当然那是产品经理要干的事情，可以不用，但一定要做需求理解，并对提出需求的合理性分析。
因为缺乏经验和专业度，也常常因为考虑不周提出了一些不合理的需求，研发同学不假思索地照着原型开干，做着做着才发现需求不合理。
需求阶段的职责缺失，造成资源的浪费！
那有没有破解之法呢？
战略上：透过现象看本质，抓住需求背后的本质
战术上：用例图。或者用例图驱动
3.2.1 用例驱动
用例图： 是软件工程中的一种可视化表示方法，用于描述系统角色与系统本身之间的交互。它通过说明用例和与用例交互的角色来捕捉系统的动态行为。
之所以会出现一些坑，其实是缺少把需求脉络理清楚的环节。 而用例图刚好是一个不错的工具。 软件的价值是通过用户的使用过程体现的。
理清脉络的公式： 【谁】 用了系统什么 【功能】做什么【事情】达到了什么【效果】。
| 谁 | 系统的角色 |
|---|---|
| 功能 | 系统的功能 |
| 事情 | 系统通过功能提供的能力 |
| 效果 | 系统的价值 |
比如以电商商品搜索为例子。
购买者会员，用例系统的搜索功能，搜寻特定的电子品牌，得到了想要的信息。
这是让我对需求理解不走偏的一个方法论。
这种方式不是将用户和功能做分开，而是结合。研发人员常常会存在一个误区，我开发了这么流弊的功能，但是为什么他们不去使用呢？
3.3.2 先有功能还是先有用户
先前有过一次失败的经历，搞了个运维预警的系统，最后没有人愿意去使用它。 后来复盘提到了一个问题。先有功能 VS 还是先有用户
1.是先把功能都开发完成，然后去寻找用户
2.还是先有用户，根据用户需求再去开发功能
几乎大部分人都认为该选择 2 。 但是实际很多开发却在干着1 。 如果不确定，我这样去描述你可能会有感触一些。
研发人员A：按照【原型】设计模型，设计功能，然后实现。
研发人员B：将用户和【原型】结合，分析能够提供什么能力，然后实现。
一种是功能，一种是能力。可能系统都能顺利上线，但是实现的过程的思维方式是不一样的。一味的堆砌功能，不贴着用户走，那么黏性就会不足。
通过用例图的思想，将功能和用户结合去看待系统，防止走偏、走错。通过这种方式，可以提前发现需求是否合理，是否需要返工等。当然这不是唯一的方式，但是一种可行的方式。
想清楚比一上来就干，然后发现不合理再返工要好不止十倍。当然这也是我的口头禅：“别急，先想清楚再干，想清楚了再干其实是简单。”
3.2 如何快速理解系统
我刚毕业的那会，我的导师告诉我一个法门。 理解一个理解最快的方式就了解它的功能权限和数据权限。当然这个经验在后来的经历中也是屡试不爽。
理解一个系统最快的方式就是：理解它的功能权限和数据权限。
当然我们对于权限系统，每一个系统可能都不一样。这一点务必要注意。不过常规的系统都是基于 RBAC 演变的。
思想都是：什么样的人能够看到什么样的功能以及什么样的数据。
如果不理解权限，始终还是门外汉，甚至会因为开发某个功能没有考虑权限而翻车！
3.3 软件开发的焦油坑
"表面上看起来好像没有任何一个单独的问题可以导致问题，每个问答题都能获得解决，但是当他们相互纠缠和累积在一起的时候。团队的行动就会变得越来越慢" --人月神话
图：来自人月神话
如何不让自己的应用成为焦油坑? 直到我遇到一个系统
这个系统，大约二十个人开发；常见的开发分支大约20个；线上应用机器接近百台。 接到了一个需求，并要在这个应用上做需求开发。 初看代码发现很逻辑很绕，但跳出细节，梳理骨干却又很简单，也很美观。 “骨干是美人坯，细节是凡人像”
认真比对以后，我发现很多有趣的事。这个系统之所以能够做得不错，有它自己的特点。概括为几个点：
问：你认为团队一起开发在技术落地中最重要的是什么?
答：规范或者统一
四、本章结尾
本文作为 无数0到1项目的技术感想 系列的开篇，限于篇幅，先到这里。但后续会继续输出这些年的一些思考，算是对这几年的一个总结和沉淀。
感谢阅读，本章结束。
