2009年7月11日 #
那么我對互聯網公司的比較感興趣的地方主要體現在軟件質量和技術管理方面,以下2點可以作為討論的提綱:
1 軟件質量,盡管質量是我們嘴邊經常掛念的一個詞,但不少創業型公司的投機心理太重,在與這些負責人的交流中發現,談論的更多的是新想法、新概念,有非常重的商業氣息,當然這沒什么不好,但我看了他們的一些產品后發現,他們所做的產品用戶體驗非常糟糕,就拿界面來說,非常的粗糙,由于有家公司做的產品和易趣類似,我特意打開2個窗口對比一下,總覺得易趣的看起來比較舒服,他們整體布局倒模仿易趣倒挺像,但問題就體現在細節上,圖片失真嚴重、字體風格不一致、細節處理的不到位。好了,那就湊合著看吧,發現該產品的功能非常的多,但讓人郁悶的是,很多功能是有問題的,比如明明提示我系統給偶發了個郵件,但就是找不到,有時候提交表單是可以的,有時候見到一堆java異常錯誤。所以我覺得這就是典型的追求功能的龐大而導致質量的縮水。
其實自從豆瓣開始流行后,大家都意識到功能做的簡潔原來是有好處的,有不少創業者聲稱自己要向豆瓣看齊,鄙視csdn,堅決走簡潔之路,但讓我納悶的是,很少有人真正的堅持下去,我有個同學06年底曾在一家創業公司玩過python,準備做一個很有趣的網站,叫做抱怨網,其實是蠻有創意的,不久前JE不是有個哥們在四處發帖說我愛我家黑中介的事,其實本來這個網站就是干這個事的,專門揭不良企業底的,但做著做著,成了巨無霸,開始是把大眾點評網的功能加進去,接著又開始融進趕集網的分類信息功能,最后有把智聯招聘的招聘功能加上了,結局就是1年不到,網站不出意料的死掉了,原因就是用戶體驗差,根本不感興趣!最后我替他們老板做了下反思,其實說實話,我還是很理解創業人的心,看到好東西都想要,而且之前幾年在互聯網圈錢誰都眼紅。另外,他們的功能盡管是抄襲別人的,但還是有一定的特色與盈利模式,并且各個功能分的也蠻清的。 所以我覺得失敗的原因不能簡單的歸結為功能太多,而是質量,小公司也就那幾號人,作為開發人員,面對這么多的需求,只有拼命的趕進度,丫還有時間考慮質量或者用戶體驗嗎?所以沒有一定的資本與一批強有力的管理和開發人員,切勿貪大求全,否則很可能就是在生產垃圾。其實質量這個東西從高的層面上說就是用戶體驗的好壞,bug少不見得質量高,但用戶體驗差的東西絕對就是垃圾。
最近市面上有個說法有個說法是30w足以模仿個淘寶,我認為就是扯淡,誤導了很多創業者,認為花點銀子,雇幾個人,就可以輕松抄襲淘寶了,咱先不說市場投資,只談技術,表面上看淘寶,丫就是一個破網站,但背后的技術你看的見嗎?穩定性、性能、維護、可擴展性,這些都和軟件質量息息相關,直接影響著用戶的滿意度,你確定真的做到了嗎?淘寶的架構師一年的薪水也30w了。所以我覺得創業者要領悟毛澤東思想,采用各個擊破的戰術,在有限的資源下約束的自己產品的功能,做到小而美。
這里舉個正面的例子,有家位于芝加哥、名為37 Signals的小公司,正是這種擁抱限制的方式之代表者。37 Signals最初是一家網頁設計資訊公司,后來為了滿足自身需求而將業務擴展到軟件開發領域。他們編寫了一些用于項目管理的內部工具。為了和客戶溝通, 就向客戶開放了部分系統。公司創始人和總裁杰森•弗瑞德(Jason Fried)解釋說,在他們自己意識到之前,已經做出了一套基于網頁的應用。又做了4個月,他們把軟件轉換為稱作Basecamp的服務。 Basecamp發布于2004年2月,很快在類似Flickr和Google的Gmail等新Web富應用天堂中名列前茅。
Basecamp只是這家公司花一年多時間投入少量程序員做出來的一系列值得注意的小而精的產品之一。Basecamp之后是Ta-da List,用于保存和共享待辦事項(及類似事項)列表。幾個月后推出了Backpack,它允許用戶保存和共享便簽及文件。每種產品都可靠并易于使用,而 且都是精心設計的。每種產品通常也都只包括少量新特性。例如,Basecamp就有一些精巧的電子郵件功能:和其他服務和程序一樣,也可以設置郵件到達提醒——還可以從另外的計算機或手機等移動設備向Backpack網頁發送郵件,郵件文本就會在頁面上顯示出來。
2 技術管理,你會發現很多公司的負責人不是很懂技術,但卻是負責技術的,丫今天聽到SOA是個好東西,號令紛紛SOA,反正大家都不理解這個含糊不清的東西,做唄,看誰能忽悠的過誰,一般來講,創業型公司為了節約成本,不會預留專門的QA,有專門的測試人員就不錯了,所以缺乏一個質量保證的環節,遇到問題怎么辦?誰做的誰改,改成什么樣沒人關心,只要負責人看到問題解決了就可以了,但,我想問的是,不良代碼背后的隱患你知道嗎?結果就是你咬牙給開發人員開工資,開發人員假裝幫你實現夢想,或者說造就一批劃水的人。其實很多東西不是錢的問題,也不要以為多開點薪水就可以留住人心。另外我覺得很多技術負責人喜歡把東西模糊化,比如把軟件即服務的理念掛在嘴邊,但做起來是另一碼子事,我覺得作為一個技術負責人自己就要身先士卒,至少在創業公司是這樣,這樣才更有說服力,遇到問題自己應當第一個沖上去,拿出具體的解決方案,對代碼應當做到精細管理,做到心中有數。說到底,創業公司得有一個技術核心,一個真正能實現你的想法的人,一個可以讓大家凝聚起來的人,不至于讓大家劃水的人。
好了,先說那么多,希望各位準備創業的同仁能真正的樹立精品意識,打造精品,實現夢想
問題的產生原因
頁面提交給Action去進行業務處理,Action再跳轉回前臺頁面,但這時URL依然是“頁面提交給Action的鏈接”,這時前臺刷新一下頁面,就變成再次執行了一次提交操作。
解決思路
1,在Action頁面中跳轉的時候用重定向,可以在struts-config.xml中配置<forward ... redirect=“true”>
不過這種方法會使得request中放置數據丟失;
2,用Token令牌環來實現
提交到Action的時候,進行一系列操作,然后保存一個標志,這時再跳轉到前臺頁面。如果前臺頁面刷新的話,Action通過查看是否有標志,就能判斷用戶是刷新還是提交。
Action中操作令牌的方法
一: saveToken(HttpServletRequest request)
創建一個新令牌,并將其保存在當前用戶的會話中,如果用戶的會話不存在,將首先創建新會話對象
二: isTokenValid(HttpServletRequest request)
判斷存儲在當前會話中的令牌值和請求參數中的令牌值是否匹配,如果匹配,返回true,否則返回false 。
以下情況返回false:
1,用戶的HttpSession不存在
2,用戶Session中沒有保存令牌值
3,在用戶請求參數中沒有令牌值
4,存儲在用戶Session范圍內的令牌值和請求參數中 的令牌值不匹配
三:resetToken()
刪除保存在Session范圍內的令牌值
示例代碼
1,進入目標頁,如 http://www.bt285.cn ,通過IndexAction轉發,其中需要保存令牌:






























至此,大功告成!
完整示例請參考附件。