• 17

請教在軟體業界的版友

tsaipifong wrote:
後幾句話看起來似乎成品都沒有文件,也沒有註解似的...
我不相信把文件及註解寫清楚詳細會造成code只有自已會維護的狀況
除非是文件及註解寫得太簡略或其他工程師程度真的差到看不懂

其實說真的從你一位資深工程師口中提出這些觀點
我是一點也不意外
因為這些都正是我從許多資深工程師身上看到的問題


實務上,不是所有系統的程式都有文件

我們都有規定程式的文件,有的甚至要寫wiki給其它team來參考

但事實上,文件都是跟在後面補,有空的補,沒空的就沒有文件

很怪嗎? 很正常,特別是公司的內部開發團隊,不是在賣軟體

還有,這些都跟公司開發團隊的大小有關係

當你的團隊大,還有一堆QA team的人,甚至養一堆人寫文件,可以這樣做

但是如果沒有這麼大的規模,根本就沒有太多要求文件的空間

況且,文件寫的東西往往多是spec或需求,頂多將相關系統關係做描述,

好比用哪些service,有哪些DB info

內部邏輯未必能展現在文件當中

還有,我不只是個資深工程師,我也是principal兼manager,我底下帶team,

公司很多開發的規定也是我在定,可是定再多規矩寫再多文件,東西只要一趕,根本很難實現

很多公司都是如此,包括一些相當大的公司如 IBM,或者美國數一數二大的銀行的內部開發的team

文件很多都還是事後才在補,並不是都是先寫文件再來開發 (剛巧有認識的朋友),而且還是有空才補

這就像當軍人有用槍程序要背,但上戰場時,往往很多只能先抓重點,

因為你的team寫完文件時,人家的team已經寫完project了..

但文件重不重要? 當然還是重要,特別是business requirement document,

但這個不是你程式邏輯的document,靠它,不是每個工程師都能養別人的project.

而且你真認為我丟一本文件給你,你就能養人家的code或者寫一套類似的東西出來嗎?

對我來講,要離職或請長假的工程師,我會盯他的文件要補齊,天天上班的工程師負責的項目,我會跟他們一起review code看有沒有錯的用法,因為我根本沒空去看那些文件,文件也包括不了太多程式邏輯


另外,你說不能怕犯錯而不做

但問題是,根本沒空做,要做就要花時間,你要做還不一定准你做,因為系統上線會要許多人測,要有很多關卡,不是僅一個工程師自己的事,你改一個東西也可能影響別人的系統(好比改動你的service),這都可能是風險

而且每個人都有一堆手上的案子在進行,系統做維護與更新不是做不到,是看公司的team有沒有那樣的空閒時間

在大家在現實環境下會把資源放在重點上的時候,就很難做到舊東西的改寫了

(你有看到戰場上正在守陣地打仗的士兵們同時忙著在改建工事的嗎? 特別是大敵已在眼前的時候)

而且以一個manager的角度,每年每季一個team都有一堆工作項目要往上報,

改寫系統除非有明顯的效能,否則很難讓高層認同是可以花費時間的工作項目,你寫太專業,高層也看不懂

老闆只覺得,東西好好的,你動它幹嘛? 沒事幹了嗎?

萬一改完造成其它team系統的問題,還可能被罵翻,這是很現實的問題

(有的並不是舊的做法錯,而是有新的做法,但有沒有需要為了一丁點好處去改呢? )
Mainline Pocket wrote:
看公司的水準...(恕刪)


jvm 自已寫?你是在ibm 還是 微軟上班 ?為了喝牛奶養一條牛,還不太好養。你應該是公司有自己的framework吧!而不是自己的jvm吧!
kevinant2 wrote:
不是每家公司都有那麼精明的領導,這要看公司的領導是否利害(怎麼大家都碰到那麼好的公司?)
...(恕刪)


當領導也是要學習的。

kevinant2 wrote:
一上任之後就必須處理之前畢業生所造成的一堆問題,最好的方式是全部重弄,但是老闆並不同意,所已經歷過這些,我深深了解如果沒人帶用廉價請畢業生的痛苦。
...(恕刪)


這個問題不見得是廉價的問題,而是請了個沒經驗的人要他獨立作業。


kevinant2 wrote:
我們是用JSP做的系統是借貸金流系統,然而當中需要設計很多借貸所需功能,但是因為這才是我第一份工作,所以我其實對業務也沒多少了解,所做出的功能需求皆是憑空想像,甚至有些東西及觀念要老闆跟我解釋我才了解。

至於說Framework,他們一直題我也不知道是瞎密,我只之道我用PHP開發網站的時候不需要任何Framework,甚至還有人跟我說需要Framework他們才會寫,反正當主管的只要把需求丟出去叫他們去寫就好了。
...(恕刪)


我避免用術語,拿你懂的PHP爲例,一般沒受過訓練的會把所有的東西(logic, data)與UI (html)混在一起. 以前很受歡迎的一個架構是 3 層式的, 1. data 2.logic 3. html 是分開獨立,各層可以在不同的機器上做。

這裡提到Java框架的目的,基本上是套用類似的架構在加上軟体上其他的架構進去。 架構中物件與資料庫的對應關係是由XML 表達。

如果你是用JSP (HTML), 正常的話,應是與 Java(logic, data) 混用的。 這裡提到的Framework的目的是要強制使它們獨立。 這樣UI/HTML 可以改變也不會牽動其他部分。

