作者qrtt1 (null)
看板Soft_Job
标题Re: [讨论] 程式不能写一辈子？
时间Tue Apr 6 01:04:09 2010
「程式不能写一辈子？」。
是的，程式无法写一辈子，因为你的肝会老
在成为产出程式并赖以维生的工作者之前，我的程式开发总是很天马行空的。
想法跳到哪，程式就写到那。连带着，我们 bug 也是这麽的发散。
那是一段写程式等於写 bug 的恶梦！
在那地狱般的回忆，能用来说嘴的只剩不眠不休连续疯狂 coding 与 debug 的时数。
说实在的，那只是用一个浪费生命的伪成就，来掩饰一再地犯错与无能。
会基本语法，稍懂些逻辑确实可以写出程式。
但是不佳的设计、不良的结构、重复的 Copy & Paste。
程式码一整份，一整份地复制，到底哪一个版本才是对的，
大概只能靠运气了。
这一切就像在开始 coding 的同时，
今日流程被标上了反覆记号。
重复着相似的逻辑，相仿的错误，相同的疲劳感。
心理的压力，随着进逼的死线更加无法承受。
那时的我，只写得出自己想要的东西。但无法正确地掌握客户想要的需求。
还是学生的我，是个非常不成熟的程式设计师。
经验几次爆肝的接案历程，对自己的能力感到相当的怀疑。
并且看着坛论对程式设计师生涯的讨论，
也相信吃这行饭需要新鲜的肝，而写 bug 是个常态。
但真的是这样吗？
不，程式可以写一辈子，因为你将不断地重构你的工作方法。
我想每一份需要专业的职业都有着一群持续贡献的工作者。
对软体开发来说，其实我们拥有许多宝藏。有些知识是无法独自领略的。
这得感谢过去曾与我一起工作过的前辈们，
透过 Pair Programming 的手法，快速被优良典范感染。
开启了我对 XP 相关知识的接触。
在那段不算长的时间，启发了我对於下列知识的兴趣：
1. 统一撰码风格
2. 重构的使用
3. 单元测试
4. 版本控制系统
统一撰码风格不单纯是符合团队的 coding style，这是团队总体思考模式的同步。
像是一个类别，它会有个负责主要流程的 method，
但我们不在这个 method 内有任何条件判断 (强烈地期望)。
它的内容是直叙的 method call 序列，就像平顺地交办一些事项。
而原本在直觉的实作方式，应该出条件判断的地方，
可能只是在其他细节中的一个 if/else。或直接在多型的结构消耗掉了。
判断出现地越少，程式结构就简洁许多，也减少因写作的失误而产出的 bug。
有时无法直接写出较少条件式的实作，透过重构技巧学习自我整理程式码。
而重构技术包含的项目可深可浅，浅如替换变数名称，提取程式码成为函式。
深如结合设计模式，调整外部无法触及的程式结构。
程式结构变换最要紧的是前後的逻辑保持一致，要确保逻辑正确性。
单元测试就是个不可缺少的技巧。
反覆地，撰写测试、重构、再测试、再重构。
这些小技巧其实都环环相扣支持着我们，对於面对的程式码产生良好的改变。
而给与我们无比信心的，那就是版本控系统。
写乱了，再拿回原先的那一份，重来一次。
这麽友善的开发环境，您说软体人悲哀得起来吗？
这是我想要分享的，是能以写程式作为一辈子的工作的正反理由。
如果您总是让自己处於险境，再强的意念都会被磨碎。
如果您试着让自己处於友善的开发环境，就能获得走下去的动力。
当然，您可以看作是我的乐观宣言。
但不去经营友善的开发环境，怎麽能期待做这行一辈子呢？
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 61.231.48.59
1F：推 Ting1024:感人呐.............. 04/06 01:37
2F：推 wouzfer:的确很感人... 04/06 04:02
3F：推 costbook:我学生时期的经验是(也就是现在)... 04/06 05:36
4F：→ costbook:规格书开出去给学弟，回来的东西都不一样 04/06 05:37
5F：→ costbook:就算结构对了，行为也不对 04/06 05:37
6F：推 andymai:推~但往往现实不一定是这样~有时客户连他自己要什麽都不晓 04/06 12:30
7F：→ andymai:得~好吧~先做一版来看看~再来就是永无止尽的修改~改到最後 04/06 12:31
8F：→ andymai:的架构连他老妈都不认得~能怎麽办呢? 04/06 12:34
9F：→ andymai:要重构?可以~需求不会因为这个停下~拿你自己的私人时间来 04/06 12:36
10F：→ andymai:好不容易重构了~结果哪天要翻架构~不想骂脏话还蛮奇怪的.. 04/06 12:37
11F：→ andymai:少打~是"当下不想骂脏话"... 04/06 12:39
12F：推 leicheong:可惜是吾让自己身处险境, 只要你不换工作, 很多时候都 04/06 13:14
13F：→ leicheong:不是自己能决定的. 04/06 13:14
14F：→ leicheong:然後version control只要不是由团队的直属上司以严法 04/06 13:16
15F：→ qrtt1:我同意这现实存在，但那是 PM 专业程度与客户教育的议题了。 04/06 13:17
16F：→ leicheong:推行的, 只需要有一个人不按规定checkin, 就会崩壊了吧 04/06 13:17
17F：→ leicheong:你说的这些, 有很多都取决於「老鸟」们是否能把良好的 04/06 13:20
18F：→ leicheong:「传统」延续下去. 但世代交替间一些已在其他公司染上 04/06 13:21
19F：推 ricky906:说得好!! 04/06 13:22
20F：→ leicheong:「恶习」的人把坏风气传入似乎无可避免. 这些人即使被 04/06 13:22
21F：→ leicheong:短时间内处理掉了, 对团队间仍会做成坏影响的... 04/06 13:23
22F：→ qrtt1:我当然知道有这些困难，但放任下去只是无尽的恶性循环。 04/06 13:25
23F：→ qrtt1:弟之所以回文，就是希望增加良性循环的可能。 04/06 13:25
24F：→ qrtt1:由自己的观念、行动开始微调。面对限制寻求可能才是活路。 04/06 13:31
25F：→ rofellosx:研发自动写程式或轻松写程式的程式... 04/06 14:28
26F：→ adrianc:Visual Studio ... 04/06 15:09
27F：→ juriolegend:VS的规则运算式的寻找取代功能很好用的.. 04/06 20:02
28F：推 prag222:我目前没有时程压力,慢慢做轻松做,进度就超前了 04/06 21:30