作者bachelorwhc (积积阴阴德)
看板Soft_Job
标题Re: [讨论] 会手痒想动前人的程式吗？
时间Sat Jan 12 11:56:25 2019
※ 引述《sec5566 (sec)》之铭言：
: 或是命名规则有问题的，
: 像函式用大驼峰，类别用小驼峰，
: 或很奇怪的名称之类，
: 不然就是排版很乱的，
: 这种大家会手痒去改吗？
就跟推文乡民讲的一样 这是团队的管理问题
通常命名如果不符规则 只是改大小写这应该不用过问吧
但是改名称 老实讲这要看写的人还在不在职啦
不然你改了 code review时解释说: 这名称很奇怪
除非你跟对方沟通过 或你比对方大牌
做事做就是做人 没有对事不对人的
(何况 你有办法保证你的命名一定比较好？)
: 改下去又是大工程了，结果工作越做越多
你前面讲dry原则的 软体开发原则很多 但这些原则多半都被有心人士拿来吵架用
更何况 这些原则能不能为商品带来价值 多数都不能
我建议三小原则的 放在自己心中默默实践就好
我讲一下重构的几个种类 这是小弟我在业界的观察
1.
命名、拆解
这就是clean code里很基本的东西
function不要太长 命名清晰描述单一动作
改名的事情我前面说过了 这边就不赘述
IMO 比起改错字、大小写 他命名很奇怪我把他改掉
把大function拆解成小function 还比较有用
(而且绝对不会是大工程... 所以... 要实践你所谓的dry可以从小事做起)
2.
运用语言技巧 精简程式码
老实讲这种事情就只是单纯的炫技
小弟我就曾经把一大段大量重复的code
利用Template 将逻辑拆解成Policy
使得每个重复的流程都可以透过组合的形式避免duplicated
但说真的 它的价值就只有文学上的价值而已
(我认为在某些状况下 重复的code不见得是错误或不良的)
3.
架构
我认为需要改架构的状况只有几种：
a) 逻辑紊乱重复 导致效能低落或维护不易
b) 当前的架构无法因应新的需求或改变
这种状况 才是你所说的工程浩大
不然一般状况下的重构搬移删除重复代码都只是很基本很浅的功夫
TL;DR
其实重点是这样的
在这个业界 有需求 满足需求才会产生价值
你的需求 如果只能满足你个人 那我肯定你做的事情是没啥帮助的
更何况 你重构又怎麽能保证不会有新的问题产生
所以最好的方式是 建立测试 才去重构
而不是重构自己爽完了 留给後人收拾问题
小弟上次重构 把一个重点功能的速度提升至少2.5倍
还赢得了与某大公司进一步合作的机会 给你参考
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.50.60.32
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1547265388.A.B12.html
1F：→ t64141: 第二点,当专案需求是频繁更动的时候,重用性的价值就出来了 01/12 12:05
2F：→ t64141: 只需要修改一个地方跟修改一百的重复的地方,时间跟测试成 01/12 12:07
3F：→ t64141: 本与风险都不一样 01/12 12:07
4F：嘘 Beatles5566: 只有文学上的价值 lol 那你改之前大概是秒懂型的code 01/12 12:12
5F：→ Beatles5566: 改完之後反而多花时间看template 01/12 12:13
学Java还要特地跑到资策会的人 当然需要多多花时间练习看template呀
6F：推 oneheat: 真的是小弟 01/12 12:53
7F：推 NDark: "你保证你架构比较好?" 其实用相同的逻辑可以驳倒你. 01/12 13:01
我并没有说我的架构比较好 但产品效能提升&受到认可是事实
我也不想浪费时间定义什麽架构 什麽命名比较好
谁有更好的做法 谁能带来更好的效益 谁都可以去实践
谁替公司赚钱 替公司贡献技术 谁替产品解决问题 我想这才是最重要的
整天把架构问题搬上台面吵 想着要驳倒谁
是把软体架构当解决问题的工具 还是当作制造问题的工具呢？ :)
8F：推 DefTM: 觉得中肯 改什麽不重要 重要的是能替公司赚多少 01/12 13:49
※ 编辑: bachelorwhc (123.50.60.32), 01/12/2019 15:43:40
9F：推 accessdenied: 推一个 01/12 16:29
10F：→ Ghamu: 重构本身不是输出输入不变 只是改改程式码 拆分 增加可读性 01/12 17:38
11F：→ Ghamu: 吗? 提升速度效能 那算是另一个事情吧? 01/12 17:38
是两件事没错
但我说过我认为两种状况下需要重构: 不易维护或流程过於复杂、有新的需求
我当时的目标是要提升效能 因为既有的程式码很难满足
所以才进行重构 这就是一种需求
而不是因为觉得自己架构比较好 才进行重构
至於你说的 改改程式码 抽取function 这些看似很基本的事情
其实也能发现一些多余的流程或效能不佳的写法
(当然你本身也要有监别这些问题的能力)
12F：→ Ghamu: 增加可读性是有用的 因为很多开发时间都是在阅读程式码 解b 01/12 17:42
13F：→ Ghamu: ug 实际写全新code 的占比不如想像中的多 命名那些 我以前 01/12 17:42
14F：→ Ghamu: 也有心魔觉得不要乱改资深同事的 但看书说 就给她给下去吧 01/12 17:43
15F：→ Ghamu: ～ 原因很简单 写那段code的人早忘记了 改好的话会感谢你 01/12 17:43
16F：推 iq1000x: 改程式码就有可能速度不一样了啊 又不是只改命名… 01/12 18:54
※ 编辑: bachelorwhc (123.50.60.32), 01/12/2019 19:45:04
17F：→ ChungLi5566: 翻译：耦合性 内聚性 每个人拿捏程度不一 01/14 08:52
18F：→ BoXeX: 想到前公司有段code写得非常巧妙 物件化的很好 01/14 22:29
19F：→ BoXeX: 结果大家常用的 debug 工具在那边很难用 01/14 22:29
20F：→ BoXeX: 变成最难维护的一段 code 01/14 22:29