Posted on 2017-08-20 15:37
小菜枫 阅读(239)
评论(0) 编辑 收藏 引用 所属分类:
学习笔记
重构之于软件开发, 可谓一个绕不过理不清的梗.
整个软件开发的范围触及世间各行各业, 每时每刻都在变更的需求, 每分每秒都在改变的结构, 以不变应万变, 在软件行业, 既不对也对.
不对, 是指不可能一成不变的去应对.
对, 是指前人总结了很好的经验给到我们去学习, 应用; 这些经验表现形式万万千, 大体的流程不会有太大差异.
首先, 得发现现在的痛点在哪里:就是你的代码在哪里令你如鲠在喉, 那痛点就在那里. 这一点, 于我, 就有了<重构:现状>的种种.
其次, 既然找到了痛点所在, 那么需要去考虑如何将其修正, 此时, 可能需要别人的协助, 或者从相关书籍汲取方法、经验, 相对来说, 是一个较为进展缓慢或者很容易半途而废的阶段. 像我, 在此阶段, 一共耗费了四个多月, 期间阅读参考了<架构之美><恰如其分的软件架构><ThinkInUML>等书, 尝试过从统一过程进行规划(最后发现用屠龙刀宰蚊子), 也曾反思过放什么当下这种三无规划的状况下得以生存, 最终决定从小做好, 先将可以复用的提取, 然后再细分耦合的方式进行, 最后要防止以前三无的状况从而制定了相关规范章程, 详情可参见<重构:规划>.
然后, 万事开头难, 最纠结的规划过程走过, 总需要有实际的工程进行, 才得以用实践验证规划的对错--<重构:工程>.
最后, 前车之鉴后事之师, 之前的困境, 如果在重构的时候不作改善, 那么重构的意义何在? <重构:测试>是在落实规划过程中, 拜读了<C++程序设计实践与技巧：测试驱动开发>之后, 从中学习到了单元测试的落实, 测试驱动开发的敏捷方式, 最终结合现实打造的实践, 它, 现在正一步步落实在所有模块的重构当中.
当然, 我并不能确定现在这个方式是最优解, 但是其是以我当下经历和认知得到的最合适的答案. 虽然, 它还有系统范畴的交互测试尚需规划, 但百步已经走了八十了, 最终的结果已经可以遥望, 后面的路, 终归会走完, 既是对这次重构的句点, 也是对自我曾经承诺的句点.
遥望身后的脚印, 曲曲直直, 有深有浅, 有迷茫有深刻...