大家在寫程式時，會寫得讓接手的人很容易維護嗎？ (第2頁)

JasonEmilly

JasonEmilly
個人積分：0分
文章編號：9188749

0分

11樓

2008-11-28 9:22

libraleu wrote:
程式這種東西，會的人...(恕刪)
最重要的是訓練自己 DEBUG 的功力，這才是最重要的

我很認同libraleu 大的觀念，自己寫程式很簡單，但是看別人的程式去DEBUG，會DEBUG的部分就很重要了!!

當然程式碼也要寫得好，所謂好程式，每個人的定義可能會不同，但是撰寫好的程式碼不外乎是

"註解要記得寫"
"系統規格書記得寫"
"記得寫unit test"
"記得去重構自己或接別人的程式碼"(當然要有時間)

這是我在寫程式一定會做的。

我覺得寫好程式碼，給別人看得懂很重要，那種感覺很好，因為你寫的程式碼及說明很清楚。
況且，如果以後要離職了，至少不會讓接手的人很累，也不要牽扯一些讓自己很累的問題進來。

說到小撇步，這自己就不知道了，因為你自己認為的技巧，覺得很稀鬆平常，但別人看來就是一種小撇步。

ulyssesric

ulyssesric
個人積分：371分
文章編號：9188755

371分

12樓

2008-11-28 9:22

請考慮到一個事實：接手你自己寫的亂七八糟的程式碼的人，可能是你自己。

今天如果你的工作很單純，一直都在維護＆更新某一個相同的程式產品，你可能沒什麼特別感覺。但是如果你的工作會面對許多不同的環境，需要開發多樣化的程式，過了一兩年以後，你自己重新看你以前寫的程式碼，可能都不認得。

而且，你認為一個優秀的程式設計師，應該具備的條件到底是什麼？

我也是寫程式出身，現在在公司裡算是一個低階的小主管，管十幾二十人。我對部屬的要求只有兩個字：紀律。紀律就是對自己的要求，對程式碼品質的堅持。我不會期待一個英雄明星工程師冒出來三兩下解決所有問題，我期待的是你能夠按照我給你的時間資源完成，不要漏東漏西功能缺這缺那，不要一堆找不出來的 Bug，不要每次都要人幫你擦屁股。

一個寫得亂七八糟、別人沒辦法接的程式碼，要是我，我也會整個全部換掉。在現在高度模組化的程式架構中，一包程式碼就像家裡的一台用了十年的老舊電視機。如果這台電視的選台按鈕壞掉了、想修理卻發現需要十種不同的特殊板手才能把他打開，連原生產公司都難以找齊，你會怎麼做？我想百分之九十的人都會選擇把整台電視扔掉買個新的。說難聽點，『程式設計師』本來就是可取代的。你會的東西，別人也會，憑什麼非你不可？

講白了，公司要裁員，如果你的紀律不佳，弄出來的東西別人沒辦法接手，我第一個要裁的就是這種人。

Sar

Sar
個人積分：126分
文章編號：9188762

126分

13樓

2008-11-28 9:23

分享自己的想法, 歡迎大家指教

基本上一個團隊必須先建立該團隊的 coding convention.
否則還不需要有人走, 彼此之間的 coding style 都不相容
那要如何維護龐大的 source code ?

要建立 review program.目的是讓新人更快融入該團隊
1. 請新人 trace 前人所寫的 code, 並且 present 給所有人聽,
一來可以了解該新人的實力在哪裡? 二來可以讓大家順便在 review 之前寫過的code, 看看哪裡可以改進
2. 請新人負責一個新的module 或是 API, 並且present 給所有人聽
可以讓資深的工程師提供建議, 並且指出 coding style 不同之處

然後就是版本控制, 無論是用 CVS , 或是 SVN
所有要commit 的 code 都必須被驗證過, 否則 commit 垃圾進去
到時候造成的 side effort 會很可怕 !
一般都是由該 Project 的 SW Leader 負責 review 該部分的 code.

