以圖明志

軟件架構技術

Web研發模式演變史

從架構改進看思維變化
前不久徐飛寫了一篇很好的文章:Web 應用的組件化開發。本文嘗試從歷史發展角度,說說各種研發模式的優劣。Web 1.0 時代,非常適合創業型小項目,不分前后端,經常 3-5 人搞定所有開發。頁面由 JSP、PHP 等工程師在服務端生成,瀏覽器負責展現。基本上是服務端給什么瀏覽器就展現什么,展現的控制在 Web Server 層。

軟件架構技術

列舉一些常見的系統系能瓶頸

Common Bottlenecks
Russell Sullivan 提出一個很有趣的設想:一共有20種經典的瓶頸。這聽起來就像只有20種基本的故事情節(20 basic story plots)那樣讓人懷疑。不過基于每個人不同的分類方式,這個說法或許是對的,但是在現實中,眾所周知,瓶頸是無窮無盡的而且涉及方方面面。

軟件架構技術

談談對一些軟件架構設計箴言的理解

對軟件的過早地優化是萬惡的根源
在做項目的時候,有些同事總是提前考慮性能優化,需求變更又是一大堆的重寫,讓我想起了Donald Knuth 提到的:對軟件的過早地優化是萬惡的根源。這里就簡單的說幾條重要的軟件名人哲學。在軟件開發過程中需求是不停的變化的,隨著客戶對系統的認識,和現有開發功能和軟件的認識,也許一開始他提出的需求就是背離的。

軟件架構技術

開發人員練就百般武藝為了啥?

業務領域,是軟件的核心價值所在
無論是買成型的軟件產品,還是出資開發項目,客戶投資的是軟件的業務價值。項目經理直接為這個目標負責,盡量少的成本,盡量短的時間,生產出高業務價值的軟件產品。架構師則是跨越單個項目,長期為這個目標負責。項目經理與架構師是天生的敵人,短期看這是對的,長期來看,他們是真正的朋友,是戰略朋友。沒有項目經理項目會死得很快;還而沒有架構師,公司會死得很慘。

軟件架構技術

Google的分布式計算模型Map Reduce

map函數將輸入分割成key/value對
計算機的早期階段,程序都是serial(連續的),類似于批處理程序。并行計算的程序中,進程將一個任務分割成多個部分parts,每個“部分“都是能夠并行處理的,每個“部分”可以同時運行在不同的cpu上,這些cpus可以是同一臺機器上,也可以是通過網絡運行在不同機器的cpu上。

軟件架構技術

大規模分布式數據處理平臺Hadoop的介紹

一種可靠、高效、可伸縮的處理方案
Hadoop原來是Apache Lucene下的一個子項目,它最初是從Nutch項目中分離出來的專門負責分布式存儲以及分布式運算的項目。簡單地說來,Hadoop是一個可以更容易開發和運行處理大規模數據的軟件平臺。用戶可以在不了解分布式底層細節的情況下,開發分布式程序。充分利用集群的威力高速運算和存儲。

軟件架構技術

軟件項目開發沒規劃好就注定會失敗

軟件項目開發與管理的一些原則
軟件項目的開發與管理是一門復雜的學問,不是簡單地需求來了就動手編碼,編碼完了就算項目完工那么簡單。一個項目如果沒有好好規劃,那么就很容易會失敗。同樣,我們在做一個軟件項目的時候,需要注意的東西很多,下面總結一下一些容易視而不見但又非常重要的軟件開發指導原則。

軟件架構技術

系統架構39問

架構視角面面觀
架構一個系統不是一件簡單的事,需要考慮到的事情也特別的多。下面我列舉一些常見的問題,以拋磚引玉。是否在不斷的學習新技術、新名詞、生怕落伍?(WCF、WF、WPF、MVC、EF、WebApi、Spring、Castle、Unity、Autofac、NInject、AOP等)

軟件架構技術

什么樣的應用才算是RESTful?

