 |
|
茫茫網海中的冷日
發生過的事，不可能遺忘，只是想不起來而已！ |
|
|
恭喜您是本站第 1671828
位訪客!
登入 | 註冊
|
|
|
|
| 發表者 |
討論內容 |
冷日
(冷日) |
發表時間：2008/3/19 7:51 |
- Webmaster
- 註冊日: 2008/2/19
- 來自:
- 發表數: 15771
|
- [原創]冷日淺談程式設計的一些些應注意事項
- 程式設計規範
前言：
其實我一點都不想說她是規範，因為我既不是大哥級人物，更不是什麼啥麼大師級的程式設計師，但有鑑於我們要走向CMMI，而且為了以後新進人員能夠以最短的時間接軌，一些些的好習慣，是會有不小的幫助！
請大家務必記得，以下所寫的部分大多都只是希望大家在寫程式的同時，能夠盡量有一個統一的格式，方便未來版本控制與程式碼的再利用，更進一部達到程式即文件的目標，這沒有一個絕對的標準，只要能讓大家不要在過去的錯誤或是歷史的洪流之中被淹沒，那就是一個好方法，小弟在這裡只是提出一些個人看法，供大家參考參考。
好了，現在開始我就以下列目錄內容一一開始介紹！
目錄：
1. 程式的本質
A. 冷日的廢話
B. 命名方法
C. 註解重點
2. 變數、函式、結構、物件、方法的宣告
A. 變數
B. 常數
C. 函式
D. 物件
E. 結構與巨集
3. 版本控制
4. 結語
程式的本質
冷日的廢話：
首先來談談電腦的功能，電腦的功能應該是幫助人類處理大量而繁瑣的資料，或是做複雜而繁複資計算，開發程式的理由，應該就是讓電腦能達到上述的目的，所以程式這東西應該是要幫助我們能更快速的處理資料，更有效率的計算，而不是讓人們陷入一種無止盡的漩渦，或是困擾大家的一個怪獸！
那我們的程式如何能夠達到以上的目的呢？就個人經驗而言，有幾個要注意的重點，在這裡提出來供大家參考：
I. 介面
創造一個便利使用者使用的介面是第一要務，唯有讓使用者不需太多的學習，用最直覺的方式就可把我們的產物使用的很順手，在最不需要花腦筋的條件下得到使用者需要的東西，這樣的產品才能夠在現今競爭激烈的世界中生存。微軟就是最好的案例，她們的東西不見的是最穩定的，更不會是最便宜的，但她們卻是市佔率最高的不是嗎！？
II. 速度
使用者大多數是沒有耐心的，如何在她們能接受（或說預期中）的時間內交給她們要的答案，是程式設計師要考慮的重點之一，當然最後吐出來的答案要是正確的！速度另外一個意義就是程式開發的速度，現今是一個分秒必爭的時代，相同的創意，如何在最短的時間內開發出成品，實作出可以進入市場卡位競爭的實品，方能在第一時間創造利潤，否則在好的創意都會變成別人的利潤！
III. 硬體需求
硬體的進步是有目共睹的，但是何時會出現硬體時代的瓶頸任誰都無法估計，所以我們不能寄望於硬體速度的無限提昇，而應該在主流（甚而更低階一些些）環境的條件下開發適合當代使用的產品，當然這也牽涉到剛剛所提的速度，因為硬體的速度不是軟體能夠控制的部分，其後是考慮未來的硬體相容性，或是各平台之間的相容度，我們的產品才能長治久安！
IV. 管理與維護
軟體發展最辛苦的不是事前的規劃，也不是程式開發期間的程式碼創造，而是軟體上線後的管理與維護，許多的產品或專案為求開發時程的縮短與程式簡潔，或單純是程式設計師的懶惰，經常忽略了預留管理與維護的介面或文件，致使許多產品或專案到最後都變成一堆爛攤子，許多前車之鑑血淋淋的在我們面前，不可不慎ㄚ！
命名方法：
此處所指的命名方法，是指檔案、資料還有資料夾的命名方式，關於變數、常數、結構、函式、物件與方法等內容的命名方式，則會在後面詳細說明！
檔案的命名原則在JAVA上非常清楚，因為在JAVA中你的檔案名稱必須與你的class同名，而在C和其他非物件導向語言之中，所以我想就乾脆借用JAVA的定義，也就是是希望大家在定義檔案名稱的時候，首先要能夠清楚表示該程式的目的或功能，其次是使用簡單而請楚的單字組合出檔案名稱，並且再每一個單字的第一個字母使用大寫！
其它輸出輸入的檔案或是程式裡面會被使用到的檔案，亦請使用上述的原則命名，但在副檔名部份，請務必要清楚寫出副檔名，避免沒有附檔的狀況增加閱讀的困難度！
而資料夾部份，大致上沿用大部分unix-like系統的習慣，敘述如下：
原始檔案放在src資料夾
執行檔則放在bin資料夾
引入檔(include file)則放在inc資料夾
函式庫(library)則放在lib資料夾
設定檔放在conf資料夾
暫存檔放在tmp資料夾
圖檔則放置在img資料夾
文件檔放在doc資料夾
紀錄檔放在log資料夾
最後要說的是，大家在除錯（debug）的時候，常常會吐出一些除錯使用的記錄檔（debug file），他不是最後程式會使用到的記錄檔，大多時候大家也懶得去定義它應該被放在哪一個資料夾中，所以經常會和執行檔放在同一個資料夾，這是比較沒關係，但請在程式除錯之後記得把她們刪除，而且還有一件事要注意，究算他是一個除錯用的暫存檔，也請大家不要使用完全無意義的檔案名，建議大家依照幾個特性替它命名：1.檔案建立者2.檔案建立日期3.給個副檔名
EX：coolsun_22041024.debug
這樣大家只要看到是人名，副檔名又是除錯用的，就可以把它給大方刪除掉，頂多考量一下時間性，比較近期的可能程式還有錯誤尚未被解決完，最少，找的到兇手來問，不是嗎？
註解重點
一個程式要被容易閱讀，註解是很重要的一個部份，大家對註解習慣都不太一樣，這純粹是個人習慣，實在是沒有被嚴格定義的必要，但是，相信許多的程式設計師是沒有寫註解的習慣，那就非常糟糕了！
一個比較大型的程式，相信就算是你自己一手寫出來的，若沒有註解的話，要看懂他在搞什麼應該是需要一些時間的，甚至於過了一段時間以後，你可能已經完全忘記了你當初為什麼要這樣寫，特別是一些歷史因素或是硬體因素的部份，將會在一段時間之後被你遺忘，而這些東西要一個閱讀這程式的人來猜透更是不可能了，所以請務必要寫註解！
註解要寫些什麼呢？基本上希望大家注意幾個重點：
I. 註明作者
寫清楚程式的作者，如果有許多人一起完成一隻程式，更應該註明哪個人撰寫哪一部份，以期在有何更新或困擾時，能用最快的速度找到當初的創作者。
II. 標記創作(或更動)時間
許多程式會因為時間的流逝而有所更新，或是因為時間的經過，硬體設備或是其他因素有所變革，此時清楚的紀錄創作與更改時間，可以使閱讀的人花最少的時間了解為何會有這樣的變革。
III. 寫明程式目的
每一隻程式的開發一定有他的目的存在，不論任何理由，都希望大家能夠把他清楚的寫明在程式的一開頭部份，讓大家在閱讀的時候，可以先開宗明義的了解本程式到底是在做什麼；如此還有一個好處，就是閱讀者在跟蹤（trace）程式時，不較不會被一堆不知所以然的參數搞得一頭霧水。
IV. 各函式的功能與目的
一個中大型的程式，一定會有許多非主程式的部份，也許是函式，也可能是一些物件或是方法，在定義這些非主程式的部份時，請順便把其功能和目的透過註解讓大家了解，這樣未來有需要的時候，大家可以比較容易的再利用該程式碼。
V. 各函式的使用方法
除了註解各函式（在此以函式統稱所有非主程式的其他程式片斷，包括物件與方法皆然）的功能與目的外，請大家也務必註明該函式的使用方法，其中應包含引數（parameter）傳遞時需要哪些引數，又應該是哪些型態，亦應包含回傳值（return value）的意義與型態，為有清楚註明這些資料，大家才能便利的重覆使用該函式。
變數、函式、結構、物件、方法的宣告：
大多數的語言都有牠們自己一套命名原則，而我這裡要說的，並不是和各種程式語言有相依性的命名原則，而是要討論大家在撰寫程式時，對於變數（variable）、常數（constant）、函式名稱（function name）、物件名稱（class name）、方法（method）等宣告時命名的一郭習慣。
I. 變數（variable）：
宣告變數名稱時希望使用有意義的字眼，少使用i、j、x等等無意義之單字，以求事後閱讀程式時，可以一眼就看出該變數的功能與目的！
EX： int counter4clientusers
其次是為求閱讀容易，變數名稱盡量使每一個單字的第一個字母都大寫，可以減少閱讀時判斷字眼間斷詞的時間！
EX：int Counter4ClientUsers
II. 常數（constant）：
常數則希望盡量宣告在變數之前；原則上C語言要求常數宣告必須在heading區，但他並沒有定義絕對的位置，希望大家能把她宣告在全域變數之前，並且使用全部大寫的字母來定義名稱，其他部分則如變數一般，避免使用無意義之字眼！
EX：#define PI 3.1415962
III. 函式名稱（function name）：
基本上涵是對應到物件導向語言中就是方法（method），所以要求的方式和物件導向中的方法命名是一樣的，首先希望大家在命名時不要使用無意義的字眼，最好是一眼就能夠看出該函式或方法的目的。
函數或方法的第一個字母應該小寫，以便於和變數清楚分辨，其它部份則應和變數命名一樣，在每一個單字的第一個字母都採用大寫，以便利大家判讀。
順便在宣告時，把引數（parameter）的定義一起定名清楚，方便大家再呼叫使用本函式時可以一眼就看懂要給哪些引數！
順帶一提，雖然不論在C或是JAVA之中，main都是可以不要引數的，亦可以不要回傳值，也就是將其定義成不回傳之函式，但不建議大家養成這樣的壞習慣，畢竟當程式開始龐大，程式與程式間互相呼叫的機會就越來越高，利用一兩個參數可以大大提升該程式之擴充性，而一個定義的清楚得回傳值，亦可幫助大家在呼叫時，可以透過回傳值知道該程式是否有達成預期目的！
IV. 物件名稱（class name）：
在物件導向語言中才有物件名稱，而各物件導向語言亦幾乎都有自行定義她們自己的物件名稱命名規則，在這裡就不多作贅述，唯一要請大家注意的是，請務必命名有意義的名字，不要嫌麻煩而偷懶把名字給「極簡化」，因為當程式一開始龐大，相關類似的物件可能會越來越多，閱讀那些不容易辨識的物件名稱將會造成大家使用上的困擾，因為大家看不懂物件的意義可能會自己再重寫一個，也會浪費許多資源，更違反了物件導向語言的目的。
V. 結構（struct）與巨集（macro）：
基本上這兩鍋東西都不會出現在物件導向語言裡，所以冷日把它放在最後說明，希望大家把結構的命名規則和變數統一，而把巨集的命名方式和函式統一，因為這兩鍋東西本來就分別是變數與函式的延伸（此處不是程式語言討論，所以不討論是誰延伸出誰），而使用的方式亦和她們差距不大，故如此規範！
命名原則說了這麼多，只是希望能夠在大家撰寫程式的時候，為未來閱讀本程式的人（不一定是別人，也許就是程式撰寫者）提供一些方便。
此處的命名原則加上前面所提到的註解方式，對於閱讀程式的人一定能夠有所助益，可以大量節省許多臆測的時間，讓所有人都能夠用最短的速度了解一隻程式的意義與撰寫邏輯！
版本控制
版本控制也有人稱它為原始碼控制（source code control），它的目的就在於解決檔案被別人（或自己）覆蓋、檔案遺失（拖放檔案時誤動作...）、比對各版本之間的程式碼有何不同、想要回到之前修改的版本（需求反覆變更、自己改錯了...）、這些 code 不是我改的，是誰碰過我的程式碼、軟體發行之後，必須凍結共用的程式碼一段時間，免得其他人在改 bug 的同時，因為你修改了共用的程式而增加更多新的問題。等各種問題，讓你可以：
隨時復原錯誤，就好像是專案的時光回溯器，可以將檔案恢復到以前的任何時候的版本；
多人同時修改同一份程式碼，不會有相互覆蓋的情況；
保留所有修改的歷程，如果你發現自己的程式碼有被別人更動過，可以很容易找到是誰更改的，以及何時更改的；
在發行正式版的同時，還能繼續發展新版本，無須下令凍結所有程式碼。
版本控制系統則是提供上述功能的軟體系統，它提供了一個地方讓你集中存放開發過程中的所有程式檔案及文件，以便達到集中控管的目的。
版本控制與軟體建構管理
軟體建構管理（Software Configuration Management）簡稱 SCM 或 CM，是軟體工程領域中的一環。SCM 的傳統定義是原始碼的版本管理，後來則逐漸演進擴大，將軟體開發的一些標準和程序納進來。你可以將 SCM 視為軟體演進的過程中，用來管理改變的標準程序，這個改變的來源包括：程式碼的改變、支援多種作業平台、提供多種版本（例如：標準版、專業版）....等等，而版本控制就是用來實現 SCM 的主要工具。
SCM 這個主題很大，這裡主要是點出版本控制與 SCM 的關係，若有興趣進一步了解 SCM，請參考相關的書籍或到 Google 搜尋關鍵字 "software configuration management"。
在這裡只是介紹了版本控制的一些基本觀念和術語，冷日也不打算跟大家繼續深入討論關於版本控制的各種軟體，導入版本控制的軟體與流程是計畫中的事項之ㄧ，本文要訴求的重點是在於，目前尚未導入本控制系統前，我們要如何做版本控制呢？
I. 清楚記載程式建立時間與更新時間。
II. 更新時間務必與更新內容原因做連結。
III. 避免刪除過去的程式碼，採用mark的方式，並註明原因與時間與兇手。
IV. 若有”目的上”的改變或是大功能的更新，建議把原始檔先備份起來。
結語
長久以來，程式設計師大多都專心致力於新程式的開發，忽略了維護一個程式的重要性，要知道，產品是不可能只有一個版本的，專案在結案後更是維護深淵的開始，唯有大家多花那麼一點點的心力，在撰寫程式的同時，養成前面所提及的各種細節，不論是檔案存放位置、註解或是各種變數、函式等的命名原則，如果每一個小地方都能夠落實完成，相信不論是自己日後要維護、更新版本、程式碼再利用還是團隊開發，都會節省倍數以上的時間與心力。
最後則是在最面冷日就有提到的期許，希望大家真的能讓程式即文件，如此向來煩擾所有程式設計師的文件撰寫也將變的更加輕鬆，僅需把關係圖與相關性交待完畢以後，也就能讓一位新手接續這未完成的任務，才是我們的終極目標ㄚ！
全文完
|
|
|
|
|
|
