從軟體開發產業進入到User端。
原本的工作以系統開發較為吃重,而現在,所有的工作將以維護為主。
開發的時候,我認為寫程式寫軟體是一種美妙的藝術。
什麼重構、預構、Design Patter等等,都是精華。
我認為這些技巧的專研,是寫程式的樂趣之一,並且樂此不疲。
現在角色換了。
修改bug,修改功能,增強功能.. 在現有的系統上做增修。
維護現有的系統,不比開發新系統來得容易。
首先遇到的問題是:要看懂別人的程式。
別人寫過的程式不會是依照著自己所能接受的”規則”進行。
這真的是一件苦差事。尤其是在沒有文件,沒有註解,甚至沒有良好的命名、架構的情況之下!!!
常常一邊看一邊搖頭:
天哪~怎麼會有人這樣寫程式?
這樣亂搞?怎麼可以用這種方式命名?
怎麼可以隨便加個IF else就敷衍了事?
這時候真的會很想很想去整理這些程式碼。
在ptt的版上看到有人說:
作者 XXX (火辣辣的大姊姊)
標題 Re: [心得] 如何向別人證明自己寫的是好code?
以前認識一位40幾歲工程師他隨口說過一句話:
"要寫code很簡單 要看得懂別人的code很難"
後來自已的體會是:
自已寫code的過程時間過得很快 而看別人的code很慢、很悶、很煩
所以 你說你想跨入更高的境界 一定要試著看懂別人的爛code
俗話說:爛code三尺 非一日之寒 有好code可以寫 誰想寫爛code
你自已文中也說了 你待的公司必須要反應迅速 依客戶要求修修改改也很正常
這種情況下 就算一開始架構良好的code 隨著維護的人一代換過一代 到你手上不爛也難
有人說 寫code是一門藝術 我覺得code是一部歷史 裡面有很多歷史因素藏著前人的心酸
你知道你維護的code在兩年前發生過必須在三天內調整架講的窘境嗎
當個事後諸葛批判前人很簡單的啦
但你看得出來某段正確卻不合常理的code背後的玄機嗎
標題 Re: [心得] 如何向別人證明自己寫的是好code?
以前認識一位40幾歲工程師他隨口說過一句話:
"要寫code很簡單 要看得懂別人的code很難"
後來自已的體會是:
自已寫code的過程時間過得很快 而看別人的code很慢、很悶、很煩
所以 你說你想跨入更高的境界 一定要試著看懂別人的爛code
俗話說:爛code三尺 非一日之寒 有好code可以寫 誰想寫爛code
你自已文中也說了 你待的公司必須要反應迅速 依客戶要求修修改改也很正常
這種情況下 就算一開始架構良好的code 隨著維護的人一代換過一代 到你手上不爛也難
有人說 寫code是一門藝術 我覺得code是一部歷史 裡面有很多歷史因素藏著前人的心酸
你知道你維護的code在兩年前發生過必須在三天內調整架講的窘境嗎
當個事後諸葛批判前人很簡單的啦
但你看得出來某段正確卻不合常理的code背後的玄機嗎
你會重構 別人就不會嗎?
你重構後的程式架講良好 bug少 別人重構架構會不好 bug會多嗎?
你重構的原因不是基於希望以後維護容易 而是 "後來逼不得已放手一搏"
有人肯為程式重構是不錯 但我看不出你這基於不得已的選擇有多值得驕傲
許多的設計藝術,在現有的系統中是沒法子落實的。
理想與現實狀況有落差
就像是一種迷信,並不會有完全解決問題的設計方式
足以讓所有的程式設計師可以快速地維護修改,甚至擴充!
雖然不能接受,但仍然必須面對。沒有人想寫爛code。
因為即使實現了重構,日後維護的程式設計師 也不見得輕鬆。
因為他必須先學會使用這個新架構。
在人員流動性大的資訊業,並不見得是加分。
我還是覺得寫軟體是一種藝術。應用這些技巧可以幫助自己練功,
並且在設計的過程中找到趣味。
而接受及沿襲別人的老程式,也是自己必須學習的課題之一。
*
有一本書我滿推薦的- Code Complete 2
簡體版的翻譯是:代碼大全(NT:380), 繁體版的是:軟體建構之道 (NT:1200)
不過這本書真是棒,從軟工到如何寫code,構建整個軟體專案該注意的事,它全寫了。
對我來說這本書有點像是軟體工作指南,反反覆覆地看它,用上個八九年應該不成問題。
原則事項不少,沒有些許專案經驗的話,還不能全盤了解呢!
(OS:繁體版的真貴~ ><)