最後, 就是文件的生成
但是, 很多工程師最討厭的做的, 就是寫文件 (我也是)
所以, 有些好用的工具可以提供給大家
1. 使用 mediaWiki 系統, 可以讓大家有一個比較好用的工具寫 Daily 或是一些 Project 記錄
2. 使用 Bug Tracking system (ex: Mantis / Bugzilla) 追蹤 Bug 修改進度, root cause 為何 ?
其實這些基本的記錄有了, 要寫成文件, 其實也很方便且容易 !

千萬別再說 "The Source Code is the Best Document" , 那會害死人..
除非你們維護的都是 "小型專案"..

當文件寫的好的時候, 就可以請新進員工去 "RTFM" 了 ...
維護成本會比較輕鬆 :-)

May the force be with you!

longan_chen

longan_chen
個人積分：42分
文章編號：9188852

42分

14樓

2008-11-28 9:30

看個人習慣囉

通常寫的模組化及多一些註解

到時候需要修改也好維護

免的案子一多要維護時又要從頭看一次程式(哪有那個美國時間....)

替不替代的問題也不用擔心啦

程式寫的再簡易,註解再清楚,看不懂得人還是看不懂

另外公司裁人有千百種狀況跟原因,不是單純能力好就不會被裁

rchm

rchm
個人積分：351分
文章編號：9188880

351分

15樓

2008-11-28 9:31

tommycheng wrote:
最近常聽說有人一早上...(恕刪)

不要這樣想比較好
如果怕被取代而搞小動作
只是徒留臭名而已
有時候還會成為千古留傳的笑柄
想辦法精進自己的功力才是不被取代的不二法則
而且你想幹一輩子Coding人員嗎
想辦法更上一層樓讓別人來取代你的位子不是更好!?

toadgod

toadgod
個人積分：0分
文章編號：9189161

0分

16樓

2008-11-28 9:51

我想…積極一點…應該是讓自己的能力提升…
直到可以知道人家留的那一手是什麼…
可以快速分析、了解別人留下的爛攤子…
這才是保身之道吧~~~

doco0454

doco0454
個人積分：72分
文章編號：9189749

72分

17樓

2008-11-28 10:33

想想你下次求職時，人資打來問以前老闆，結果換得一句不負責任，粗心大意。

那才會欲哭無淚吧

s8728860

s8728860
個人積分：0分
文章編號：9189773

0分

18樓

2008-11-28 10:35

基本上寫程式，我只管自已看不看的懂而已

別人都看不懂的東西，我也不相信日後你要維護的時候，還看的懂自已寫的東西

kevin__3

kevin__3
個人積分：0分
文章編號：9189933

0分

19樓

2008-11-28 10:45

在寫程式這一行混很久 ,也看到許多專案的起起落落 ,樓主的擔心不是沒有道理的 ,
一般新進員工和老員工 ,差在什麼地方呢 ? 有2個地方
1.經驗 ,新人無法取代舊人過往的經驗 ,老人也常被經驗誤導 .
2.專業技術 ,一般目前市面上的新技術文件 ,每半年推出來 ,老人和新人又是同時學 ....呵呵 ,老人不能懶看文件 .

老實說 ,技術是其次 ,做人才是重點 ,如何和同事"和平相處" ,和窗口互相幫助互相成長 ,替你的上級做一些你可以幫忙的事

.

frankw

frankw
個人積分：680分
文章編號：9190015

680分

20樓

2008-11-28 10:50

這個行業很無趣的，如果你不能把自己的作品當作藝術品看待，
只會愈做愈無力，開心一點工作吧，別想那麼多。

要讓程式沒人願意接手很容易，不要說是沒註解，
就算是有，只要命名亂取，就會讓人想重寫一次，不必這麼費心。

話說程式人員的工作又不是那麼難找，我們這裡如果有人被資遣是要請客慶祝的。