如你有一點基礎,這些 Framework 其實不難,你可以去看看的。 PHP 也是有Framework , 只是你沒注意到。

比方説假設 php 的框架的一層,你就看不到HTML

// 這是表達對應關係

$app->get('/register', 'regsiter');
$app->get('/login', 'login');

funtion register() {....}
funtion login() {....}

//這是執行
$app->run();

//類似的 Java 框架可能變成
<!-- xml -->
<mybean class="somejavaclass">
<path value="/register" call="register" />
<path value="/login" call="login" />
</mybean>

//java
public class somejavaclass {
public register() {}
public login() {}
}

如你說有人需要Framework他們才會寫,因爲他們用Framework 看到的是Object,可能沒接觸過低層的SQL,或是JDBC. 他看到的只是樹林裏一棵樹

想像當你的資料庫也是這樣處理, 做出一個完整的程式之後,東西多了後, 還要經過的轉換步驟,就變成很瑣碎。有1/5在寫XML,如果是用IDE可以幫助。 php 簡單多了,只要一個text editor 就搞定

你說這些東西難嗎,如果我以上說的是正確的,我說了解一點都不難。 看你願不願意花時間去看罷了。另外,拜謝微軟的發明,今天的 3層式架構的 html 可以在客戶端做。事實上,你做的好的話,2,3層可以有不同的版本同時並存。
wangccw16 wrote:
jvm 自已寫?你是...(恕刪)


我當時這個公司的同事,光被百萬美金現金挖角的就有2個。

tsaipifong wrote:
我就看過很多資深工程師寫出下列這樣的null判斷...(恕刪)


我覺得這樣的判斷很合理阿

你怎麼知道別人在呼叫你的方法時
傳入的參數是否正確?
tsaipifong wrote:
public String myMethod(String arg)throws Exception{
if(arg==null){
throw new Exception("arg is null");
}
return myService.doMything(arg);
}

我認為這樣的code有沒有問題,不能只單看這一小段
例如流程分析可能如下
1. 檢查參數是否為空值(若為空值則拋出NullPointerException)
2. 呼叫Service做doMything
那麼程式可能如下

public String myMethod(String arg)throws Exception{
checkNull(arg);
String ret = myService.doMything(arg);
return ret;
}

private void checkNull(String arg){
if(arg==null){
throw new NullPointerException("arg is null");
}
}

在多數時候,經過前置參數檢查後
後面的doMything的行為內是不會再寫檢查的
而且不會把參數檢查合併入doMything行為中

tsaipifong wrote:
這也是我所提的一個重點
很多人擔任了主管之後,認為看事情的角度不一樣了
漸漸的忽略了技術層面而交給底下的工程師去搞
..(恕刪)


這也許是工作内容的問題。如果專業夠的話,情況會不同。 在國外有點規模的的軟體公司都會有2條平行升遷的路。 很多PM都不是寫程式出身的。 在這種公司,PM的工作除了外代表部門,對内有潤滑油的性質,讓工程師能夠專心開發.

你針對的是軟體開發,那拿微軟為例好了。如果微軟要開發一個C++的編譯器,你認爲PM會比工程師還懂 C++ 語法及類似的問題嗎?微軟會由PM 來”交給底下的工程師去搞“嗎? 在這種請況下,工程師往往比 PM 值錢。另外考慮,為什麽要"升“一個能力很強工程師去做PM? 如我是老闆,我巴不得他繼續幫我做他“很強”的事。 我記得比爾蓋玆最後工作的頭銜是software architect. 他離職後為什麽請了一個外面的人當software architect?

專業夠的話,PM是無法了解你能了解的東西(我說的不是框架之類)。 開會時,PM 常提醒我有需要什麽跟他說,他會幫我解決。 我現在的PM 也是經驗豐富的博士。 如果你能“own”你所做的產品,公司未來方向,老闆最需要的是工程師。

我們必需了解, 工程師不是只有寫 code。 好的工程師是花很多時間在 ”想“ 上面。 工程師如果想主宰自己的產品,必需要脫離“學”與“會”的想法而進入到“創造”。
tracer1000 wrote:
實務上,不是所有系統的程式都有文件


就這句話其實已經解釋你的開發團隊所遭遇的一切問題了

若有一天,你的團隊把文件看得比趕程式重要時

相信會有更好的突破

在這之前,只要有客戶跟你要求照著文件驗收系統

就吃不完兜著走了

能撐到現在覺得你對付客戶很有一套…

文件不全居然也交付的出去… 厲害
shukae wrote:
在多數時候,經過前置參數檢查後 後面的doMything的行為內是不會再寫檢查的 而且不會把參數檢查合併入doMything行為中


這code本身不會對結果造成問題
只是在於寫的人不知道
這個method不做null判斷
也不會讓任何nullpointerexception從這個method產生

null判斷與否並不完全是你說的那樣
有興趣的話,建議私訊討論吧
因為細節偏離開版的主題了

hank78 wrote:
我覺得這樣的判斷很合...(恕刪)


因為就算沒有那個null判斷
也不會因為arg==null,而有任何的nullpointerexception從這method產生
這部份由於有偏離主題了,建議可以私訊討論
  • 17
內文搜尋
X
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 17)
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?