高效設計構建軟體的十三條建議

標籤：

我近來一直在反思這幾年開發的公用程式，思考有沒有方法設計得更好。

我大致將公用程式定義為「能夠針對具體情境或商務程序解決單一或特定問題的任何項目」。

舉個例子，我用PHP寫了個小程式，輸入來自電商店鋪的輸出，通過解析資料轉換成下一步特定商務程序需要的格式。

怎樣設計才能更出色？

我一般有瞭解決問題的思路就會馬上動手，隨手開啟一個編輯器就開始敲代碼了。

過了一段時間，發現需要從以前寫的公用程式中照搬一些功能，但是當我開始重用代碼的時候，才發覺之前寫的代碼真是糟糕啊。通常我不會花太多時間寫公用程式，後果就是它們大都沒有類，沒有命名空間，甚至不是物件導向的。為了達到目的甚至用了過程式編程！

經過這件事我覺得應該更有計劃性，哪怕是很小型的項目也必須如此。

現在在開始新的項目之前，我都會考慮以下要點：

1）基本功是必需的！

不管公用程式有多小，都要養成良好的編程風格！使用正確的原始碼格式，命名規範和注釋。讓別人可以毫不費力地看懂代碼。

儘可能避免過程式編程。

哪怕項目很小或者用處有限，我也不會馬馬虎虎地寫代碼。

2）定義項目

除非公用程式只有一個功能，不然的話先對項目下好定義再開始寫代碼。程式的定義應該包括基本的聲明，比如誰會調用它，預設的輸入格式如何以及預期的輸出是什麼。

同時要定義資料來源，安全問題以及將來程式是否會逐步增加功能。

將公用程式託管在哪裡呢？

定義越詳細，挑選合適的工具就越輕鬆，編程時更不會迷失方向。在為他人開發軟體時更要注意這一點！

 

3）有合作者嗎？

如果有其他程式員參與開發，就需要豐富文檔和注釋。使用源碼版本控制系統，認真編寫類和方法確保不會出差錯。

如果根本不會有第二個人看你的代碼的話，文檔和注釋簡單寫寫就夠了，不用勉強自己。當然你得保證自己能看得懂。

4）原始碼版本控制？

原始碼是否可以託管在公開庫中取決於它自身的背景，比如是否屬於組織內部項目。如果可以公開，就要完善文檔，添加readme.md檔案，添加文檔塊來明確代碼的所有權，還要使用語義化版本號碼。

如果你有智慧財產權方面的顧慮，還可以再加一個許可證加以限制。

5）有必要長期維護嗎？

如果你覺得程式很有前景，認為會有更多程式員參與進來的話，就得使用版本控制，完善文檔並附加許可證。

如果公用程式屬於組織內部項目，你可能不會負責長期維護它。所以還是趁早把這些瑣事都搞定了吧，免得將來接手的程式員把你歸入可憐程式員之列。

如果代碼文檔完善，你甚至會收穫推薦信（雖然不能把在公司寫的代碼帶走，有封推薦信至少可以證明你幹得不錯！）。

6）應該建立API或者庫嗎？

雖然討論API和庫超出了本文的範圍，這個問題仍然需要仔細斟酌，因為它會影響編寫代碼的方法。

要編寫的工具 + 生產力是獨立的，還是作為一個庫來分發？或者你想讓他人通過API介面訪問一些功能？

如果選擇了API，那麼就必須要紮實地控制好輸入和輸出、資料驗證、資料轉換、安全性、HTTP路由、斷點等等。加密和認證也要重點考慮。

7）CMF，後端，配置？

公用程式是否需要內建獨立於前端環境的管理介面？

公用程式是否需要配備後端使管理員有相應許可權去進行控制？

最大的問題在於，任何內容管理架構（CMF）大都會塞給你一大堆根本用不到的功能，而你只需要跑一個公用程式就夠了。不過話又說回來，CMF也會給你相應的API和協助工具輔助，可能也相當好用。

要不然就把所有的配置資訊都儲存在一個檔案裡，只允許管理員有許可權訪問。

大多數時候我都會建立一個config.php檔案，把所有的配置資料都放在裡面，純手動編輯，不使用任何介面。

 

