本文是笔者对于技术规划的一些思考沉淀。如果这篇文章能帮助你入门技术规划，那自然是最好的，同时，正所谓教是最好的学，这也侧面了证明笔者已经掌握了技术规划的能力哈哈。
软件系统技术规划，顾名思义，就是对软件系统做一些技术侧的规划，分三块描述：
往大了说桌面端的PC软件，Web端的网页、移动端的APP等等都是软件系统，往小了说，一个服务，一个模块，一个组件，一个小工具也属于软件系统的范畴。任何一个软件系统都是可以做技术规划的，一方面世界上不存在完美的系统，总会有这样或那样的问题，把这些问题归因分类下，我们就可以做规划了；另一方面，世间万事万物总是向前发展的，即使现在的系统真的很完美，我们仍然可以思考系统未来的发展方向，并针对这个方向做一些技术探索甚至创新颠覆，这也是规划的一种。
技术侧是相对于业务侧来说的，本文虽然专注于技术视角，但是我们也要知道，技术和业务是相辅相成的，不能孤立的看待两者，有了业务的发展才有技术的用武之地，有了技术的支撑业务才能更好得发展，因此做技术规划的过程是绕不开业务话题的。
根据规划-百度百科的定义，
规划，是个人或组织制定的比较全面长远的发展计划，是对未来整体性、长期性、基本性问题的思考和考量，设计未来整套行动的方案
按我个人理解，主要有两个关键点：
方案，是用来解决问题的措施，因此方案既要明确问题是什么，同时要避免假大空，要避免空中楼阁，要细化到怎么解决问题，或者说细化到解决问题的具体步骤。
规划即方案，说的是规划也要满足上述针对方案的论断，这点毋庸置疑。同时，规划相对于方案来说，首先侧重于解决基本性问题而不是一个两个BUG，其次正所谓不谋万世者，不足谋一时，不谋全局者，不足谋一域，好的规划需要从局部视角切换到全局视角，需要以一种较为全面整体的视角来出方案。
规划主要是面向未来的，但是要想展望未来必先立足当下。对于一个软件系统而言，需要对系统的现状甚至过去的演进有一个足够的了解后，才能做出比较好的规划。
规划需要面向多久的未来呢？一般情况下是3-12个月，时间太短了赶着落地可能会出一大堆Bug，而且谁也不想天天活在Dealine的恐惧中；太长了也不好，正所谓计划赶不上变化，万一出现了一些意外情况导致结果不及预期，那么船小还能掉头。
规划需要落地执行，简单来讲就是排期，在某个时间节点完成某项功能。
事事都离不开规划，大到国家，有五年规划，小到个人，有人生规划和职业规划等。做规划在我理解最大的好处是，有了目标和方向感，有了目标和方向感就不会迷茫并且能正确发力，精力只有用到正确的地方才能起到事半功倍的作用。
具体到软件系统技术规划也是一样的道理，有了规划我们才能稳扎稳打的做出对用户更友好的系统，甚至成为业界标杆；当然，还有一个更现实的原因，对于一个程序员而言，如果不掌握规划能力的话，那么是无法进一步往上发展的，它是我们迈向资深程序员的必备技能。
收集资料贯穿整个技术规划的始终，只有足够的输入才能有输出，资料包括但不限于代码、以前的规划文档、技术方案、接入文档等等
从两个方案入手梳理现状：
我们可以实际从头开始体验系统，了解系统有哪些角色，代入这些角色实际操作一把系统，并最终沉淀一份接入文档。
体验系统的过程中我们可以抓包、查日志、看代码等方式梳理系统的架构和链路，最起码总结出以下两张图：
有两种方法可以推测系统的未来：
我们可以去做竞品调研，了解司内司外同类系统是怎么做的，并整理归纳下，对比我们的系统就知道未来需要做什么了。
但是如果竞品系统没有值得借鉴的地方怎么办呢？那我们可以从本质出发，思考系统的本质是什么，为谁服务，基于此进行逻辑推理与演化思考，从而推导出系统的未来理想态，就如同本文最开始从规划是什么的定义出发，带出了怎么做规划的方法论。
什么是问题呢？现实和理想的差距就是问题。前文梳理现状和预测未来提出理想态如果已经搞清楚了，那么发现问题自然不在话下，具体而言，可以从以下几个方面总结问题
针对一个问题，我们需要提出至少3个解决方案，并总结每个方案的优缺点，再进行对比选型，最后，针对选型出的方案总结出两张图：
方案出来了，剩下的就是排期落地，其实就是列出Todo项，根据优先级排序，并一项项得完成之。
对于资深程序员而言，IDE是必不可少的，它好比是剑客手中的宝剑，IDE帮助程序员更快更丝滑的去编程，同时插件就是这把剑上的各种Buff，为宝剑赋能，提供更好的升级打怪体验。
Java又要完了，又要没了，你没看错，10月编程语言榜单出炉，Java跌出前三，并且即将被C#超越，很多资深人士预测只需两个月，Java就会跌出前五。看到这样的文章，作为一名Java工程师我感到……
IntelliJ IDEA的远程开发功能，可以将编译和运行等消耗资源任务放在服务器上执行，降低本地电脑负载，但是体验上和之前的IDEA操作保持一致，破旧的老机器也能焕发青春