※ 引述《peanut97 (丁守中)》之铭言： : 大家中秋节快乐，快收心了。 : 想问一个假设性问题，大家在工作上，如果有一份专案的 code 是某位前人一手写的 : 後来新人加入，变成前人带新人，此时继续维护那份code。 : 但再过一阵子，前人离职了，唯一的创始者走了。 : 新人把旧 code 重构，或是砍掉重链的机率高吗？ 先跟主管、老板提，确认有人支持你，不然你会被当成怪物 「为什麽要改？」 「系统好好的干麻改？」 「改了有好处吗？」 「会花多久时间？」 「时间剩不多，要动不动随便你，不要影响到时程」 : 我的想像是，如果一份code是出自於1个人之手 : 我的想像是，如果一份code是出自於1个人之手 : 那麽code就是他的世界观、他的切入点 : 那麽code就是他的世界观、他的切入点 : 後面的人看着他的世界观，有时候不一定能全部接受 : 而有人的地方就有政治 : 当他还在的时候，当然就不会乱动。 : 而当他走了的时候，後面的人，一看不爽，就可能改写成自己看得爽的、 : 好改的code。 : 如果是一个团队，那当然要好好讨论为什麽要改 : 哪些因素造成现在不好的情况，以及主管同不同意改等等的。 : 只是我很好奇，1,2人的专案，改的机率高吗？ : 是不是，code只能是「现在还存在公司的人」能控制的才行。 我们公司的经验，以前因为很多原因 (十几年前的 code) 导致系统没有测试、没有严谨的 coding style、方法注解也很少 copy paste 是基本，没有遵照 SOLID 错误不是丢 null 就是 false (欸! 我的 Exception 呢？ 每个 team 成员想怎麽写就怎麽写，不管後续的涟漪 反正东西交出来就好 多棒 然後中间当然成员就是来来去去的 我看这之中大概也是 有人进来 -> 看 code -> what the fuck？ -> 离职 大概就是这种循环 因为自己痛过，知道 clean code、设计模式 的重要性 进公司没多久就跟主管说这 code 不能搞，一定要重构 每个工程师一定看不爽前人的 code XD 但是不是说说而已，总是要提出改善的方法 理所当然地，你前面那些问题我都被问过 幸好我的主管与老板也是支持我这件事情 但是我们讨论的结果，现在的 code 也没办法全部翻掉，怎麽办 在那个时候刚好要把原本的系统生出一套 API 原本的系统是 server-side template render，模板与资料、样式高耦合 这个没办法改成 API 我们的作法是，把原本 DAO 抽出来，放进框架里当成 library 然後加一层 Adaptor 让新系统相容旧模组 旧的 DAO 逻辑怎样就不去动他，要改一律在 Adapter 里面改 (就算 method rename 也是) 在这个新系统，以 SOLID 与设计模式为基楚 controller 与逻辑之间，包装成 service 呼叫 (一律把该写的东西放在该去的地方) service 只准有抽象的叙述，实作的部分写成介面去依赖，由子类别注入 service 使用 DI Container 自动注入依赖的类别，不准直接 new (方便替换测试) 提交功能分支以前，要一并提交单元测试与 functional test，否则不准进 develop 这些都是规定好写在专案文件里面的 (以前没有的文件，现在开始留下记录) 接着就是重头戏的部分 --- 跟人有关的 coding style 怎麽统一？ 就算统一了还是会有漏网之鱼 不小心看到 violation 还是会白眼翻到尾椎 所以这边必须用自动化工具检查，绑在 CI 流程里 这样已经可以省掉很多人工的部分 接着定期 code review，挑出变数不懂、「比较不易修改」的类别… 等等 这样至少做到了几件事情 1. 以前没有的，现在开始留下记录 2. 把 legacy code 加上 test 3. 把系统改成 API server 从视图抽离後，再动前端 (refactor 分阶段) 4. 统一 coding style 5. 符合 SOLID、易於修改的架构 (为了以後着想) 当然前面几篇贴文，有些前辈也有提到 「有人的地方就有政治」 这句话应该划 _底线_ 三颗星 ★★★ 这之中太多阻碍了，电脑不会背叛你，人会 XDD 做了这麽多品质保证措施，一定会遇到成员反对 「一个变数而已，干麻花这麽久时间讨论？」 「我觉得 code review 花太多时间」 「我觉得一个东西，干麻拆这麽多类别，放在一个不就好？」 深入探讨提出这些问题的同事心态，不外乎几个原因 1. 影响 issue solving 时间 --> 觉得产出变慢 2. 觉得写单元测试很麻烦 --> 觉得程式会动就好 3. 觉得一个类别不用提炼为抽象+实作 --> 现在又没这麽多需求 干麻拆？ 但他们忘记事实是，程式本来就是会修修改改的，而且也是会给别人改的 这让我想到一句话 「 据统计，你现在挖的坑，有80%会自己来擦屁股 -- 不知道是谁 」 即便跟他们说品质是什麽，clean code 的重要性，他们还是觉得『不需要』 所以大多数的问题，都是「人」造成的 stop writing legacy code，从你我开始 但如果你身边没人支持，更进一步的说: 没有得到老板/主管支持 这公司也差不多 GG (因为不在意品质) 如果你是 team 的其中一个人，试着先从统一 coding style 开始 我在 Modern Web 2018 听到有一场 keynote 是 Terry Yin 大神的「遗留代码经济学」 里面有提到，其实也不用这麽讨厌 legacy code 因为有那些东西，我们工程师才得以被养活。 如果你发现有 code 里面处处是坑，怎麽办？ 那就别再挖坑了啊！！ 我们现在做的，只是把以前没做的都补回来而已 但是，不要再欠下更多的技术债 债总有一天还是要还的，而且还会生利息 最後我要说一句 很多前辈们会建议，要重构前先写测试 但是 一个万能类别/万能方法/高耦合，要写单元测试，发现整个系统都要写 有些 hard code 的 class 还不见得可以 mock 「人」的问题 无解。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.241.170.131 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1537805551.A.271.html 推 kewang: 推！这场有去听，很赞！ 09/25 00:16 推 t64141: 精辟, 解法也很实用 09/25 00:17 推 yuanyu90221: 推 09/25 00:22 推 ppppman: 推 code review和coding style真的很重要 但人多意见多 09/25 00:23 推 fanatics5566: 精辟，推个 09/25 00:23 → ppppman: 真的都是人的毛～ 但执行良好的话後面维护会轻松很多 09/25 00:24 大多数的人不懂的品质的重要，只想着「我速度会不会会拖慢」 但是请记住，是因为有稳定的品质才得以让开发更快速 推 abccbaandy: 这篇基本上大部分人都卡在第一步吧XD 09/25 00:48 推 Hevak: 推 09/25 01:43 推 FukadaKyoko: 不错~蛮流畅清楚的说明 09/25 01:49 推 marmot00: 推MW2018那场演讲，获益良多 09/25 02:00 这场听完让我很印象深刻 → angusyu: 所以你意思是说你提的才是对的，别人提的都只是懒惰 09/25 02:53 不太懂您的意思？ 我可以理解求开发加速的心切，但是「欲速则不达」 程式码本来就会修改改，做这些事情只是让修改更方便进行 否则开发效率也会趋近於零，最後完全加不下去任何程式码。 推 drajan: Clean code已经是proven best practice 想反对就拿出合理 09/25 03:34 → drajan: 的理由来 09/25 03:34 我很庆幸我站在巨人的肩膀上 我可以接受反对的人不懂 clean code 的重要 但是明明知道，却一直说服自己「没必要」「会拖慢进度」 这样的态度相信其他夥伴也无法接受 推 scottxxx666: 推 09/25 04:33 推 scottxxx666: 推 09/25 04:33 推 SmileJoS: 这篇文章所要表达的意义，就感觉跟MW2018那场很像，没想 09/25 08:05 → SmileJoS: 到是讲者亲自来回.... 09/25 08:05 不是我，内文已修正补上。 我是会众 XDD 「我在 Modern Wen 2018 听到」 推 Sunal: 在此篇情境下不重构有更好解法？ 09/25 08:09 → Sunal: 我是想不太到啦 09/25 08:10 推 sharku: 推 09/25 08:20 推 Y78: 推 09/25 08:31 有两件事情是不可以被妥协的 1. clean code 2. testing 我知道很难 XDD 在 clean code 这本书的前面几个章节，有提到: 程式码最後失控，难道是 PM/PO/主管/客户 的错吗？ 不，错的是我们 RD，这都要怪我们「不够专业」。 看完 clean code 你就会明白，时间与产出是现实的问题， 但我们的专业，不就是要让程式码变得更清楚明白 易於修改和稳定 Unit test 能让 component 表达他原来想要做的 intent 而不会历经改朝换代之後，已经不知道程式码原本想要干麻了。 「测试又叫作不会说话的文件，靠人来传承系统，注定会失败」 -- Terry Yin, 遗留代码经济学, Modern Web 2018 ※ 编辑: banqhsia (114.34.5.66), 09/25/2018 13:37:23