※ 引述《prag222 (prag)》之铭言：
: 大家好
: 小弟上上份工作快离职前
: 听到新进的同事说
: 他都习惯把程式写成一个一个小的function
: 后来离职我花了一点时间学习设计模式
: 和了解SOLID原则
: 我越觉得这种作法很OK
: 我大概也知道这应该是重复说高手说过的话
: 所以后来找到工作
: 专案自己一个人开发
: 也没主管强制要求程式该怎么写
: 变照着 之前同事说的话去开发
: 让程式码 程式码也是有结构性架构性的
: 而不是一个function写几百行几千行
: mvc Model层也是切得很干净
: Model层写的就像api
: controller带参数给MODEL层捞资料出来
: 不过我最近的公司
: 完全不是这种做法
: 虽然是MVC不过还是下SQL查出资料
: 看到function写几百行我看了就昏(业务逻辑)
: 为了符合公司专案的coding style有点辛苦
: 基本上我速度也差不多折损一半也有了
: 不过尽可能把程式码写成一个一个小单元应该也没错吧
: 毕竟单元测试
: 跟我最近看重构的书也是建议这样
: 上份工作有改到open source的专案
: 好像也是这样
: 是很难看的懂 但扩充维护修改都很轻松
重构取决于你对自己的程度有多自信
假设已经发现问题 也觉得自己有能力修改 试着跟主管沟通看看
说“在自己任务时程不耽误的前提下 有路过看到程式码就稍微整理一下”
若有得到主管或同事许可就下去改
没把握自己可以改好的话 量力而为 先从小区块开始改起
尽量多用辅助工具来帮助你重构
一些基础的设置例如linter的检查
不必要的语法、不合规则的命名或者nested if之类的他会提示你请你修改
或者是根据引用的rename之类的
比较怕大幅度的重构改坏 亦即版控很重要
因此先从小区块开始 每次改完若有提升一点可读性 就还不错
在不改动代码逻辑的前提下 其实现在的IDE很进步 要重构都很方便了
先把杂乱的程式模块化 考虑一下谁依赖谁的问题 小心搬就好
惯用的IDE、语言都摸很熟 重构大多数情况都是手法问题
大部分都有个固定的套路可以依循
常用会越来越熟 个人观点给你参考