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

我近來一直在反思這幾年開發的實用程式，思考有沒有方法設計得更好。 我大致將實用程式定義為「能夠針對具體場景或業務流程解決單一或特定問題的任何專案」。 舉個例子，我用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