任务分解与函数拆分以及面向未来编程的思想分享
一、背景
本文可能和很多人想的不一样，没有那么高深莫测，但是可能很实用，可能更容易避免出错。
业务开发中很多人可能面临这种情况：
1、任务每次都延期，任务时间并没有通过拆分后单个评估，而是全凭拍脑袋
2、很多函数超过80行，大的意群没空行，没拆分出子函数，导致别人阅读你的代码非常痛苦
3、写代码没有灵活性，比如加了缓存的功能，后面需要拿掉，还得重新修改代码发布等。
4、到上线了发现经常担心遗漏一些配置啥的
本文先介绍任务分解和函数拆分的概念和联系，然后简单介绍一下面向未来编程的习惯。
我这里指的 “面向未来编程”是指写代码的时候要适当考虑未来的修改。
二、探讨
2.1 任务分解
极客时间《10x程序员工作法》
大多数人对于可执行的粒度认识是不足的，低估了任务分解的程度，做到好的分解你需要达到“微操作”的程度。有了分解得很小的任务，我们就可以很容易完成一个开发循环，也就让计划调整成为了可能。软件行业在倡导拥抱变化，而任务分解是拥抱变化的前提。
动手做一个工作之前，请先对它进行任务分解
有些公司提供一套完整的效率平台，包括任务的状态，项目中每个人的拆分，项目涉及的文档等等。
开发前需要对任务进行分解并且估时。
任务拆分的合理，预估的时间相对就准确，对风险的把控能力就强，如果额外加入了几个小时的紧急事情，那么比预计晚多久就相对容易评估出来。
任务分解使任务变得更容易执行，并且时间更容易评估，可以非常清晰的了解当前任务的执行进度，剩余时间。
建议大家可以借鉴类似的思想来做项目。
另外估时可以适当预留单测的时间，预留应对突然事件的时间，极少数情况会开发的这段时间不需要处理任何紧急插入的其他事务。
如果公司没有提供工具的话，可以考虑trello
或者teambition
甚至也可以在有道云笔记里，创建待办来实现。
2.2 函数拆分
很多人喜欢把所有代码写到一起，导致一个函数可能好几百行，如果其他人修改你的代码，极其痛苦。
而且自己时间久了需要修改的时候，如果注释还不够完善，自己也会浪费很多时间，而且也极容易理解错误。
《阿里巴巴Java开发手册》中建议一个函数的代码长度不要超过80行。
为了更好的编写业务函数，我们应该把业务函数拆分成几个逻辑单元，比如参数检查，查询，数据组装等。
不同逻辑边界加上空格，部分大块功能建议抽取到私有的子函数中。这样代码的可读性更高。
比如我们对concurrentGet代码重构，其参数和返回值明确，逻辑清晰，极容易重构，也极容易测试。
2.3 面向未来编程
即编程时要有灵活性，要面向未来可能出现的一些（不是所有）情况。
2.3.1 比如开发一个缓存功能
为了避免上线后缓存出问题可以及时拿掉，为了测试环境测试不走缓存，可以设置缓存开关。
通过apollo配置，这样不需要代码修改和上线可以实现某个功能（不只是缓存）的开关。
2.3.3 比如某个模块本来应该独立成子函数
未来注定要通过其他方式替换掉的，建议独立写一个子函数，未来只需要替换这个函数就好了。
如果写到一个大的业务代码中，需要理解上下文，这样修改的难度就很大了。
比如这里 我们替换了第三部分，参数返回值可以不变，只修改逻辑就好了。
2.3.3 比如调用二方接口
返回值类型是Map
假如二方接口对数据使用使用JSON序列化到Redis里，然后取出来Long被转成Integer，如果我们通过get获取Object进行强转，如图所示，含Long类型的数据的map，第二次请求走缓存，会出错。
但是如果我们也缓存了我们的最终结果，那么这个反序列化错误可能一直被隐藏着。
《JSON序列化导致Long类型被搞成Integer经典巨坑》https://blog.csdn.net/w605283073/article/details/90941038
面向未来编程，决定了我们要意识到虽然测试环境数据正确，不代表未来不会变化，怎样更好的应对变化是关键。
2.3.4 面向未来记笔记，很重要！
比如你新开发一个功能，涉及到某个配置的改动，涉及到SQL的修改，需要依赖的其他服务先上线，上线后需要配置XXX等等情况。
都可以在开发的时候记录到云笔记的“上线” 文件夹的“注意事项”等笔记中。
这样极大避免了上线前抓耳挠腮的去检查思考自己的变动，需要的配置，依赖的服务等等。
当然上线前还是要重新思考的，但是极大减轻了工作量，极大避免了遗漏出错。
开发阶段可以记录未来测试阶段需要注意的事项。
甚至需求评审阶段，就可以用笔记整理思路，甚至预先设想技术方案等。
功能测试阶段可以在云笔记的“测试”文件夹，记录测试所需的账户，SQL语句，URL等方便测试的工具，每个测试步骤最好带上截图。
这样后面如果需要再次手动测试，直接copy搞搞就好了。
如果测试想你咨询某个环节的问题，直接对着笔记看截图就好了。
我如果得知下午要把提测的内容和测试过一遍，会尽可能的把分支名、改动内容、涉及的函数名、可能帮助测试的日志、测试注意事项提前整理好，到时候就非常轻松。不需要现场组织语言，现场找各种需要的东西，避免了浪费时间。
等等。
2.3.5 面向未来总结经验
很多人不重视方法，不去学习好的排错方法（参见《代码排错和避免错误的正确姿势》），不去主动夯实基础，不喜欢总结。
导致失去了快速成长的机会。
拿排错来说，错误排查的方法主要就那么几种，通过扎实的基础结合逻辑的思考，谨慎的印证绝大多数都可以找到错误原因。
我们可以积累排错经验，包括F12大法（抓包大法）、Code Review大法，调试大法、日志大法、搜索引擎大法、控制变量法、换环境大法等。
另外避免上线时遗漏一些事项，我们可以积累上线需要注意的事项，然后每个功能上线前都排查一遍。
比如SQL变更有没有提交并生效？有没有修改配置项，是否已经提交并生效？上线顺序是怎样的？上线后怎么验证功能有效性？等等。
这些在上线前都要认真检查的，并且开发阶段如果有结论可以提前写到笔记里，上线前重新核实。
三、总结
任务分解和函数拆分有极其相似的地方，都是将大的任务拆分成小的更容易执行和评估的单元。
而面向未来编程，则是在其中未来注定要替换的部分，可以提取到某个子函数，未来直接重构子函数即可。
面向未来编程则是考虑更多未来的变化，提供一些方便的开关等功能。
最后也是最重要的一点是，多读有助于提高代码健壮性，可维护性的图书，在本人的另外一篇博客上有超多推荐，欢迎参考。https://blog.csdn.net/w605283073/article/details/89893440
当然过度设计也不太好，但是尽可能的“”，思考各种意外的情况，面向未来总结经验，面向未来做一些准备等。
如果觉得本文对你有帮助，欢迎点赞，欢迎关注我，如果有补充欢迎评论交流，我将努力创作更多更好的文章。
另外欢迎加入我的知识星球，知识星球ID：15165241 一起交流学习。
https://t.zsxq.com/Z3bAiea 申请时标注来自CSDN。