在新千年的開始,讓我們花點時間為自己的事業下點決心。
在2000年1月1號的零點。不管在1999如何如何，依然有電，水還在流，世界上的金融系統仍在加加減減的正常運行。這已經是新千年的開始，但你仍要作些新年誓言。是的，你可以發誓減肥或是更多的在外工作，但你是否可以持續一到兩周？不如作些承諾改進做為軟件專業人士的職業生涯吧。請仔細想想以下的一些決定:
我不妨礙他人。你不應只想玩玩，就使用技術。你用技術，因為這合情合理，或對解決在手邊的問題有用。許多開發者僅僅為了獲取經驗而建議使用如EJB（Enterprise Java Beans）或COM+等流行的技術。你是在浪費你老板的時間與金錢來實現自己的目標。另外，不要為了揭示你的單位軟件結構的弱點而引入病毒，或刪除數據或程序。如果真的有弱點，通知管理層，不要造成任何損害。
我會適當的重用任何可重用的東西. 因為大家喜歡從零開始，而不是重用已有的成果，這些年，軟件專業人士的生產率并沒有顯著的提高。有很多的軟件成果可以被重用，如原代碼、部件、文檔、文檔模板、模型甚至通過應用模式重用其他人的技術。只要可以，就去致力重用其他人好的工作成果，而不是假設你可以從零開始做事，并比其他人更好（不幸的是，這正是許多一般開發員的心態）�，F在，重新發明“輪子”，并不是一件榮耀的事。
我只開發基于實際需求的軟件。如果你沒有需求，你不需要開發任何東西。無論什么類型的系統，你總可以從為它定義需求開始。人們或其他系統如何使用你的系統？它需要怎樣好的執行？它必須具有什么樣的使用特點？它必須在什么平臺下運行？不管你的系統使用什么技術，它是什么樣的業務類型，你總可以先確定它的需求。其他都是干咳。
我會在編碼前先建模. 最有效率的開發員會首先建模，并只有在他們認為完全理解了要做什么了后，才會開始編碼。你在建模上的精力或許簡單如只是在餐巾紙上畫幾幅簡圖，或是復雜如使用業界領先的CASE工具畫出一整套圖形。其中的含義，非常簡單：先想，后做（運籌帷幄）
你要能夠辯明你的工作. 你為什么正在開發你的系統或相關部分？你是否知道它技術上的可行性？是否其他人做過該類原型，顯示出你正在做正確的工作。你的軟件在經濟上有意義嗎？它是否值得去做，是否可保持你的組織的競爭力或打開新的市場？一旦你開發的產品完成后，是否你的組織能夠操作它？你是否有一些人可以操作并維護該系統？是否可以得到操作規程和文檔？是否有支持計劃？如果你不能辯明你的工作，為什么你還在做它呢？
我會停止重復教條. 給予項目組最大損害的是那些相信如：數據至上，編碼最重要，或是我們是用例驅動等一些小教條的人。軟件開發非常復雜，這些教條只是覆蓋了對于過程的缺乏理解問題。實際上，數據只是整個過程的一個小部分；而為了使軟件成功，需要的不僅僅使原代碼；對描述需求來講，僅有用例是不夠的。教條只是在人們之間建立了阻礙，并減小了小組的成功機會。
我會從不同的角度來看工作. 不管你在項目中的角色，你應總是同時針對幾個相關部件。業務分析員在調查問
題域時可以開發用戶界面、用例和領域模型。建模者在設計軟件時可以開發順序圖、類模型、部件模型、狀態
圖和數據存儲模型。程序員在實現軟件時可以編寫代碼、測試用例和編寫原代碼文檔。只關心一個產品部分，
或是項目進度、或是用戶界面原型、或是原代碼或數據模型，將經常導致發布結果達不到軟件總體需求。
我不僅僅關注軟件的執行. 成功開發不只是做出執行速度快的軟件。根據項目的類型、級別不同,創建可擴展、可理解、可維護、可用或重用的軟件也許更為重要。軟件執行速度僅僅只是軟件評價標準的一方面，但是太多的開發員只注重該項，而影響了他們整個的工作質量。
我會尊重客戶并同他們緊密協作. 你開發軟件的唯一理由是為了支持客戶。只有客戶能夠告訴你他們需要什么，因為他們是業務領域的專家。為了保證你建立正確的系統，與客戶緊密工作難道不是非常有道理嗎？
我只接受符合實際的項目計劃. 組織或市場的壓力經常導致項目計劃不符合實際。無論何時，只要使用“如果每件事都按我們估計的方式發展，而且我們足夠幸運的化，我們就可以將項目作好”來闡明計劃的話，那你就有麻煩了。事情不總是按你想象的方式進行，不管多少人力投入一個項目，許多軟件的開發的不同工作都會耗費非常大量的時間來完成。記住，九個女人也不能在一個月里生一個孩子。如果你迫于壓力，接受了一個不切實際的項目計劃，那么你必須回去向老板闡明計劃不實際的原因。你的理由也許不被接受，你還得執行該計劃，但至少你為項目進行了爭取。有不現實計劃的項目組常常時采取了捷徑，但卻導致項目在遠遠落后于進度時，項目仍在停步不前。
我會持續改善我的溝通技巧. 如果你不能與其他人有效溝通，好點子又有什么用呢？你也許可以寫出世界上最好的源程序，但是，你不能寫一封E-MAIL來告訴你的老板與小組成員你所做的，那么你的杰作可能根本得不到承認。
我會養成學習的習慣. 在你躺在你的榮譽上時，軟件工業的技術與技巧在飛速改變。試著每月讀幾本相關雜志或至少一本技術書籍。我曾經接受到的一些最好的建議是擴展視野，并讀一些商業雜志。商業相關的閱讀使你具有同用戶聯系的背景知識，它是成功的一個關鍵因素，因為軟件是為支持用戶的使用而開發的。參加與工作有關的課程或會議也應是你學習過程的一部分。
我要測試所有我開發的. 如果你可以構建，你也可以測試。你可以通過查看需求文檔、設計、并執行多次測試來檢測代碼。如果一件事不值得測試的話，那么為什么還要做它呢？
我要文檔化所有我開發的. 現代軟件開發模式是你做為一個小組成員進行工作，如果沒別人能夠理解你的工作，那你就沒有對工作做出任何貢獻。很明顯，好的文檔能使你的工作容易被理解。實際上，簡而言之，好的程序員在開始編碼之前，會文檔化他們的代碼。
我認同軟件不僅僅是技術. 技術是有趣的，但它只是開發軟件過程中的很小一部分。不管是好是壞，你的工作 需要你熟練地與用戶、經理、同事、賣主或操作人員打交道。
我認為軟件不僅僅是開發. 你必須牢牢記住，你的用戶，或是你的上層經理，在你開始工作前，很可能已經花費了極大的精力來挑選和識別軟件開發項目。一旦你將軟件發布給用戶，該軟件必須要被維護、使用和支持。
你需要全面理解如何成為一個有效率的專業人員。
你正在新前年的開始，一個獨一無二的歷史時期，幾乎每個人都在迷惑如何看日歷。你可以或是以頭撞墻來向其他人解釋，2000年是千年的最后一年，不是新千年的第一年，或是放棄解釋，將注意力轉向改進你的軟件開發技巧。
依從我這里的一條或幾條建議將給你帶來成功，同時需要指明，經常去去體育館也是個不錯的主意。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
