軟體專案開發的實務人員管理-細節, zj0014
version: 2022062401
面試軟體開發人員:從細節觀察
在講專案管理前,我先講個小故事在2021年時我打算買房子,
所以我看了140間的房子。有次我跟一個預售屋建案的工地主任聊天,
我就提問: 「請問你(工地主任)都是怎麼判斷你顧用的工程人員,專業能力是否符合工地需求?」
他用肯定的眼神回答:「細節」。
工地主任指是的做工的細節,就可以判斷這個工程人員,施工的品質。
*你好,如果你是管理職的人員,可以直接跳到「分數表」,直接套用做程式人員管理。
這個管理思維跟軟體專案管理不謀而合
以下就程式碼判斷程式設計師的「施工品質」
在開發大型專案時,大多會組建五人以上的團隊。依照各個專業人士下去分工,且專業人士完工後回報給專案經理,
分析的程式碼的三個重點:
1) 變數命名
2) 註解
3) 程式碼的結構
A. 防呆(輸入資料型別、極大值、極小值)
B. 處理(Big O)
C. 輸出
1) 變數命名,例如:
是否有依照「國際的命名規則」命名變數名稱,像是Java 就有固定的命名規則,像是變數的話Java 採取小寫駝峰(lower camel case):
String setUpNetworking = “”; //建議的寫法
String aa = “”; //不建議的寫法
2) 註解
有良好習慣的程式設計師都會寫註解。
因為寫完程式後,大約二個星期內就會完全忘記自已寫的程式,
所以有經驗的且受過良好訓練的程式設計師,都會在「關鍵」的程碼寫下「註解」。
例如 kotlin 寫法:
val apktxtIp = “”//存放apk txt網址
//判斷外部儲存空間是否可寫入
private fun isExternalStorageWritable():Boolean{
}
3) 程式碼的結構
A. 防呆:
先把傳入的資料進行極大值、極小值、型別的判斷、型別轉換,
用來防止程式碼進行 B.處理 時發生無法預期的錯誤。
例如 C++寫法:
string greatestLetter(string sInputString){
if(sInputString.length() > 1000 || sInputString.length() < 1)
return “Error Input String.”;
}
B. 處理(Big O):
程式碼進行運算處理的部份,一般不建議把for迴圈寫到BigO n的四次方以上,
因為這樣寫出來的程式就算能正常運作,此程式碼的處理的效能會太慢而被放棄使用。
基本上多重for(){ for(){}} 迴圈越少圈越好。當然還有其他的部份像是OOP(Object-oriented programming), List之類的結構化程式碼寫法。
例如 C++ 2層for,程式的運作效能還行:
for(int i =0; i < iLength ;i++){
for(int j =0; j < iLength ;j++){
/*處理過程*/
}
}
C. 輸出:
就是當你的程式已經處理完後,要用什麼型別回傳值給其他程式作運用。
這部份的工作就比較像是系統架構師(SA)、資深程式設計師會做的工作,規劃各個程式之間的溝通介面(Interface)。依照專案的不同,可能回傳List, JSON format之類的,分辦的重點在於介面的可擴充性,以後回傳值是否會有增加、減少的狀況來做討論。
例如:
public List
convertListToMap(List
listIn){
return result;
}
分數表:
可以依照上述的判斷做一個標準,製作成一個分數表。如下
*裡面的數字可以依照專案團隊的需求而改變。
結論:
一個系統專案的成功要有許多要素的構成,才能在期限內完成交件的任務。
寫程式的能力是程式設計師最基本的門檻,
所以才要用上面的表格去分辨程式設計師的撰寫程式的程度,
正常情況專案經理,會要求的是能實戰寫程式的人員,因為大部分的求職者都不會寫程式。
在過去十六年開發專案時我遇過多種的狀況,
像是兩個程式設計師個性不合互相打架,我也有遇過寫一支程式寫兩個月寫不出來的程式設計師,
或是個性固執且無法跟團隊合作的程式設計師,各種情況都有。
以上是我的專案經驗分享,希望這些資訊對你有用。
關於作者:
Billour Ou
歐育溙 的資歷
簡歷:
Google Technical Lead 面試邀請
Yahoo bid, 百萬成功賣家
台灣教育部 DSP 競賽全國, 第一名
2022/6/24
參考