蔣さんへ
お返事遅れになっておりまして、本當に申し訳ございませんです。
第1：工作的重心在於溝通，軟體開發的本質是溝通的技術。作為剛開始開發的新員工，一定要記得，有問題就問，而且要知道問問題的ルール、首先應該問身邊的老員工，然後再問擔當，最後向領導匯報，有效的將問題提出和解決，能夠提高自己的工作效率和成果
第2：式樣設計不是萬能的，式樣設計必然會有錯誤，在coding中間，要學會用質疑的眼光發現式樣的問題，然後做好證據，去找式樣確認，千萬不要貪圖自己一時爽快，把問題掩蓋下去，等最後測試時發現問題的時候，問題就會變得不可收拾，當初只要花乙個小時解決的，現在可能要花1天，1周
第3：coding的時候，要注意自己的式樣裡面是不是有共同的機能，這點，式樣不會說明，但是自己要認識到，如果有共同的機能，就要抽出來寫成共同函式，抽成共同函式能減低程式的耦合性，提高程式的結構，以後的再開發和改修都會有好處
第4：寫程式的時候，請一定寫注釋，乙個沒有注釋的程式就不是好程式，不要指望自己能永遠記住自己的程式的含義，如果以後有其他人幫你對應bug的時候，你的注釋就是他的引路燈，但是如果你沒有注釋，你的程式就是別人的惡夢
第5：所有的變數申明要在程式開始的地方寫出來，變數的定義要符合規約，函式名也要，我在日本遇到過乙個日本人寫的帳票程式，因為沒有式樣書，所以我只能閱讀程式，但是程式裡面的函式名字是***x1,***xx2,***xx3這種樣子的，導致的結果就是，乙個4000行的程式，我看了整整3天，最後只能報告日本人，重寫程式。如果是你遇到這種該死的source,你也一定會很不爽，所以，規約對自己和別人都有好處
第6:程式中經常出現bug的乙個問題就是，資料的邊界值，這也是測試中重點測試的問題。打個比方，前面乙個程式，傳乙個[3，3]的陣列給你，結果你在自己的程式裡面，迴圈取每乙個元素，取到了[3，4]這自然是會出錯的，尤其在迴圈的條件判定上面，如果你是用到計算出來的判定值，那就更要小心計算的正確性
第7：程式中間經常出現bug的乙個問題就是，資料型別的轉換，比如在vb.net下面，有這麼一段程式
dim x as integer = cint(a) (其中a是前面傳過來的string)
大家覺得這段程式怎麼樣？
其實有很大的問題，因為在a是空的情況下，這種條件轉換就會丟擲exception
所以正確的做法是
if (a = string.empty) then
x = 0 '具體賦什麼值要看具體的式樣
else then
x = cint(a)
end第8:checkin 和 checkout的時候，一定要小心，小心，再小心。一般不推薦，全體下新版本，很多時候伺服器上面的版本不是穩定的，如果你下來之後，就會沖掉自己的環境。checkin的時候，如果發生衝突，千萬，千萬不要把人家的東西刪掉，加上自己的東西，再上傳。這是一種非常不負責的行為。
第9:做什麼事情都最好在機器做個list，比如今天自己今天改了那幾個配置檔案，再source上面修改了幾個case,這樣如果以後有問題，可以按圖索引，匯報進度的時候也好說清楚
第10：有時候工作的時候，會遇到老員工心情不好的時候，發脾氣的時候，這個時候還是多體諒一下老員工吧。大家都是乙個team，團結才能做好軟體
以上です。よろしくお願いいたします。
給師弟們的一封信
各位 相信各位在歷經了暑假的乙個月後，鬥志和心情都多少受到了不同程度的磨損。我可以理解 明白你們在嘗試找工作過程中一次又一次受挫後的感受。也相信你們在每次歷經這樣的感受之後的那種對自己的勵志和自責。但是，我很想告訴你們 面對現實，面對自己的問題。在這樣的過程中要歷經這麼幾個過程 1.尋找自己的目標。...
架構師給程式設計師的一封信
某architect給他的engineering團隊的寫了一封信 from an architect to a programmer 在信中，結合他20多年在軟體圈的經驗，他為程式設計師提出了9條建議，去做乙個快樂 受人尊敬的程式設計師。酷殼 版主陳皓將這封信進行了翻譯，相信所有程式設計師可以從中學...
架構師給程式設計師的一封信
某architect給他的engineering團隊的寫了一封信 from an architect to a programmer 在信中，結合他20多年在軟體圈的經驗，他為程式設計師提出了9條建議，去做乙個快樂 受人尊敬的程式設計師。酷殼 版主陳皓將這封信進行了翻譯，相信所有程式設計師可以從中學...