Re: [讨论] 主管不认同书本的知识,说我没学好程设

楼主: aoksc (重出江湖)   2016-05-09 20:30:34
我只能说多数人很容易陷入以为全世界就是自己看的那样
以成语来说大概就是以管窥天吧
你说每个类别都乖乖复制贴上
你有没有遇过一次改版要改全部系统
然后你那些贴上的地方要一个一个改的情况?
我还真的有遇过而且才刚结束
有时候我真的很好奇是不是有公司用程式码长度来算薪水的?
明明就是一样的东西一样的动作
就是有人不喜欢抽离成一个工具方法
然后每一个地方都复制贴上
最后如果要改版就得全部挖出来一个一个改
然后改的时候还要确认是不是有跟其他复制的地方不一样
这样有比较爽嘛?
我认为写程式所谓的优美
指的是程式简洁好读
这不是什么洁癖
而是为了让你能准时下班的必备coding style
我名言就是“偷懒的最好方法就是一次把程式写好”
一次写好抽离能抽离的部份使之能改到最少
你程式问题少user也就少来靠北
你能准时下班的机会就多
一堆人写出来的程式耦合性强到靠北
然后要改的时候就跟玩叠叠乐一样
可能抽一块积木就整个垮了
这时候也只能加班收拾自己造的孽不然还能干麻?
然后因为耦合性太强太难改就会想一堆奇奇怪怪的解决方法
最后终于长成四不像的怪兽天天浪费自己甚至下一个接手人的生命
而且就我观察
这种人几乎都是觉得写程式就是这样阿
也不会再去思考是否有更好的解决方案
每次听到有人在那边大放厥词说什么物件导向、重构、设计模式没用我就心里偷笑
这跟公开大声跟大家说“老子实力弱到连物件导向的好处都体会不到”一样意思
这种东西你本来就是要会遇到你才知道他的好
没有实际遇过你跟讲一百遍你还是无法体会
写过好几年程式还不能体会这些好处
那我只能说什么样的人就会待在什么样等级的地方
这是我干过驻点待过公司看过一堆人之后的心得
也是我给自己最大的警惕
※ 引述《allenxxx (fufuxxx)》之铭言:
: 个人是半路出家,去资策会闭关半年入这行的
: 不学无术先请别见怪
: 以我自己来说,从来不觉得程式写法有什么优劣,程式是帮客户解决问题的
: 只要能达到目的,效能可以达到,维护不困难
: 没必要在那里鼓吹什么手法
: 当然或许是因为我做过很久的维运
: 个人反而不喜欢一堆抽象化的手法
: 当客户火烧屁股电话追杀的时候
: 我还必须要追到抽象的类别或接口,然后判断到底产生的是啥鸟物件
: 到底干了那些好事
: 那开发者你还不如每一个类别乖乖地用复制贴上,我还比较好追
: 每个人都有自己立场
: 开发的人觉得自己的程式写得很"优美",不重复
: 后头维运的人如果技术层次跟不上
: 只有两种可能,想办法跟上,或是把问题踢回给你自己处理
: 另外像我有一个倾向
: 就是一个专案只要开始做,大家决定用什么技术后
: 不管有什么新的了不起技术
: 开会只要有人要用新东西,个人一概反对到底
: 除非不用无法解决现行问题,不然不管多没水准还是一律要用一开始律定的技术
: 这是开发的纪律,要用请用在别的案子
: 很简单,专案不是给你练功夫的
: 你懂别人不懂
: 不代表你厉害,只代表你"摇屁股",替"队友"制造麻烦而已
: 像我就遇过很有进取心的同事
: 每一个功能,只要有进化的可能,他都要做点小修改
: 然后最初的功能跟最后写的差很大...
: 等到他走了
: 接手他的功能,大家干到没力!
: 老兄,你还不如每个功能都一样写法!
: 以RD来说,这当然是有点不进取,我也承认啦
: 不过就像前面说的
: 个人维运做很久
: 有时候必须想的不全然只有自己的立场
: 抱歉以上得罪诸多高手之处,再一次致上歉意
作者: drajan (EasoN)   2016-05-09 20:49:00
不学无术请别见怪 人间已经打好预防针了
作者: CaptainH (Cannon)   2016-05-09 21:22:00
也有例子是过度抽象化 改版也改不动的简洁应指逻辑和算法简洁, 不是语法简洁
作者: mithuang (阿明)   2016-05-09 21:43:00
这篇要转到软件黑特版吗XDD(误)
作者: laputaflutin (很恐怖,不要问)   2016-05-09 22:03:00
原PO怨念深重
作者: airkolf (高雄特快车)   2016-05-09 22:29:00
敏捷开发和重构需要拉扯一下 但是复制贴上和单元化 工厂化 之间没有什么悬念呀我曾经有一个多月和原Po有类似想法 鼓励原Po多体会 DP意义阿
作者: Lordaeron (Terry)   2016-05-09 22:32:00
嗯,物件大师, 高手.用了物件导向,就必然好维护,写得快. 准时下班.
作者: airkolf (高雄特快车)   2016-05-09 22:34:00
物件导向用的好的人 懂一些注解之美还是会让程式很好读的
作者: final01 (牛顿运动定律)   2016-05-09 22:42:00
看完这篇感觉大大就是最会嘴炮那型吧??
作者: femlro (母猪教谋神异端审问官1.5)   2016-05-09 22:47:00
物件导向不够潮惹 现在最潮的是AI debug还有ML
作者: yyc1217 (somo)   2016-05-09 22:47:00
有时候重复贴也不一定是坏事 例如一开始可以共用但后来因需求改变 必须独立出来不再共用 重复贴就很方便所以我觉得这depend on project 很难说谁对谁错
作者: a47135 (金属史莱姆)   2016-05-09 23:04:00
你惨了,提到OOP,等一下又有人要跳出来推广他的神见解了话说@yyc1217,有需要独立出来再COPY就好了啊XD,怕东西以后会独立出来所以就重复贴不是因噎废食吗XD想想aoksc加班前说的话(误)
作者: atpx (秋雨的心情)   2016-05-09 23:49:00
现实上 C&P的人因为产出比较多, 生的比较快维护? 反正他升了, 这些东西留给下个人烦恼
作者: yyc1217 (somo)   2016-05-10 00:09:00
我遇到的是健保费 前人设计时没想到后来有二代健保费科技部 自筹款 迈项顶尖大学计画扣除的对象 比例都不同甚至学校 学院 系所等扣除的比例也不一样 都是当初不会想到的 因为最初就一个健保费 谁知明后年会不会多个三代四代 又或是加收国保费之类的所以我想说的是复制贴上不一定是坏事 因为需求会一直变动最初设计的架构不一定能满足后来的要求阿我讲的是大学里的状况
作者: Blueshiva (龙野南云)   2016-05-10 00:24:00
复制贴上,用来因应的是一次性,或者可预见的未来不会变动的需求,因为可能根本没有下次用到的机会,或者跟本没有修改的需要。反倒是如果预期每年规则都会有些修改,更需要设计一个有弹性的架构
作者: bacdasdf (酱爆)   2016-05-10 00:28:00
同感
作者: typepeter (∵Peter∴笑点)   2016-05-10 00:43:00
太中肯
作者: tyc5116 (累人啊....)   2016-05-10 08:47:00
颇为同意
作者: Argos (Big doge is watching u)   2016-05-10 09:21:00
我也同意 但有时就是人在江湖 身不由己 最好的解决办法 就是换一个工作 不然就算拿你写的跟主管据理力争 大概又会被骂得更难听 没办法 社会上这些人数量还不少
作者: hung0724 (三头)   2016-05-10 11:06:00
现在同事写了十支程式 结果每支有90%是copy % paste
作者: lovdkkkk (dk)   2016-05-10 13:34:00
请他们去维护写得好的, 之后就会从那 copy 去改了 :D
作者: atpx (秋雨的心情)   2016-05-10 16:11:00
现实上要知道功能是不是一次性有时很难
作者: Blueshiva (龙野南云)   2016-05-10 17:23:00
没那么复杂,写的时候问一下自己:下次什么时候要跑这个?跑的时候要不要改东西?是不是参数改一下就可以?这样大概就抓得出来。如果写完下次要用发现要改code,就可以开始评估要不要简单refactor。
作者: VisualStudio (2015)   2016-05-10 20:28:00
我之前有遇过要对两种不同的class做很类似的事情除了class不同之外要回传的显示讯息也不太一样还有两个虽然做的是很类似的事但分属不同功能区但是因为只有两种而且要做的东西已经发展满成熟了之后不太需要再变动 所以复制贴上应该也是不错可以直接看出两个方法用的东西不一样不过如果勉强要抽离的话 我猜大概用泛型化或是参数
作者: lovdkkkk (dk)   2016-05-10 20:33:00
楼上的状况感觉蛮直观, 丢个 msg map 进去要秀时 call
作者: VisualStudio (2015)   2016-05-10 20:34:00
传入的复杂一点 里面还要做一些分流判断机制做不
作者: lovdkkkk (dk)   2016-05-10 20:34:00
方法 showMsg(key), 这样可以用同一个方法秀不同讯息
作者: VisualStudio (2015)   2016-05-10 20:35:00
扩充的情况 我觉得复制贴上应该是比较清楚
作者: lovdkkkk (dk)   2016-05-10 20:35:00
之后不会再动的话就随便了 XD
作者: VisualStudio (2015)   2016-05-10 20:36:00
msg抽出来也是可以 不过我觉得例如错误讯息直接写在那个方法的catch本身应该比较好读例如有两个类别在方法中间五各有5个trycatch讯息都有些不同,全抽出来丢到一个msg用key判别这样看方法的时候每次看讯息都要再跑到msg方法里找
作者: atpx (秋雨的心情)   2016-05-10 20:51:00
我说的很难判断是不是一次性, 是指像是2代健保的状况
作者: lovdkkkk (dk)   2016-05-10 20:51:00
喔喔, 原来是 class 里自己的讯息 @@
作者: atpx (秋雨的心情)   2016-05-10 20:52:00
有些政策面的改变会导致过去的假设失效他没有任何逻辑可言
作者: VisualStudio (2015)   2016-05-10 21:36:00
(补推
作者: viper9709 (阿达)   2016-05-10 23:13:00
推这篇~观念比较正确
作者: Blueshiva (龙野南云)   2016-05-11 01:30:00
2代健保当然是当成一次性啊 XDD 这种东西不会每个礼拜改啦,至少是以年在计算的
作者: roger00 (Stage Column(?))   2016-05-11 08:06:00
作者: Masakiad (Masaki)   2016-05-11 08:32:00
我们team之前的做法是bad smell出现时会纪录到管理技术债的表格,通常在下个sprint会做完修正,另外,纪录的当下就会大略评估最晚何时要改。比如效能大约可以知道多少流量是极限,duplicate code这种我们会在出现第三次的时候开始设计重构。
作者: FukadaKyoko (小毛哥)   2016-05-12 09:59:00
讲得不错啊!然后居然有人觉得复制贴上较好,神奇

Links booklink

Contact Us: admin [ a t ] ucptt.com