作者tyc5116 (累人啊....)
看板Soft_Job
标题Re: [心得] 反思程式革命的疯狂。
时间Tue May 10 21:27:26 2016
※ 引述《NDark (溺於黑暗)》之铭言：
: 的原因避开了管理及工程的检验。其中的一些甚至应该烧掉，埋葬，用巨石镇压，然後把
: 这个警告刻在石头上：天真地过分简化管理，...
: Agile became a brand-name, with marketing hype. It therefore became subject
: to the rules of all such hyped products....
: 敏捷已经变质为一个招牌，还是一种行销的炒作。它只是波潮流所推送的产品中的品项。
这段文章还好啦(没看本文,只看节录)
主要不就是理想和现实间的差距吗
理想,也就是敏捷开发,这个idea很好,也有很多书在提倡
可以参考这本书
http://goo.gl/zYTckv
书的後面提供了一个失败和成功的例子
就像信仰一样,大家都希望人心向善,世界大同,但是理想和现实总是很差距
有很多要妥协的
敏捷开发很好,重构很好,可是schedule很赶
没时间好好思考,copy paste功能弄出来再说,先求有再求好
design pattern很好,但是没事用继承这种高超手法干麽,明明有比较简单的作法
(我有听过前同事这样讲....)
写测试程式很好,但是schedule很赶,先求有再求好
总之就是先求有再求好了,不过事後通常不是因为懒或是code太难懂
反正也不会出错,就先放着,累积久了就变烂code了,相信大家都有经验
理想很好,但是没考虑到实务上的状况
有改动就有风险,跑好好的地方为什麽要改,一定会有人这样想
更何况,要量化出怎样才叫好的开发是很困难的
敏捷开发很好,但是你要如何拿出数据说服别人??
举一个我个人的想法(不过也只是单方面的看法XD)
我觉得姑且不论任何写作方式,只要能作到三个大方向,大致上code不会烂到哪里去
1.命名精确,不要出现a1,a2等等的名称
2.每个函式控制在200~250行内
3.括号的层数控制在三层内
e.g if
{
for
{
if
{
}
}
}
我觉得这很基本,离敏捷开发也还谈不上,但实务上要完整实现就不知道要等多久了
so~实务离理想还太远了,一步一步来嘛,你要求一步到位下场就是没人认同
呼应一下这句,敏捷已经变质为一个招牌，还是一种行销的炒作。
至少面试拿来嘴炮是很有用的
同样的道理,"当责"这名词不也一样吗,观点很好
但想要一步到位,科科,当你去死~
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.224.41.15
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1462886850.A.6D1.html
1F：推 NCUking: 函式200行? 你是认真的吗? 05/10 21:30
2F：推 rayway30419: 20行其实就很多了 05/10 21:32
3F：推 sarafciel: 200行的code一定有办法再拆函式出去 除非你写组语XD 05/10 21:34
4F：→ tyc5116: 有可能行业别的关系吧,我常看到动辄1~2000的函式... 05/10 21:35
5F：→ tyc5116: 再拆当然还可以阿,但是...我觉得还是一步一步来会比较好 05/10 21:36
6F：推 NCUking: 说design patterns是搞继承的那位 根本是不懂装懂XDDD 05/10 21:39
7F：推 rayway30419: 200行的函式是什麽巫术....... 05/10 21:42
8F：→ rayway30419: 2000 05/10 21:42
9F：→ tyc5116: 我觉得design pattern是教你如何善用继承和聚集的特性 05/10 21:44
10F：→ tyc5116: 前同事的说法某种程度也不能说是错 05/10 21:44
11F：→ johnny94: Class 200 行还比较可以理解...函式 200 行是怎样 05/10 21:49
12F：推 sarafciel: 突然想起交大某教授聊天时提到曾接手过印度人写的13层i 05/10 21:55
13F：→ sarafciel: f波动炮 仔细想想200行好像也还算能接受的范围(远目) 05/10 21:55
14F：→ manaup: 个人的括号层数可以忍受到六层 毕竟还要try-catch 05/10 21:56
15F：推 ns1234: 我无法接收一个function超过200行。。这种一定都是可以再 05/10 21:56
16F：→ ns1234: 拆解的。。 05/10 21:56
17F：→ manaup: 没有重复code的情况下 单函式3000行我可以 05/10 21:59
18F：推 rpdef9969: 2跟3应该存在弱关联...像3F说的那样处理， 05/10 21:59
19F：→ rpdef9969: 再加上guard clause观念去检视 ifelse flow 05/10 22:00
20F：→ rpdef9969: 巢状层次可以有效约束。 05/10 22:02
21F：→ tyc5116: 200是我认为不搭配辅助方式(画图,下断点,etc)仍然能容易 05/10 22:10
22F：→ tyc5116: 理解的范围,不过看大家反应似乎还是很难接受XD 05/10 22:10
23F：推 Ekmund: 我看过不少破500 还有几个破千的...该说幸运吗 Orz 05/10 22:26
24F：→ GoalBased: 拿过一个因为行数太多一支档案放不下只好写成两支的Y 05/10 22:30
25F：→ dnabossking: 新手的看法，所有的'好'设计，都是为了分离（解耦） 05/10 22:45
26F：→ rpdef9969: 设计模式原则是聚合优先於继承 05/10 23:12
27F：推 Ayukawayen: 200行当上限我可以接受 当下限我实在不行 XD 05/10 23:42
28F：→ Ayukawayen: 是控制在0~(200至多250)行内 还是控在200~250行内啊? 05/10 23:44
29F：推 shortoneal: 一个function两千行通常看到都是那种Thread function 05/10 23:49
30F：→ shortoneal: 里面switch case 到欲罢不能那种..，每个case又不太大 05/10 23:49
31F：→ y3k: 一直跟schedule妥协只会让不懂管理的人爽到 以为只要押schedu 05/11 07:08
32F：→ y3k: le事情就做得出来 结果就是愈做愈烂 我的话都一定会讨论一下 05/11 07:09
33F：→ y3k: 反正我很努力了 如果赶不出来一定是schedule的问题(? 05/11 07:10
34F：→ Lordaeron: 高论！！什麽才是懂管理的人呢？ 05/11 08:49
35F：→ tyc5116: schedule很重要阿,一定要以它为主,不过如果常常都不合理 05/11 09:01
36F：→ tyc5116: 就该换间啦,在那撑干麽? 05/11 09:02
37F：推 Argos: 这里好像没见过什麽世面齁 前公司单函超过1000的满地都是 05/11 09:17
38F：→ Argos: 不过这种世面 不见也罢 QQ 05/11 09:17
39F：推 ssadow: 通常不是要一次到位 只是想要为将来保留修改空间 05/11 09:24
40F：→ Lordaeron: 哦哦哦，都是没看书的人。主席说10行就够多的了。还 05/11 16:23
41F：→ Lordaeron: 200呢。打到死就是一个function 20行。没听主席讲的。 05/11 16:24
42F：推 csfgsj: 这种问题我都是这样解决，再多行再多层也不怕 05/11 16:52
44F：推 typepeter: 看作品看赚的钱才是重点 不幸的，跨国大公司都重视软工 05/11 17:55
45F：→ typepeter: 程式写难维护难懂 太长无法除错 所以才有软工一说 05/11 17:58
46F：→ Lordaeron: 哪几家大公司重视软工啊? 05/11 20:18
47F：→ bobju: 200行还好吧? 一堆open source的函式恐怕都不止这个数. 05/11 22:02
48F：推 typepeter: 有空去看看google Facebook apache 等公司的程式码 05/12 02:12
49F：→ typepeter: ptt打笔仗很简单 不如省下来去学习强者写程式 多赚钱 05/12 02:14
50F：→ typepeter: 难怪国外都上太空台湾还在杀猪公 连大陆都屌打我们 05/12 02:16
51F：→ typepeter: 说到这个 有没有听过ibm yahoo 程式和技术也去看看吧 05/12 02:18
52F：推 storyn26383: 我有维护过单档上万行的 PHP……… 05/12 05:54
53F：→ Lordaeron: 典型见树不见林，整天强者挂嘴边。他们有多重视软工？ 05/12 07:48
54F：→ Lordaeron: @typepeter期待你的讲解 05/12 07:50
55F：→ wesley234: csfgsj 不就是IBM的，你可以去问他 05/12 08:50