8）包管理？

包管理非常討人喜歡，但這並不意味著非用不可。

如果只需要幾個庫的話，不使用包管理一樣很輕鬆。

如果需要超過兩個或三個模組，或者模組十分複雜，我還是會使用包管理的。

如果決定使用Composer模組（PHP），那麼我建議你按照Composer的規則來寫公用程式，這樣的話你的項目自身也可以用Composer來管理。使用PSR-4 spec，檔案夾命名，類的命名規範諸如此類的東西。

9）前端架構？

使用者執行諸如上傳檔案、填寫表格、審核心數據、可視化資料等等多步操作的地方，需要複雜的前端。如果前端變得過於複雜，就要考慮使用前端架構。

說到架構，我其實指的是CSS架構，比如Bootstrap，Foundation，甚至是jQuery這種更龐大，包括更多可視化模組和JavaScript外掛程式的架構。

我喜歡從頭開始寫CSS，萬一項目壯大了，我可能就得在Foundation架構的基礎上把CSS重寫一遍。

10）需要日誌嗎？

你需要曆史日誌來記錄使用工具 + 生產力的過程嗎？你需要為審計工作記錄“誰做了什麼，何時做的，從哪裡做的，做了多久”嗎？

還有，如果是在公司裡而且工具 + 生產力會被許多人用到的話，是有必要記錄日誌的。

一些不錯的日誌庫可以用包管理找到，又一個使用包管理的理由，不是嗎？

11）需要強化錯誤處理嗎？

我編寫實用軟體的時候大多不考慮錯誤處理的問題。我傾向於寫代碼時讓所有錯誤提示開著，一旦所有工作都搞定了而且測試沒有發現問題的話，我就直接把錯誤提示關掉。

你要仔細考慮，是否真的需要複雜的錯誤處理機制、前端訊息、撤銷功能、後退按鈕管理、自動儲存而不是儲存按鈕、快顯視窗和模態視窗。同時還要考慮是否要和日誌系統對接。

務必注意，日誌、審計和錯誤處理都應該是前期標準中的一部分。這可以協助你從一開始就決定如何使用包管理和架構。

 

12）需要加強安全性嗎？

如果公用程式使用破壞性資料管理或者需要驗證使用者身份，那麼加強安全性簡直輕而易舉。

我是這麼想的，如果需要強大的安全性，那麼就使用高安全性的架構。可以選擇諸如Laravel、Kohana、Slim、Sliex之類的沒有管理介面的架構。還可以選擇諸如MODX、ProcessWire和Bolt之類的有介面的架構。只要架構滿足你的安全要求就行了。

重新發明輪子完全沒有必要。不要自己去實現日誌，安全性，使用者身分識別驗證，資料庫抽象等等。直接用架構。

13）要公開嗎？

還有一個大問題需要考慮，你寫的工具 + 生產力是僅供內部使用，還是開放給網上的所有人？如果是前者，內部是指會有幾十個，上百個組織內的同事使用你的軟體嗎？

必須確保終端（endpoint）被嚴格定義過，同時確保任何需要保護的輔助檔案和指令碼都得到了保護。

如果你疑慮高訪問流量會帶來問題，其實應該考慮緩衝機制，尤其是在產生資料庫或高度動態資料的地方。我們也會考慮安全問題、日誌記錄、身分識別驗證等等。

這麼說吧，一般而言，如果只是為普通人寫工具 + 生產力的話，用尋常的庫，工具，方法，文檔就好了，或者乾脆用架構。

在要發布公開版本的時候沒什麼好操心的，成事在天，只要嚴格按照規矩辦事，使用現代可靠的模組和架構就沒什麼問題。

你呢？

以上就是我開啟Sublime或者Netbeans開始一個新項目前需要思考的事情。

或許你已經有一套用作公用程式的常用工具集了。我想知道它們都是什麼，畢竟像Laravel這樣的大型架構或者全功能的CMF/CMS都過於龐大了沒法直接拿來當作工具 + 生產力。你是否在使用功能不多卻足夠完成實用功能的更小型的微架構呢？

原文連結：http://www.gbtags.com/gb/share/9424.htm

高效設計構建軟體的十三條建議