讀 《REST in Practice》
盡管 REST 這個概念 2000 年就被提出來了,但到了2007 年才成為了一個熱詞,隨后越來越多的服務都宣稱自己是 RESTful 的,但是到底真么做才是真正的 REST 我從來沒有自習學習過。由于 2007 年的時候 Ruby on Rails 也十分熱門,所以我以為 Rails 風格的 CRUD API 就是 REST 了,同時對于外界關于「什么算是 REST 什么不算是 REST」的爭論沒怎么關心過。

軟件架構技術

根據自己的需要適度使用Web開發框架

取自己需要的,做適合自己的系統
軟件系統發展到今天已經很復雜了,特別是服務器端軟件,涉及到的知識,內容,問題太多。Web開發框架能夠幫我們大大減少工作量,但是我們應該如何正確看待Web開發框架,并且如何去使用他們呢?從做網站到現在做Web端的應用,我度過了三個時期:使用框架來搭建自己需要的系統。一開始是大框架如drupal,后來覺得過于笨重。于是改用codeignitor等小框架。

軟件架構技術

在系統設計中,如何控制層次的問題

設計的核心任務之一:層次的控制
對于軟件而言,層次是讓人又愛又恨的東西。很多問題是通過增加層次解決的,但另外一部分問題也是因為層次而導入的。通過加入層次解決問題的同時,新的問題也隨之發生。在眼前蒙上一層薄紗可以防止眼睛被風沙所傷害,但如果蒙上十層,那更嚴重的后果將會出現——你看不到路了。

軟件架構技術

軟件系統架構中的分層思想

關于分層結構
眾所周知,經典的三層結構包括數據訪問層、業務邏輯層和表示層。當然,如果繼續擴展下去,還可以分為4層、5層……我相信很多人都用過,很多人都寫過,但是為什么要這么做,還是有一部分人是不能夠說清楚的,這不是我猜想的,而是遇見過很多想分層但是分的亂七八糟的層次結構。

軟件架構技術

編碼工作也是一種設計

【設計 = 編碼】 VS 【設計 ≠ 編碼】
這篇文章的核心觀點是:編碼也是設計,而軟件開發中與建筑行業中的施工所對等的工作,已經被編譯器代理了。這是幾近20年前的文章,但時至今日,類似的爭論仍未休止。好像是在《軟件架構設計》里,在討論架構設計時,作者就點了一句:這總不能說是設計就是編碼了吧。

軟件架構技術

網站性能優化策略的選擇

性能優化到何處為止?
人生三苦:選擇,后悔,絕望。為了避免后兩項,所以才絞盡腦汁去做出明智的選擇。人人都無時無刻不面臨選擇。做軟件開發的,從初級,到中級,到高級,所掌握的知識和技術越來越多,面臨的選項越來越多,對選擇進行評估也越來越困難和復雜,一項選擇所造成的影響也越來越大。所以,做軟件做到架構師,就是和人生三苦之一的“選擇”整天打交道的職業。

軟件架構技術

ECMALL的登錄過程機制解析

這個過程程序執行效果非常的好
在ecmall.php文件中實例化控制器類,每一個控制器類,必須繼承admin\app\backend.base.php文件。在繼承中調用方法是誰先被繼承誰的方法被先調用。繼承其實結果就是為增加代碼的可重用性,也就是你定義一個方法如果他有一定的共性可以被多個新增加的效果所調用。程序結構給人感覺似乎挺亂的,但是如果細心研究執行效果非常的好。

軟件架構技術

簡單談談Web Service概念的理解

云計算、云服務與Web Service
傳統上,我們把計算機后臺程序(Daemon)提供的功能,稱為“服務”(service)。比如,讓一個殺毒軟件在后臺運行,它會自動監控系統,那么這種自動監控就是一個“服務”。通俗地說,“服務”就是計算機可以提供的某一種功能。
1 / 3 首頁 < Prev 1 2 3 Next > 尾頁 頁碼:
英超直播吻球网