作者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
推 Ting1024:感人吶.............. 04/06 01:37
推 wouzfer:的確很感人... 04/06 04:02
推 costbook:我學生時期的經驗是(也就是現在)... 04/06 05:36
→ costbook:規格書開出去給學弟,回來的東西都不一樣 04/06 05:37
→ costbook:就算結構對了,行為也不對 04/06 05:37
推 andymai:推~但往往現實不一定是這樣~有時客戶連他自己要什麼都不曉 04/06 12:30
→ andymai:得~好吧~先做一版來看看~再來就是永無止盡的修改~改到最後 04/06 12:31
→ andymai:的架構連他老媽都不認得~能怎麼辦呢? 04/06 12:34
→ andymai:要重構?可以~需求不會因為這個停下~拿你自己的私人時間來 04/06 12:36
→ andymai:好不容易重構了~結果哪天要翻架構~不想罵髒話還蠻奇怪的.. 04/06 12:37
→ andymai:少打~是"當下不想罵髒話"... 04/06 12:39
推 leicheong:可惜是吾讓自己身處險境, 只要你不換工作, 很多時候都 04/06 13:14
→ leicheong:不是自己能決定的. 04/06 13:14
→ leicheong:然後version control只要不是由團隊的直屬上司以嚴法 04/06 13:16
→ qrtt1:我同意這現實存在,但那是 PM 專業程度與客戶教育的議題了。 04/06 13:17
→ leicheong:推行的, 只需要有一個人不按規定checkin, 就會崩壊了吧 04/06 13:17
→ leicheong:你說的這些, 有很多都取決於「老鳥」們是否能把良好的 04/06 13:20
→ leicheong:「傳統」延續下去. 但世代交替間一些已在其他公司染上 04/06 13:21
推 ricky906:說得好!! 04/06 13:22
→ leicheong:「惡習」的人把壞風氣傳入似乎無可避免. 這些人即使被 04/06 13:22
→ leicheong:短時間內處理掉了, 對團隊間仍會做成壞影響的... 04/06 13:23
→ qrtt1:我當然知道有這些困難,但放任下去只是無盡的惡性循環。 04/06 13:25
→ qrtt1:弟之所以回文,就是希望增加良性循環的可能。 04/06 13:25
→ qrtt1:由自己的觀念、行動開始微調。面對限制尋求可能才是活路。 04/06 13:31
→ rofellosx:研發自動寫程式或輕鬆寫程式的程式... 04/06 14:28
→ adrianc:Visual Studio ... 04/06 15:09
→ juriolegend:VS的規則運算式的尋找取代功能很好用的.. 04/06 20:02
推 prag222:我目前沒有時程壓力,慢慢做輕鬆做,進度就超前了 04/06 21:30