作者prag222 (prag)
看板Soft_Job
标题[请益] coding style差太多怎办?
时间Tue Jan 19 21:02:29 2021
大家好
小弟上上份工作快离职前
听到新进的同事说
他都习惯把程式写成一个一个小的function
後来离职我花了一点时间学习设计模式
和了解SOLID原则
我越觉得这种作法很OK
我大概也知道这应该是重复说高手说过的话
所以後来找到工作
专案自己一个人开发
也没主管强制要求程式该怎麽写
变照着 之前同事说的话去开发
让程式码 程式码也是有结构性架构性的
而不是一个function写几百行几千行
mvc Model层也是切得很乾净
Model层写的就像api
controller带参数给MODEL层捞资料出来
不过我最近的公司
完全不是这种做法
虽然是MVC不过还是下SQL查出资料
看到function写几百行我看了就昏(业务逻辑)
为了符合公司专案的coding style有点辛苦
基本上我速度也差不多折损一半也有了
不过尽可能把程式码写成一个一个小单元应该也没错吧
毕竟单元测试
跟我最近看重构的书也是建议这样
上份工作有改到open source的专案
好像也是这样
是很难看的懂 但扩充维护修改都很轻松
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 150.117.70.191 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1611061354.A.2F3.html
1F：推 aidansky0989: 能动就好的公司建议逃 01/19 21:10
2F：嘘 knives: 下sql会很累，你还太菜，快逃吧 01/19 21:11
3F：嘘 lturtsamuel: mvc跟sql的关连是...? 01/19 21:15
4F：→ accessdenied: 程式码写成一个一个小单元，应该要增加可读性才对， 01/19 21:19
5F：→ accessdenied: 怎麽到你手上变成「是很难看懂，但维护轻松」？ 01/19 21:19
6F：→ iamshiao: 谁规定 mvc 不能下 sql? 01/19 21:45
7F：→ x246libra: 他的很难看懂 应该是指 程式码 会跳来跳去吧 有用介面 01/19 21:52
8F：→ x246libra: Imp 通常不会放在同一个档案 01/19 21:52
9F：推 fiiox3: 我大概懂你意思...我公司目前就是这样，看到头很晕 01/19 21:54
10F：→ fiiox3: 同样逻辑东西不断复制贴上 01/19 21:54
11F：推 alihue: mvc 还是要下 sql，虽然有些 orm 会额外包一层语法，但是 01/19 21:56
12F：→ alihue: 专案一大，还是 sql 比较好维护。 01/19 21:56
13F：推 jj0321: 哈哈 一个.cs档塞3~4万行程式码还是照样维护呀 01/19 21:56
14F：→ jj0321: 钱给超多还是吞下去继续做 01/19 21:57
15F：→ a740125: 骑驴找马吧，这种环境待太久不太好 01/19 22:01
16F：推 longlyeagle: 这个不叫 coding style 叫做有没有把程式写好 01/19 22:10
17F：→ devilkool: 看不懂什麽mvc下sql 01/19 22:13
18F：推 wulouise: 原本还想要战tab跟space,进来竟然...!! 01/19 22:13
19F：推 j0958322080: 还以为是我们公司XD 01/19 22:14
20F：→ airtsubasa: 应该是指不是.where .select ,from a in b 01/19 22:19
21F：→ airtsubasa: 复杂sql或跨资料库用套件下也是痛苦啦 01/19 22:20
22F：→ devilkool: 那下SQL和MVC或是不是烂code无关啊XD 01/19 22:28
23F：→ devilkool: 不过进到架构烂的公司除非钱很多否则我也会想离职 01/19 22:30
24F：→ james732: 旧code能正常运作的就不要碰它，有bug要修再趁机重构 01/19 23:13
25F：→ james732: 有兴趣可以参考91的课程，很详细的说要怎麽做 01/19 23:13
26F：→ james732: 从不可测试的烂code→可测试的烂code→可测试的好code 01/19 23:15
27F：→ james732: 不过个人觉得如果对薪水之类没帮助就不要乱碰它 XD 01/19 23:16
28F：推 mercurycgt68: 这种好习惯还难看懂原因只有四种，我都亲身碰过：1 01/19 23:16
29F：→ mercurycgt68: . 命名差 2. 文件/注解没写好 3. 没有靠IDE帮忙跳 01/19 23:16
30F：→ mercurycgt68: 转/peek 4. 对方是智障; 看您的行文风格，应该不 01/19 23:16
31F：→ mercurycgt68: 是4 01/19 23:16
32F：推 alan3100: 如果你只碰orm没碰过需要sql应该是你摸过的系统都太小 01/19 23:38
33F：推 luke72: 所谓的code style就是主管,前辈,掌权者说了算 01/19 23:47
34F：→ luke72: 再多的书 大神文章 google设计模式 先问你薪水谁给的 01/19 23:48
35F：→ luke72: 差太多怎麽办？前辈的code你只能跟着阿 不然还能怎麽办 01/19 23:50
36F：→ luke72: 等你抓到机会抓到权力 才能慢慢导到你理想的方式去 01/19 23:50
37F：→ luke72: 而且要想想既有的code为什麽长这样 改成理想的样子能动吗 01/19 23:52
38F：→ luke72: 很多菜鸟读了一些文章就以为自己超强 改下去才发现爆光光 01/19 23:53
39F：→ Kazimir: 要是没看过某种架构或者pattern会觉得比较难看懂我觉得 01/19 23:55
40F：→ luke72: 就好像我有一次在牙医手术台 菜鸟医师刀开到一半跑去求救 01/19 23:55
41F：→ Kazimir: 正常吧 01/19 23:55
42F：→ luke72: "为什麽跟教科书上的图不一样" 我：....... 01/19 23:56
43F：推 noahleft: 就一边工作一边注解一边refactor 01/20 01:20
44F：→ noahleft: 书上的范例都很理想 实务上不是人人都懂SOLID 01/20 01:21
45F：→ noahleft: 而且你会说看到头昏就表示你自己也还没很熟悉业务逻辑 01/20 01:22
46F：→ noahleft: 所以就一边工作一边注解确保你理解业务逻辑跟假设 01/20 01:23
47F：→ noahleft: 熟悉以後再根据SOLID补就好（不是推倒重来 01/20 01:24
48F：推 youtuuube000: 应该是命名太差造成看不懂吧.. 01/20 01:26
49F：推 noahleft: 像前面版友建议的。可以先理解为啥要SOLID 01/20 01:27
50F：→ noahleft: 而不是书上说这样比较好 01/20 01:28
51F：推 vi000246: orm跟sql都要学啊 orm有效能瓶颈的 01/20 01:33
52F：→ vi000246: 我是觉得要先学会看懂烂code 改得动烂code 01/20 01:33
53F：→ vi000246: 才能体会OOP的美好 01/20 01:33
54F：推 WaterLengend: 我觉得这不是style 纯粹是之前写太烂 01/20 06:57
55F：推 del680202: 连调整都做不到 还是转行吧 01/20 07:10
56F：→ taikobo: coding style 跟 code quality 是二回事... 01/20 07:42
57F：嘘 KanzakiHAria: 测试能过随便你改 01/20 08:36
58F：→ shooter555: 测试能过 然後内容可维护性太低就是猪队友的做法 01/20 08:45
59F：→ testPtt: 没维护到一堆复制贴上的没资格抱怨啦 01/20 09:27
60F：→ xo1100: 遇过同一个变数用到一千多行还在用的 01/20 09:42
61F：→ xo1100: 不然就是好几层ifelse 然後三四个变数在变的 01/20 09:43
62F：推 t19960804: 一堆智障senior也都是各种复制贴上 一堆function快百 01/20 10:30
63F：→ t19960804: 行 01/20 10:30
64F：→ shooter555: 好几层ifelse然後好几个变数这我也遇过 很想砍掉重练 01/20 10:50
65F：→ shooter555: 然後变数命名还是看不出含意的 01/20 10:52
66F：→ lazarus1121: 我连if的条件看到一堆括号or或and都受不了 01/20 11:00
67F：→ lazarus1121: 写出这种烂code的人可能还自以为是逻辑大师 01/20 11:02
68F：推 brianhsu: ninja code，工程师保护自我价值 XD 01/20 11:38
71F：→ newhandfun: 可读性跟效能有时候也是要做取舍，我觉得可能要搞清 01/20 13:29
72F：→ newhandfun: 楚商业逻辑再看看 01/20 13:29
73F：推 wayne5668944: 谁规定一定要用orm? 复杂的东西orm 根本超难处理好 01/20 15:43
74F：→ wayne5668944: 吗... 01/20 15:43
75F：→ ChungLi5566: 那是以前VB时代留下来的包袱 01/20 16:09
76F：推 oachan: 如果还只是一般工程师，那只能从手边的做起，别人的cod 01/20 22:43
77F：→ oachan: e 尽量看，自己先维护好自己的程式码 01/20 22:43
78F：→ oachan: 如果为了重构反而拖累开发时程，会被叮到飞起来的，等未 01/20 22:44
79F：→ oachan: 来带团队或主管在尝试传播想法 01/20 22:45
80F：→ viper9709: 推楼上 01/21 00:16
81F：推 uioty: 我待的第一间公司主管带得很好，刚进去的那阵子会很仔细的 01/21 01:26
82F：→ uioty: review我的coding style，第二间就真的是能动就好 code有 01/21 01:26
83F：→ uioty: 时候看到会觉得公司招人标准到底在哪... 01/21 01:26
84F：→ brianhsu: 能动就好的 code 肯定一堆啦，我还去过那种为了抢快什麽 01/21 09:29
85F：→ brianhsu: code smell 都有，标准教科书负面教材案例大全的新创。 01/21 09:29
86F：→ brianhsu: XD 01/21 09:29
87F：推 luke72: 以前修OS时老师是微软出身，他说windows也是这样.. 01/21 11:19
88F：推 luke72: 教科书都太理想仅供参考，winxp一堆没照课本做的 01/21 11:20
89F：推 wulouise: BUG出来会害人停机的..不管怎样一定是先补起来啊，是取 01/22 21:16
90F：→ wulouise: 舍 01/22 21:16
91F：→ dogocreat: 有时候太复杂的业务需求orm反而效能不好 01/24 00:38
92F：→ superpandal: 所以说为何当一个好公司的元老很重要 一句话说出职 01/24 13:51
93F：→ superpandal: 场生态 01/24 13:51
94F：推 nayeonmywife: 别用ORM了吧… 调效能很惨 03/21 19:06