一個程式設計師的千年決心 (轉)

一個程式設計師的千年決心 (轉)[@more@]文章比較長，希望你能耐心讀完, 相信對你會有幫助。

在2000 年1 月1 號的零點。不管在1 999 如何如何，依然有電，水還在流，世界上的金融仍在加加減減的正常執行。這已經是新千年的開始，但你仍要作些新年誓言。是的，你可以發誓減肥或是更多的在外工作，但你是否可以持續一到兩週？不如作些承諾改進做為專業人士的職業生涯吧。請仔細想想以下的一些決定:

我不妨礙他人。你不應只想玩玩，就使用技術。你用技術，因為這合情合理，或對解決在手邊的問題有用。許多開發者僅僅為了獲取而建議使用如 （Enterprise Beans ）或COM+等流行的技術。你是在浪費你老闆的時間與金錢來實現自己的目標。另外，不要為了揭示你的單位軟體結構的弱點而引入，或刪除資料或。如果真的有弱點，通知管理層，不要造成任何損害。

我會適當的重用任何可重用的東西. .. . 因為大家喜歡從零開始，而不是重用已有的成果，這些年，軟體專業人士的生產率並沒有顯著的提高。有很多的軟體成果可以被重用，如原始碼、部件、文件、文件模板、模型甚至透過應用重用其他人的技術。只要可以，就去致力重用其他人好的工作成果，而不是假設你可以從零開始做事，並比其他人更好（不幸的是，這正是許多一般開發員的心態）。現在，重新發明“輪子”，並不是一件榮耀的事。

我只開發基於實際需求的軟體。如果你沒有需求，你不需要開發任何東西。無論什麼型別的系統，你總可以從為它定義需求開始。人們或其他系統如何使用你的系統？它需要怎樣好的？它必須具有什麼樣的使用特點？它必須在什麼平臺下執行？不管你的系統使用什麼技術，它是什麼樣的業務型別，你總可以先確定它的需求。其他都是乾咳。

我會在編碼前先建模. .. . 最有的開發員會首先建模，並只有在他們認為完全理解了要做什麼了後，才會開始編碼。你在建模上的精力或許簡單如只是在餐巾紙上畫幾幅簡圖，或是複雜如使用業界領先的CASE 工具畫出一整套圖形。其中的含義，非常簡單：先想，後做（運籌帷幄）

你要能夠辯明你的工作. .. .你為什麼正在開發你的系統或相關部分？你是否知道它技術上的可行性？是否其他人做過該類原型，顯示出你正在做正確的工作。你的軟體在經濟上有意義嗎？它是否值得去做，是否可保持你的組織的競爭力或開啟新的市場？一旦你開發的產品完成後，是否你的組織能夠操作它？你是否有一些人可以操作並維護該系統？是否可以得到操作規程和文件？是否有支援計劃？如果你不能辯明你的工作，為什麼你還在做它呢？

我會停止重複教條. .. . 給予專案組最大損害的是那些相信如：資料至上，編碼最重要，或是我們是用例等一些小教條的人。非常複雜，這些教條只是覆蓋了對於過程的缺乏理解問題。實際上，資料只是整個過程的一個小部分；而為了使軟體成功，需要的不僅僅使原始碼；對描述需求來講，僅有用例是不夠的。教條只是在人們之間建立了阻礙，並減小了小組的成功機會。

我會從不同的角度來看工作. .. . 不管你在專案中的角色，你應總是同時針對幾個相關部件。業務分析員在調查問題域時可以開發介面、用例和領域模型。建模者在設計軟體時可以開發順序圖、類模型、部件模型、狀態圖和資料模型。程式設計師在實現軟體時可以編寫程式碼、測試用例和編寫原始碼文件。只關心一個產品部分，或是專案進度、或是使用者介面原型、或是原始碼或資料模型，將經常導致釋出結果達不到軟體總體需求。

我不僅僅關注軟體的執行. .. . 成功開發不只是做出執行速度快的軟體。根據專案的型別、級別不同,建立可擴充套件、可理解、可維護、可用或重用的軟體也許更為重要。軟體執行速度僅僅只是軟體評價標準的一方面，但是太多的開發員只注重該項，而影響了他們整個的工作質量。

我會尊重客戶並同他們緊密協作. .. . 你開發軟體的唯一理由是為了支援客戶。只有客戶能夠告訴你他們需要什麼，因為他們是業務領域的專家。為了保證你建立正確的系統，與客戶緊密工作難道不是非常有道理嗎？

我只接受符合實際的專案計劃. .. . 組織或市場的壓力經常導致專案計劃不符合實際。無論何時，只要使用“如果每件事都按我們估計的方式發展，而且我們足夠幸運的化，我們就可以將專案作好”來闡明計劃的話，那你就有麻煩了。事情不總是按你想象的方式進行，不管多少人力投入一個專案，許多軟體的開發的不同工作都會耗費非常大量的時間來完成。記住，九個女人也不能在一個月裡生一個孩子。如果你迫於壓力，接受了一個不切實際的專案計劃，那麼你必須回去向老闆闡明計劃不實際的原因。你的理由也許不被接受，你還得執行該計劃，但至少你為專案進行了爭取。有不現實計劃的專案組常常時採取了捷徑，但卻導致專案在遠遠落後於進度時，專案仍在停步不前。

我會持續改善我的溝通技巧. .. .如果你不能與其他人有效溝通，好點子又有什麼用呢？你也許可以寫出世界上最好的源程式，但是，你不能寫一封E-來告訴你的老闆與小組成員你所做的，那麼你的傑作可能根本得不到承認。

我會養成學習的習慣. .. .在你躺在你的榮譽上時，軟體工業的技術與技巧在飛速改變。試著每月讀幾本相關雜誌或至少一本技術書籍。我曾經接受到的一些最好的建議是擴充套件視野，並讀一些商業雜誌。商業相關的閱讀使你具有同使用者聯絡的背景知識，它是成功的一個關鍵因素，因為軟體是為支援使用者的使用而開發的。參加與工作有關的課程或會議也應是你學習過程的一部分。

我要測試所有我開發的. .. . 如果你可以構建，你也可以測試。你可以透過檢視需求文件、設計、並執行多次測試來檢測程式碼。如果一件事不值得測試的話，那麼為什麼還要做它呢？

我要文件化所有我開發的. .. . 現代軟體開發模式是你做為一個小組成員進行工作，如果沒別人能夠理解你的工作，那你就沒有對工作做出任何貢獻。很明顯，好的文件能使你的工作容易被理解。實際上，簡而言之，好的程式設計師在開始編碼之前，會文件化他們的程式碼。

我認同軟體不僅僅是技術. .. . 技術是有趣的，但它只是開發軟體過程中的很小一部分。不管是好是壞，你的工作需要你熟練地與使用者、經理、同事、賣主或操作人員打交道。

我認為軟體不僅僅是開發. .. . 你必須牢牢記住，你的使用者，或是你的上層經理，在你開始工作前，很可能已經花費了極大的精力來挑選和識別軟體開發專案。一旦你將軟體釋出給使用者，該軟體必須要被維護、使用和支援。你需要全面理解如何成為一個有效率的專業人員。

你正在新前年的開始，一個獨一無二的歷史時期，幾乎每個人都在迷惑如何看日曆。你可以或是以頭撞牆來向其他人解釋，2000 年是千年的最後一年，不是新千年的第一年，或是放棄解釋，將注意力轉向改進你的軟體開發技巧。依從我這裡的一條或幾條建議將給你帶來成功，同時需要指明，經常去去體育館也是個不錯的主意。