我說的培訓不是單位的正規培訓，是在實際工作中如何提高開發人員的開發素質，從而達到改善開發流程，提高軟體質量，降低開發風險的目的。上回說了乙個測試人員 小a的培訓，在說說另外乙個例子。小b的培訓。
小b是乙個開發人員，按道理來說他的培訓不應該由我們負責，但他和小a是好朋友。在7月剛參加工作的時候和小a一起測試過系統，平時也經常和我們在意思，所以他問一些開發的問題。我們自然會回答。
在7月份小b參加了乙個系統的測試後，一直沒有專案，主要是自己學習，期間也和我討論過開發的問題，但我總覺得給他講了很多，但他接受的並不是很多。效果很差（個人認為原因有三，乙個是沒有真正的專案，而他的開發經驗比較少，很多東西很難接受，二沒有專案，很難實施很多軟體方法，而其中的好處也自然理解不了，三沒有專案的情況下，很多時候是只講解理論，而不能和實際結合起來，沒有例項很多問題很難講的清除）。
小b終於上專案了，開始他很興奮，（剛開始工作的同志都是這個樣子）。但很快，他就眉頭緊鎖了，緊接著就開始瘋狂加班了。兩周的任務在快到中間的時候，他越來話越少了。周五下班的時候，看他還在奮鬥，於是過去打了乙個招呼。小b仍然是眉頭緊鎖。看他那個難受的樣子，於是決定幫他除錯一下**。除錯的開始，首先是把他的**規範化，很簡單，就是層次之間空四個格。他原來的**一看就是沒有經過這種練習，所以**層次寫的很亂，從格式上很難一下分清**的層次結構。經過十分鐘的排版，程式**的之間的格式很整齊，語句之間邏輯結果也明晰了。很快就將一些語法問題解決掉了。然後是問他處理流程。讓我生氣地是，他對處理流程不是很清楚，很多時候都是想當然。於是我讓他講所有的處理流程分層次寫一下。小b一臉疑惑地看著我說：「這麼簡單的程式還要寫文件呀」，我告訴他就是因為他少寫了文件所以他現在才掉到坑里出不，看他一臉不樂意的樣子，我說，我來大致的寫一下，1程式要從session裡讀引數，2根據從session裡多的引數從系統資料庫裡獲得主表資料，然後根據這些資料在到資料庫查詢從表資料，3根據所有從資料庫中查詢結果顯示。根據這個大致流程，系統可以分成三個大模組，1從session讀引數，2從資料庫讀資料。3顯示資料三個部分。而2有可以劃分為2.1從主表讀資料。2.2從從表讀資料。功能模組有乙個大致的劃分之後，就要確定介面引數。1到2之間是乙個字串，2到3之間是乙個二維結構的陣列。2.1到2.2之間傳入的是乙個字串。傳出的是乙個一維資料。整個系統被分成四個函式，每個函式都有專門的用途，這樣結構基本清楚。而小b將所有**都寫在一起了，**行過大，除錯起來很困難。我建議小a先按照這種劃分將函式編寫完畢，然後再作其他處理。讓我高興的是小b拋棄了他原來的**，按照新的結構劃分設計了他的**。而且**嚴格按照層次之間空4個格的方式，新**的邏輯結構很清楚。但令人奇怪的是新寫的**確總是出問題。問題的症狀是無法從資料庫中獲得正確的資料。於是我們開始除錯這段**。
首先，我告訴小a，**的除錯，最重要的是縮小問題的範圍。我首先將第乙個函式的內容註解掉，然後寫了乙個賦值語句，假設從session中獲得了資訊。然後再逐步看**的執行。在系統生成sql查詢語言的時候，將這段生成的sql語言cut下來，然後放到，oracle的client端的sql環境中去執行。sql語言可以執行，這就證明了構造sql語言是正確的。但sql語言的查詢結果集卻是有問題。於是我又去看資料庫的結果和儲存的內容，這才發現原來資料庫的設計有問題（具體問題不說了，簡單說就是違反了資料設計的單一性）。所以必須經過一些特殊的處理才可以使用這些資料去構造下邊的子表資料的查詢sql語言。但由於主表的結果是公用的。所以我們不能修改這個表結構。問題找到了。解決的方法也就有了。小b又開始了奮鬥，半小時，基本搞定。本想回家了，小b卻不幹，非要請我吃飯，順便想在問問開發的問題。這麼好的同志，我怎麼可以拒絕。於是將自己的一些想法和小b說了說。
首先，我建議他寫一下設計報告。很簡單的道理，他幹了四天半，系統一直有問題，而後來因為我們總結了系統流程很多問題立刻就暴露出來了，於是我們只用了半天就解決了問題。所以很多資料說編碼工作的工作量只佔這個開發工作量的10%是很對的。當然，基於小b開發的實際情況，我將以他這回先補設計報告，這麼做雖然不正規但也是亡羊補牢。下回可以先寫設計報告，哪怕只是在紙上畫乙個大致的框架也好，到第三個系統的時候就要先寫設計，在編碼了。這樣一步一步來，有2，3個月的時間，他就會熟悉先設計在編碼的方式。
其次。我讓他注意一下編碼規範的問題，這個問題說大不大，說小不小，好的編碼規範，**之間的層次清楚，可讀性，維護性都很好。包括函式的行數限制（函式行數最好20-40行，不要超過60）。變數定義的時候一定要初始化，變數名的如何取名。當然問題很多，給了他一本講**程式設計規範的數--**大全。
另外乙個是體系的設計問題，比如我們的遇到的問題，其實是系統設計問題（雖然我們不能修改它，但不能證明它就是正確的），當初設計的時候沒有遵循資料庫設計的規範，為以後的工作添了很多麻煩。
剩下的就是工作方**的，比如如何除錯，如何做設計，如何寫**，其實方法都一樣，就是將複雜問題進行劃分，分成若干小問題。逐步解決。
關於小b的培訓，有幾句要說的。
1因為我現在不管理開發，所以對他的培訓是一種私人幫助性質的，而如果是正規的培訓效果會好很多。
2培訓首先要讓被培訓的人認識到培訓的必要性。比如我在原來開發人員的培訓工作中會先給他們兩周作乙個系統。然後對這個系統進行測試。一般來說沒有開發人員能把這個系統開發的很好。
3培訓要有針對性。在系統測試完之後，第一步，是針對問題，講解問題出在什麼地方。這需要對開發比較熟悉（可以不熟悉開發語言，但一定要有很強的編碼經驗），幫助開發人員發現問題。其次，講解編碼的開發規範，比如層次之間格、函式的長度限制、寫註解的方法、變數說明之後一定要初始化，資源的釋放，一般掌握這些最容易犯錯誤的問題之後。開發人員的開發的**的質量會提高很多。
4培訓要分層次進行。首先是講解編碼規範，然後是講解設計的方法，這是很重要的，在學校了都講解過調研、概要設計、詳細設計、除錯但卻很少實踐，在實際工作如何使用這些東西往往是開發人員所欠缺的。在講解完程式設計規範後，我會要求開發人員編寫詳細設計報告（不必在修改錯誤的**），然後採用走查的方法通過詳細設計報告發現他們設計的問題。然後是概要設計報告，需求。這裡要說明一點，正規的開發流程應該是先出需求報告，再概要設計、詳細、編碼，而我之所以反其道而行之，主要原因乙個是開發人員比較好接受（他們習慣編碼，而對設計很陌生），其次，讓他們了解各種報告需要些什麼東西。比如他們如果實現了乙個資訊管理系統，讓他們寫詳細報告的時候，如果沒有定義資料輸入域的長度，我就會問他為什麼這個輸入域在編碼的時候長度為10而不是12或8，並告訴他這些東西應該在詳細設計報告中寫出來，（編碼的依據是詳細設計報告，不能憑空自己決定）。同樣的原理，資料輸入長度在概要設計報告中也要寫明，而最終這個資訊是要在需求中寫明的，最後明確告訴開發人員，需求報告是寫概要設計的唯一依據，概要是寫詳細的唯一依據，詳細是編碼的唯一依據。採用反寫報告的方法雖然不符合開發的實際情況，但卻可以讓大家對各種報告中應該寫什麼內容有乙個比較明確的認識，對以後的寫各種設計報告很有幫助。
5要讓被培訓的開發人員了解開發的基本原理和方法，只是乙個最困難的事情，比如無論是寫設計報告，編碼，和疑難技術問題的解決其實都是採用分解的方法，拿些報告來說，我要求他們先寫第一類標題，全寫完了再寫第二類標題，然後是第三類標題，解決疑難技術問題的時候，現想明白處理的大致流程，讓後把流程中的每乙個步驟細化（逐步細化，不要一步到底），調研的時候也要求他們先搞明白框架，在逐步細化，這樣做乙個保證工作的完整性，其次降低問題的難度。層次關係也比較清楚。（這些實際工作經驗不知道為什麼學校裡都不講）而在實際工作是最有效的工作方法。
6對被培訓的人員要耐心，基本上每乙個新開發人員都有自己的壞毛病。而改正這些毛病是很痛苦的事情。特別是在他們沒有了解這些毛病的危害的時候，要一次讓他們改正乙個毛病，並鼓勵他們堅持下去。
工作隨筆 xshell4安裝後應該做的一些事
xshell4預設支援中文語言 選項 鍵盤和滑鼠 設定快捷鍵，滑鼠按鍵 可以提高工作效率 1.選定文字自動複製到剪貼簿 選擇 將選定的文字自動複製到剪貼簿 選上 2.更高滑鼠中間按鈕和右鍵按鈕的功能 滑鼠 根據自己的習慣選擇 本地shell 檔案 屬性 修改缺省會話屬性 1.修改遠端主機的編碼 終端...
為什麼一些結構中尾部陣列的大小是1？
一些windows結構都是可變大小的，乙個固定大小的頭之後是乙個可變大小的陣列。當這些結構被聲名的時候，陣列大小都宣告為1，舉個例子 typedef struct token groups token groups,ptoken groups 如果你看這個標頭檔案，你將看到這個anysize arr...
作為應聘者 面試結束時應該問面試官一些什麼問題呢？
幾乎所有的面試在結束時候都會留一些時間給應聘者來提問問題，不少應聘者都以沒有問題來結束了整個面試過程，其實我感覺這個提問時間還是大有用處的，正確的問一些問題不但能讓你對雇主有更好的了解，更有可能為你的面試加分甚至影響面試結果。那到底應該問一些什麼問題呢？以下是我個人的一點意見，希望能給大家有所幫助。...