軟工我的博客-week7

Part 1       No Silver Bullet - Essence and Accidents of Software Engineering
軟件工程中沒用通用的方法或者技術讓軟件工程在短期內快速進步，這一點其實我也沒有很明確的概念。其實近幾年的敏捷開發框架，mvc結構，rest風格，這些的出現都大大提升了軟件工程的效率，在我看來銀彈的出現也是不無可能，畢竟單純一個rest風格結合html5，給個人感受讓開發效率提升了起碼百分之三十。
Part 2　　big ball of mud你的項目有一個大泥球麼? 有什麼解決辦法？
所謂大泥球，是指雜亂無章、錯綜複雜、邋遢不堪、隨意拼貼的大堆代碼。其實在一開始寫工程的是偶，就是我大一的時候，我寫的代碼都是這種大泥球式的代碼，我以爲這種代碼的產生主要是因爲開發人員沒有開發經驗和合做編程經驗，有要急於完成任務。解決這種代碼的方法就是要作好分層解耦和回調，拿後端來講，咱們起碼要作到的一點是，邏輯處理和數據模型的分離，以後能夠進一步解耦，先後端交接的api分離爲路由，數據的處理邏輯主體分離爲控制器，參數的預處理邏輯分離爲中間件，後端的總體動做分離爲系統服務和觸發器，數據的處理分離爲模型，數據庫結構和填充分離爲數據遷移和數據填充。這樣就很好的保證了代碼的條理清晰，重用性，易於維護。
Part 3　　CatB – Cathedral and the Bazaar
關於教堂和大集市，這是對開源軟件開發模式的分類，教堂模式，源碼公開，可是開發過程有一個團體控制；市集模式，同源源碼公開，且源碼放在互聯網上供人閱覽，並能夠貢獻代碼，進行開發。提倡市集模式，認爲在足夠的人的檢視之下，BUG將無處藏身。我是認同做者的觀點的，舉個例子，國內的大部分開源cms都是大教堂模式，或者說連大教堂模式都不能算，由頂層控制太嚴重。能夠說這些cms的安全性是很是差的，可是反觀國外的開源項目，大部分都是在github上讓衆人一塊兒維護，包括php這種很是流行的語言（儘管php的漏洞略多，或者我接觸的比較多。。。），其安全性與國內的cms相比高了一個層次。
Part 4　　Lost in CatB這些狀況在你的團隊中出現過麼?
過分依賴的問題並無出如今咱們的開發中，由於在一開始制定api和開發文檔時，我就爲團隊成員撰寫了環境搭建的教程和要求，並規範了各類數據的存儲形式和結構，在咱們的項目中，數據都是存儲在數據庫中，進行報告生成的數據都是以文件形式。
其實惟一出現過一次依賴問題是這樣的，咱們須要用latex進行報告生成，咱們調試腳本時發現，在普通用戶下執行是能夠成功的，然而經過php調用生成腳本時卻一直在報so庫文件引用錯誤，以後我放了一個木馬得到apache守護進程用戶的權限，發如今該用戶下運行是不成功的，以後我用ldd看那個出錯的so庫的引用指向，發現，他居然指向了apache的庫文件，也就是說py的庫和apache的庫有重名衝突，以後發現apache會給他的用戶自動添加他本身的lib路徑到ld_library_path，然而php的命令執行是不起bash的，因此沒法添加環境變量，最後我寫了一個sh起一個bash把/lib路徑添加到環境變量裏最終解決了依賴問題。。。。。。
Part 5　　Managing the development of large software systems: concepts and techniques
瀑布模型在咱們的工程中是獲得了充分的使用，一開始是制定計劃和需求分析，以後計劃其實對我來講只是一個大致的概念，知道你們會在大致什麼時間作什麼就好，由於若是是針對個人計劃時間，我通常會超前完成不少，以後需求分析交到我手中後，我根據他們的網站原型進行後端路由和api的設計，以後交給前端和後端開發人員，咱們一塊兒進行開發，最後完成後進行對接，以後進行測試，上線後維護。
Part 6　　軟件工程的方法論到底有多少用處?
他其實能夠指導大多數的合做項目，有通用性。
-----------------------------我是優雅不要污的分割線-------------------------
其實寫到最後我還想寫一點其餘和做業無關的事情，您在咱們團隊的博客下評論，用戶名密碼的傳輸過程沒有加密，後端存儲時是否是也是明文。先說明一點的是，後端是採用加密的，而且加密方式是動態salt以後進行hash，以個人認知水平來看，在咱們規定的最小密碼長度6位下，這個加密方式是沒法破解的。
以後是關於明文傳輸的問題，個人主業的搞信息安全的，其實我遇到不少不少人跟我提漏洞的時候都是跟我說，這個密碼是明文傳輸的，我其實很不理解，就這樣來講，單純在前端作一次加密是沒有任何卵用的，我遇到過不少網站，他們前端作了md5，以後進行傳輸，可是這個傳輸過程當中我若是嗅探到數據包，照樣能夠拿這個數據包進行登陸，而且，這些網站在拿到他們的數據庫權限或者注入獲得密碼後，發現起碼有七成是直接拿前端傳過來的md5進行存儲的，這是一種愚蠢到爆的方式。若是先後端都作加密，安全性確實會好一點，可是我一樣能夠拿數據包登陸。
我能提出來的惟一一種可靠的前端加密方式就是使用時間戳做爲動態salt，也就是說，咱們拿一個時間間隔好比15s做爲單位，來用時間戳計算出一個salt以後與密碼作hash，後端一樣拿這個方法進行校驗，這樣能夠保證每一個數據包的有效時間最可能是15s，可是，就算是這樣，也會出現隨機的驗證失敗（好比驗證時間恰好在更換salt的一瞬間），而且，我徹底可使用腳本，在嗅探到數據包後當即重放攻擊，甚至不須要重發，我既然能夠嗅探到你發出的包，一樣能夠嗅探到你接收的包，普通用戶的密碼並不重要，重要的是登陸後開放的接口，這樣纔有更多的漏洞暴露，也就是說，重要的是cookie和session。然而，這是任何前端加密都不能解決的安全問題。
而且，還有一個很重要的成本問題，我能想到的最有效的辦法就是如上的時間戳方案，可是，這個方案也是個能夠被輕易攻破的方案，然而，實現這個方案也是須要成本，若是這個應用真的有這麼高的安全需求，他不會去付出如此的成本去實現一個破綻百出的方案，而必定會使用ssl。然而沒有這種安全需求的網站也不會去付出這個成本。
以上的討論都是站在一個黑客或者運維的角度出發的，個人確沒有爲用戶暴露明文密碼着想，由於我以爲，用戶密碼被嗅探，不管如何都是極小範圍內的，若是嗅探者是在服務器C段，那我以爲服務器安全是朝不保夕的，而且關鍵並非在傳輸中。密碼並不重要，密碼是爲了獲得權限，數據和權限纔是一個黑客想要獲得的。
綜上。
謝謝。