怎樣才能成為一名優秀的軟體開發者 (轉)

怎樣才能成為一名優秀的軟體開發者 (轉)[@more@]

  怎樣才能成為一個優秀的開發者？

(譯者注：原文是for BCBer 的，但其實本文所述對所有Programmer都適用,具體到語言的幾乎沒有，所以就這樣譯了...）

作者：    不詳  出處：    不詳
英文轉貼：Bird1945

★ 簡介：
 
最近有人要我就怎樣才能成為一個好的C++ Builder開發者提些建議。在二十多年的職業程式設計生涯中，我使用的程式語言從IBM 360 、Pick Basic、Modula 2到C、C++、Icon，使用的操作從MVS、、Amiga OS到DOS、、Win95以及多種管理系統，創作的產品被應用於製造業、保險業以及GIS領域。這些年來，我涉足過很多種技術領域，從而也獲得了很多方面的知識積累，它們對我有著“潤物細無聲”式潛移默化的幫助。我希望它們會對你有用。


對於此文的讀者，我假設你至少了解一些C++、 C++ Builder、繼承、資料和抽象、關係型資料庫、ER圖及一些基本的程式設計知識。 但你可以透過此文的閱讀知道你可以在其它與此相關的書籍中學習哪些知識，同時，也會提到一些參考書目及作者。


首先，你要知道，作為一個軟體開發者，多方面、多層次的對你的提高非常重要。Smalltalk(譯者注：80年代初廣泛使用的語言，曾掀起了一場“面向運動”，隨之誕生了物件導向的C、C + +、Eiffel和CLOS等語言) 和 Icon 可以提高你的C++能力；物件導向的Lisp語言和 Self programmer's(??) 對你使用繼承和很有益處；多種軟體開發方法學的使用不但可以幫助你做出更棒的設計，同時也可以使你學到很多設計重用的知識；廣泛地瞭解不同的上開發的形式各異的程式介面（尤其是那些經典的例子）可以使你的軟體產品獲得更多使用者的認可。


其次，你要記住，作為一個軟體開發者，客戶需求對你至關重要，雖然你要面對的客戶經常是需求難測。即使你是在開發一個小範圍使用使用的系統時也是如此。你要確信你理解客戶的需求，而且如果你要開發的系統是要應用於客戶的日常工作中的，這時你要想開發出滿足客戶需求的東西出來，你就必須非常清楚客戶他們的目的、他們的處理方法以及侷限性－－從長遠看來，這也是你盈利的唯一辦法。


最後一點，你要熱愛你的作品。對她，你要愛若珍寶，時時擦拭，她會擁有精妙絕倫的設計、精雕細刻的介面、良好感知的資料庫系統、優異卓絕的，並且同時具有最大程度的簡潔、精練、產品化，以及最大可能的對包括程式碼、元件、程式和設計等可重用的資源的重用。



★ 建議：

要想成為一個BCB軟體開發好手，你就必須時刻記住－－你是一個軟體開發者，而不僅僅是一個程式設計師。這就是說，你所要考慮的，不僅僅是怎樣寫出優秀的程式碼！你還要考慮如何做到軟體、資料庫以及使用者介面的良好設計、最終產品的可重用性及可維護性。當然，對產品的市場等商務環境方面的因素你也應該有相當的瞭解。


在我看來，即使在專案規模大幅增長而超出預先規劃的情況下，優秀的軟體開發者也可以始終如一地保持他的全域性意識。但在這種情況下，唯一可行的辦法是開發者在先前軟體模組的基礎上開發出功能更好的可重用軟體模組，即使在你覺得你為了使某模組可重用而做的工作會對你需要實時達到的僅僅是使它執行起來的短期目標有所妨礙的情況下，也不要例外。希望你在C++ 語言方面的經驗會使你更好地瞭解這一點。我的要旨是：如果你編碼中用到相似的部分超過三次，我想你應該對這些部分進行抽象和重用。這在BCB中也同樣適用，當然，如果重用的間隔度有可能很大的情況下例外。


(★譯者注★ －－ 以下文字請最好參閱相關建模技術方面的知識來理解！)

具體到BCB，重用有很多級別，懂得它們對你大有裨益。


最大限度有效地重用你現有的資源。我的意思是，你要儘可能地搞清楚VCL元件的機理，並且，你要經常嘗試著使用新的方法應用這些去解決你的實際問題。理解VCL所提供的屬性及其還可挖掘的可抽象性。絕對不要在僅僅設定一個屬性就可解決問題的情況下建立一個方法 －－ 記住，特別是在BCB中，物件導向思想的應用中的一個方面就是在程式設計中努力做到：少用過程式編碼以及控制結構，而儘量透過更改物件的屬性來實現。要了解BCB中VCL元件的應用，推薦你看這本書， Miano 的 《C++ Builder How-To》 (ISBN 1-57169-109-X)。


必要時開發新元件。我的所謂的“事不過三”規則要派上用場了。如果你發現你以同樣的辦法設定一個元件超過三次，我想你應該考慮將它做成一個新的元件。分析一下現有元件，繼承和它最接近的元件，只新增一些你所需要用到的東西。因為這只是單繼承，你不能透過藕合將其它功能也新增進來，但你應該考慮儘量使它在以後可以被繼承使用。在開發新元件時，儘量建立更多的介面和屬性而不是方法。學習屬性和元件編輯器並且清楚它們是如何在你建立新元件時簡化你的工作的。（相關推薦書目：Thorpe's " Component Design" (ISBN 0-201-46136-6)）


儘早形成自己的定規。“事不過三”規則部分上是在這一條－－儘早形成自己的定規中形成的。這樣來解釋吧：不要只是為了改變而改變(/faint)。堅持使用已經工作地很好的東西，只有這樣，你才可能有足夠充分的時間來比較詳細地瞭解它，從而知道是否可以透過對其抽象建模以提供給你更好的功能。另一方面，如果這條道路通向的是一堵牆，那我想你最好還是另尋它路。(譯者注：rut 同時有 車轍, 慣例意)


選擇合適的元件。仍然，注意“事不過三”。你的元件中包含了那些經常被提及的元件－－譬如 一個Combo 和一個使Combo 的內容得到使用的CheckBox 嗎？如果有，你就可以做一個聚合元件了。（獲得更多聚合元件的相關資料，可以看看“Creating An Aggregate Component With Streamable Sub-Components”，Konopka的"Custom Delphi 3 Components"(ISBN 1-57610-112-6)中也有很多有用資訊）


選擇合適的設計模式。遵循“事不過三規則”，使用前面提及的 Rut 規則，嘗試做到設計部分重用。你在建立設計時，首先嚐試尋找一套可以實現你的要求的元件，並且試試能否從中抽象出你所需要的（其中的子功能部分儘量使用屬性而不是在其中編碼來實現）而建立一個模型，而這個模型就可以在你係統的其它地方或你的下一個系統中得到重用。在物件導向程式設計領域有關設計和編碼模式的書籍很多，我的大多數這方面的知識來自於ACM（美國學會）和SLA（物件導向程式設計－－系統、語言、應用軟體）組織發表的會議錄及學報等文件，當然，你也可以找到其它一些好書。不過，我強烈建議你能夠加入ACM（這個建議也是自開始程式設計生涯以來我得到的最有益的建議）。如果你加入，可以成為以下特殊興趣小組的成員(SIGPLAN ：程式語言；SIGCHI：計算機知識交流；SIGSOFT ：軟體工程),可以索取OOPSLA, SIGCHI等組織的學報以及UIST的會議錄，你還將有機會獲得以前發表的學報文件，而這些文件都是值得精讀的，從中可以學習關於程式設計技巧、模式、使用者介面設計的知識。


選擇合適的應用程式模式。很多應用程式都有著很大的通用部分，所以，你可以先建立一個包含這些通用部分的核心繫統，然後再在這個基礎軟體模型上進行相應的改進來滿足需求。要獲得更多這方面的資訊，請參見“重用你的整個軟體系統”一文。


(★譯者注★ －－ 以下為作者對程式介面設計等方面的建議）

作為一個BCB開發者，你也必須充分認識到在程式使用者介面中的使用者方的因素，你也必須熟知一些如何使你的產品介面好看易用並且可以在相當一段時間內不會被淘汰的設計原則。


確信你理解了客戶的需求。在系統設計時，多問“這個是為了解決什麼問題？”或者“你需要它為你完成什麼功能？”等諸如此類的問題。不要讓使用者來為你設計使用者介面。如果客戶在說“我這兒放什麼，那兒放什麼”等介面設計細節方面的話，試著用上述的問題讓他回到正道上來。你熟悉設計良好使用者介面的工具和技巧，而你所要做的就是將客戶的所有需求轉換成可以滿足所有需求的抽象性介面，而不是為每一個任務建立一個使用者介面。


儘可能地簡化你的系統介面。你的應用系統越複雜，這一點越難做到但也越重要。介面設計中，經常用到的部件要一直可見，較少用到的部件就無需這樣了。要知道，人在同一時刻只有在面對不多於七個部件時才可以有較好的工作，而且，這些不應該需要去刻意地記憶，應該做到讓使用者可以輕易地識別開來。


在必要的情況下介面可以設計地比較複雜，你要保證沒有遺忘或者隱藏掉某些完成工作所必須的部件。


保持介面風格一致。實現不同功能的介面中風格不應有差異。完成相似功能的介面中應該使用一致風格的部件，提供相近功能也應該保持一致，使得使用者可以依賴他們的直覺來操作。


儘可能地捕獲並處理可能的錯誤。我很憎惡程式中會出現"Alpha value in numeric field"或這種型別的錯誤訊息－－系統根本就不應該允許我在這兒輸入不合適的值！另外，對於不可撤消的操作（譬如刪除），應該在未進行之前提供明確的取消途徑（譬如“你真的要刪除這條記錄嗎？”）。


注意各系統中各個部分之間的關聯。譬如，你不能允許使用者刪除一個尚有訂單未處理的賬目、還在原料單上的產品、尚有病人未重新分配的醫生－－除非你得到訂單撤消、原料單作廢、病人重新分配的確認。


保持整體均衡和諧。介面中重要的部分應該大一點，次要一些的選擇性的出現或者放在 Tab 頁上使得它可以被訪問但暫時不出現。確保你軟體的介面整潔，各個控制元件排列整齊而且佈置和諧，就如同一副令人賞心悅目的畫面。學習圖形設計、佈局方面的技術並應用到介面設計中去。如果可能，儘量使用系統提供的字型和顏色而不要太過花哨。


相關部件應放在一起。確保那些經常會同時用到的部件放置在一起。客戶應該找到所需部件而不會手忙腳亂。


隔離有可能產生危險性操作的控制元件。這些控制元件不可和經常使用的控制元件放置在一起。如果使用者誤操作刪掉了資料庫，哼哼，使用者肯定會咬牙切齒的，相信換作是你也不會例外。


使用模式，但又要避免使用它。是的，這聽起來有點矛盾。模式可能帶來很多問題。假設這樣一個場景：你本以為當前是選擇模式而進行了某些操作，遺憾的是，你最終發現當前是刪除模式！噢，天吶，你將有何感想？ 所以，儘量避免在你的系統中使用模式切換，這個比你想像的要易於做到。有新意、精練、並且沒有使用模式切換－－這樣你將設計出世界上最易於使用的程式介面！你可以隨時任意地操作它，而在（大多數情況下）你結束時會恢復成它應有的初始模式。當然，不可否認，一些模式切換可以讓使用者接觸不到會導致危險操作的介面元件。如果你使用了模式，想辦法儘可能清楚地標識它，同時做到易於切換，再透過增加確認來避免那些可能導致的錯誤(此項最好可選以方便高階使用者)。


儘量使你的介面標準化。我指的是，使用系統的標準格式，諸如系統字型，同時使用控制元件的方式也應該遵循比較通用的標準，或者使用那些使用者可以很直覺地明白如何操作的方式。


儘可能地允許使用者改變他們所想改變的。至少可以允許使用者來改變你的程式的視窗－－對話方塊中也希望如此－－並且做到可以記錄使用者所做的改動並可以在下次恢復。


(★譯者注★ －－ 以下為作者對資料庫設計方面的建議）

你還得成為一個資料庫開發者－－一個關係型資料庫開發者。你需要讀一讀Codd 和 Date的原作，並且應該搞懂ER圖。

(譯者注：

Codd: E F. Codd ： 關聯式資料庫領域著名專家,1970年，身為IBM公司San Jose研究室研究員的他在 "A RelationalModel of Data for Large Shared Data Banks" 一文中首先提出了關係資料模型(這篇文章就發表在前文曾提及的ACM的會刊上)，以後他又提出了關係代數和關係演算、依賴的概念，還有關係的1NF、2NF、3NF的概念，還和Boyce合作提出了BCNF，“為關聯式資料庫系統奠定了理論基礎”，曾獲ACM最高獎——圖靈獎。

Date: C J. Date ： 資料庫領域著名專家，著有多本資料庫書籍。An Introduction  to Database System 為其名作，1975年第一版發行，現在好像已經出到第六版了。)


每個表都應該有一個唯一ID屬性，這個你可以在向表中增加元組的時候指定。用數值來表示這個屬性。在資料庫中維護一個包含資料庫中所有表的元組，在每個元組中，貯存相對應的表中唯一ID的最大值；程式中每向表中增加一個元組，這個唯一ID屬性就應該跟著增加。這個唯一ID屬性在任何關係中都屬於一個外碼。


使用ER模型設計你的資料庫。把表作為一個實體看待，聯絡在表中一般是一個外碼。但有時候聯絡也可以是僅僅包含兩個碼值（偶爾也可能是三個）的表，其中的碼值對應這個聯絡的兩方。


設計關聯式資料庫時，理解4NF(第四正規化)，並且將它付諸應用。每個表中應該只包含那些與主碼緊密關聯的欄位，而且所貯存的欄位的絕大部分元組都不會為空。一個表中如果包含大比率的空欄位，就意味著有多種型別的固有欄位模式各異的記錄存在。這樣的表應該一分為二，其中一個為包含公共資料項（主幹部分）的特定資料表，另一個包含其固有欄位的各種型別，同時分配一個對應於主幹表的關鍵字和符合其型別的合適的資料項給它們。


每個可供取值的域都應對應一個表。這個表由一個唯一ID、一個名稱或者是一個描述組成，也可能包含其它資料項。在資料柵格中，如果包含了域中的屬性，那就使用組合查詢以便使用者在域表的元組中選擇資料。把名稱或者描述語句顯示出來，把唯一ID貯存在元組中，這樣，你就可以在不暫停資料庫的某些服務的情況下方便地改變其名稱或者描述。


另外，你也應該多多關注業界湧現的新知識和新技術。最好了解一下諸如、 Pascal、OC等東東，同時也時時瞭解一下相關的語言，譬如 SmallTalk、Common Object Lisp、Icon以及其它獲得較少關注的面嚮物件語言。每一種語言都擁有自成體系的技術和風格，而這些，對你的工作都會有所幫助。



★ 至於編碼本身嘛...


命名要科學。命名一個記數變數為"Index"而不是"i",定義一個變數名為"BillOfMaterialmpleted" 而不是 "BOMComp"。雖然這樣需要你多敲鍵盤，但與它在程式維護期間給我們帶來的方便性相比，這一點小麻煩微不足道。希望你在命名之前先考慮一下與它關聯的內容。舉個例子，命名你是資料模組為“Account”，其中的資料表為“Table”，這樣你的程式碼中就會出現這樣的程式程式碼：Account->Table->FieldByName("ID")->AsString = Accountdit->Text，看起來很清楚。注意選擇合適的命名，使得類似這樣的關係流就如同語言般的流暢自然，易於理解。


使用整齊的縮排格式和空格來保證程式段的條理性。為了突出顯示，括號最好單獨佔一行。


選擇適當的註釋方式。尤其對那些不可見並且不包含控制元件的類更是如此（這些類絕大多數繼承自TObject，也有一些是獨立的）。這方面可以參考一下“轉換模式”)。



★ 結論


要想成為一個好的軟體開發者，你需要具備多方面的高超技能，而這些技能中，大多數是來自於你所開發過的各種專案、應用軟體、開發系統、開發語言以及方法學。所有這些，是不可能一蹴而就的，你要有耐心，不懈努力，讓更清晰明快、更優美簡潔、更流暢自然的風格不僅僅體現在你的程式碼上，也體現在程式的介面上、功能上... ...

  CyberUFO (笨鳥後飛)  2001.11

to:CyberUFO@yeah">CyberUFO@yeah.net

歡迎指正…… 歡迎交流…… 

相關帖子：