電子商務(wù)網(wǎng)站的可持續(xù)發(fā)展
電子商務(wù)網(wǎng)站的可持續(xù)發(fā)展
2007年終于過去了,從焦油坑里爬出來幸存的人們,互相握手慶幸,喜極而泣,紛紛在博客上寫工作總結(jié)與來年展望,而我,難得的坐下來,遠(yuǎn)離自己負(fù)責(zé)的網(wǎng)站,想一想來年的布局。
在國家大力宣揚(yáng)環(huán)保,可持續(xù)發(fā)展的時候,從企業(yè),從網(wǎng)站,就我個人,都要講一個可持續(xù)發(fā)展,一夜暴富的思想只會浪費(fèi)精力,沒有方向,而只有平時注重積累,厚積薄發(fā),終會有從量變到質(zhì)變,扭轉(zhuǎn)局面的時候。
我們發(fā)力在向前奔跑的時候,也要適時的停下來,倒掉鞋子里的沙子,讓自己的步伐更輕快。
我所經(jīng)歷過電子商務(wù)網(wǎng)站都面臨的下面的問題,如何讓自己步子慢下來,解決這些問題,持續(xù)發(fā)展,是一個從管理和技術(shù)層面上,都比較有挑戰(zhàn)、讓人興奮的問題:
1.膨脹
公司業(yè)務(wù)向好,代碼越加越多,原來一個人寫一個類時,只是完成一兩個單一的功能,隨著需求的變化,一個核心類的代碼,不知不覺膨脹到一兩千行,有的Action代碼,也會超過1000行。接手的人,一般不敢動,也不愿意動接手的代碼,也就是說,他不會去重構(gòu)以前的代碼,一般就是線性的隨著需求的增加,代碼也不斷的增加,同時在開發(fā)時,總是八股文開發(fā),很機(jī)械、迂腐的套用一些重型的、所謂的J2EE設(shè)計(jì)模式,如Factory, DTO, Proxy等等,代碼量和代碼復(fù)雜度最終是線性增加。
則代碼復(fù)雜度和行數(shù)的膨脹,會是負(fù)面循環(huán),反過來影響你面對需求變化時態(tài)度。
舉一個例子,從用戶角度來講,訂單上增加一個字段的小需求,應(yīng)當(dāng)是很簡單的一件事,但是對開發(fā)人員來說,增加一個字段,則要確認(rèn)所有與訂單相關(guān)的頁面(相關(guān)的界面可能有十幾個)都要修改、重新布局,這個工作量可不小,而且容易漏改。這不是一個容易避免的事情,不僅是頁面,類也要修改。很多人寫的關(guān)聯(lián)查詢,結(jié)果放在DTO類而不是Map,扔到頁面上的話,則DTO類也要修改。
一般的性能問題,總是由開發(fā)人員的代碼造成的,而不是由架構(gòu)的Scalability瓶頸所造成的,累積的代碼,就像電器上日積日厚的灰塵一樣危險,隨時會短路。以前的僵尸代碼,會在數(shù)據(jù)量和訪問量慢慢增長到某一個臨界值的時候,突然復(fù)活,搞得你灰頭土臉。 如果你只會批評開發(fā)人員不小心,那種永遠(yuǎn)也解決不了問題,讓誰寫,都不能保證不會踩上地雷。領(lǐng)導(dǎo)不出BUG,只是因?yàn)樗麄儾粚懗绦颉?/p>
3. 鐵打的營盤,流水的兵
第一個人下棋,下到中途,離開了,第二人接手,接著下,以后可能會有第三個人,接手的人,怎么下怎么不順,這時總想重新下一盤,但沒有選擇,只能一邊問候著前人的老媽,一邊繼續(xù)走。最后,我們再把這盤棋復(fù)盤來看,做成一個棋譜,會有什么的感覺?
這一般不是兩個人能力差異的問題,是一個心理的問題,每個人都不愿意看別人的代碼,都覺得別人的代碼寫的爛,不愿意花點(diǎn)時間,來review同事或者前人代碼,他們認(rèn)為這是考古學(xué)家的事情。這樣的結(jié)果,如果不了解別人的代碼,就無從重構(gòu),在此基礎(chǔ)上增加功能或修改,只能說是亂上加亂。
要包容別人的代碼,現(xiàn)在不是找出是誰造成的,而是要從自己接手這一刻,開始改進(jìn)。
打江山的人,所基于的環(huán)境,是非常惡劣的,是非常不容易的,從無到有的創(chuàng)建一個網(wǎng)站的老員工,一個人做三個人的活,是非常值得尊敬的,接手別人,再怎么說,也是站在別人的肩膀上考慮問題。其實(shí)讓你先下,讓第二人再接手,他也會這么有同樣的思維,我們需要的是寬容,寬容與諒解應(yīng)當(dāng)是自上而下的,而不是自下而上,不然就變成,項(xiàng)目經(jīng)理說:我體諒你們,可領(lǐng)導(dǎo)不體諒我啊。
4.新來的員工不是考古學(xué)家
新來的員工抱怨個不停,確實(shí)是很討厭人,另一方面,從他的角度上來講,沒有選擇的權(quán)力,必須在別人代碼的基礎(chǔ)上增加新的功能或修正一些BUG,你不能用你最擅長的東西,當(dāng)別人的代碼是JSP+Servlet,你就用這個,你必須要遵守這個規(guī)則,同時也要遵守別人的開發(fā)習(xí)慣。
新員工就像一個考古者,站在一段象形文字的文物面前,來想出前人的意圖,確實(shí)非常的艱難。
所以每個公司的每個項(xiàng)目組,都應(yīng)當(dāng)向HR部門學(xué)習(xí),制訂一個良好的新員工入門索引,這個索引有什么內(nèi)容,每個人根據(jù)自己的項(xiàng)目,自己來考慮。這樣的索引目錄可以重用,不用來一個要講一遍,占用項(xiàng)目經(jīng)理的時間。
一般的人,都是被動的,8個小時,怎么過,都是過,平時不會去看別人的代碼,只是在自己承擔(dān)一個任務(wù)時,才會去看那些相關(guān)的代碼,這樣就會時間太緊了,手忙腳亂的,容易出錯。所以在平時,就要強(qiáng)制性的review代碼,是必須要的,你不能信賴別人的主動性,否則的話就是自食苦果。
5.脆弱的測試體系
長期膨脹,得不到改進(jìn)、重構(gòu)的代碼,每有新功能開發(fā),測試的代價非常、非常的高,因?yàn)榉浅H菀追稿e。
很多的公司并沒有一個良好的自動化回歸測試體系,所帶來的人工成本就是非常高,測試人員所做的工作,就是民工扛水泥包,又臟又累,測試覆蓋的效率又差。
頻繁ReOpen的BUG,會牽累process當(dāng)中每個環(huán)節(jié)的人,配置管理員,測試人員,開發(fā)人員,TeamLeader,也會影響到考核。帶來的眾多的參與其中的人,隨著運(yùn)轉(zhuǎn),打標(biāo)簽,提交測試,打回,修改、再打標(biāo)簽、再提交測試(此時所有開發(fā)人員的BUG都要改完才能提交),測試人員重新測試(原來已經(jīng)測試通過的功能,還要再測試一遍),重復(fù)N次。
其實(shí)我們自己從開發(fā),到測試部門,都可以不要對立,坐下面交流,來去考慮如何改進(jìn)。測試部門可以指導(dǎo)開發(fā)樹立測試的意識、思想、技巧,開發(fā)人員必須要承擔(dān)測試,不僅要寫單元測試,也要做功能測試,也要會自動化測試,這些除了可回歸的單元測試,很艱難,不容易做,但可以一步步的改進(jìn),其它的比如自動化的界面測試,其實(shí)是很容易的,花個兩天時間,把成員關(guān)在會議室里,搞Win runner界面測試,編寫可重用的測試腳本,定制有效的、覆蓋關(guān)鍵路徑的、可重用的數(shù)據(jù)源,還是能收到成效的,這樣當(dāng)需求變化時,那些沒有變化的功能,其腳本也不變,都可以在短時間內(nèi)回歸的測試一遍,而不要把成本直接轉(zhuǎn)嫁到測試部門。
關(guān)鍵是要不要走出第一步。 不知道為什么領(lǐng)導(dǎo)總是愿意相信冶百病的偏方,相信永動機(jī),相信不會犯錯,項(xiàng)目不會延期、百戰(zhàn)百勝的神人。 不要再花錢找一些天橋說書、賣大力丸的QA了。其實(shí)沒有一個人可以驅(qū)動一個龐大的團(tuán)隊(duì),還是要靠團(tuán)隊(duì)中的核心都行動起來。
5.缺乏從宏觀層面技術(shù)標(biāo)準(zhǔn)的概念統(tǒng)一和定義
隨著業(yè)務(wù)的發(fā)展,有很多的合作型的項(xiàng)目,子系統(tǒng)越來越多,同時要外接的系統(tǒng)越來越多, 做為一個分銷的平臺,可能要和外接的B2B系統(tǒng)對接,即要給別人在公網(wǎng)上發(fā)布接口,又要從第三方的系統(tǒng)獲取產(chǎn)品數(shù)據(jù)源,這種系統(tǒng)與系統(tǒng)之間的數(shù)據(jù)交換,缺乏統(tǒng)一的標(biāo)準(zhǔn),各種各樣的技術(shù)都可能有,又有不同的項(xiàng)目組負(fù)責(zé),各自為政,這不是他們的問題,他們不是CTO,不是架構(gòu)師。
從全局的基礎(chǔ)上,對系統(tǒng)的服務(wù)基礎(chǔ)設(shè)施建立一套共同的抽象規(guī)范,從架構(gòu)師的層面,進(jìn)行控制。
主要有:
1.服務(wù)的分類(支付網(wǎng)關(guān)、消息網(wǎng)關(guān)、中央工作流引擎、中心緩存服務(wù)、外部數(shù)據(jù)源對接服務(wù)、B2B訂單預(yù)訂接口服務(wù)等),以及各類服務(wù)的設(shè)計(jì)原則和建議
2.服務(wù)的技術(shù)標(biāo)準(zhǔn)定義與約束,耦合關(guān)系和原則的設(shè)計(jì)規(guī)范等
3.服務(wù)調(diào)用的接口詳細(xì)定義與約束,如此服務(wù)所支持的并發(fā)數(shù)的限制、超時調(diào)用的限制等。
4.統(tǒng)一技術(shù)標(biāo)準(zhǔn)和約束(如統(tǒng)一使用spring, ibatis, struts2, jquery等),不濫用,注重有效積累, 減小對后來的人增加維護(hù)難度,但確定下來的技術(shù),新來的人都要強(qiáng)制先學(xué)習(xí),從心理上接受這些技術(shù),先期消化這些技術(shù)曲線,避免臨陣磨槍,好事變成壞事。
5.被動的迎接變化,缺乏主動
規(guī)劃是很重要,但總有跟不上變化的時候,不可能有一勞永逸的架構(gòu)和平臺,初期業(yè)務(wù)和業(yè)務(wù)系統(tǒng)都是不成熟的,你在做一個系統(tǒng)時,可能只有兩三個人的團(tuán)隊(duì),所做的也只是一個初期的業(yè)務(wù),你不可能想到,未來我的系統(tǒng)可能要與114合做,要與某某網(wǎng)站合做,當(dāng)這個變化來時,你才能去做這個設(shè)計(jì)。
例如你只知道大陸酒店的業(yè)務(wù),當(dāng)你的業(yè)務(wù)要擴(kuò)展到香港、海外的時候,他們的業(yè)務(wù)規(guī)范與國內(nèi)的差別非常大,新的業(yè)務(wù)有可能在推翻你前期的設(shè)計(jì)。
你的系統(tǒng)要和某某網(wǎng)站一個合作業(yè)務(wù),要個某某銀行合做一個信用卡聯(lián)名卡業(yè)務(wù),這些合做型的項(xiàng)目,對方都是強(qiáng)勢的,你不是規(guī)則的制訂方,你是接受規(guī)則的一方,你在欣喜公司的業(yè)務(wù)蒸蒸日上的同時,恭喜你!你的系統(tǒng)的復(fù)雜度,也在蒸蒸日上。
唯一的辦法,就是要去主動的重構(gòu),對系統(tǒng)和代碼的復(fù)雜度降維,輕裝上陣,在一個更有利的位置,擁抱變化。當(dāng)然重構(gòu)不是陽春白雪,不慎會帶來新的不穩(wěn)定因素,只要是對代碼進(jìn)行變動,都會引入風(fēng)險,特別是遺留代碼, 你在擦拭灰塵的時候,卻不小心把桌上的瓷器給打破了,這時候主人肯定不會表揚(yáng)你的勤勞。不管怎么樣,這是你負(fù)責(zé)的項(xiàng)目,你跑不了,主動一點(diǎn),總比束手待斃強(qiáng)。
6.人力的焦油坑
人月神話這本書,只是給出版業(yè)帶來了繁榮,平時的我們總是一遍又一遍的從一個焦油坑出來,又掉到另一個焦油坑里去,可見看書是沒有用的。
由于難以維護(hù)的系統(tǒng),總是拖累正常配置的人力,使你感覺到人手總是他媽的緊,連正常的需求開發(fā)、BUG修正都滿足不了,那有時間重構(gòu)。所謂人力惡性循環(huán),就是好不容易一個熟悉代碼的人,培養(yǎng)起來,他也厭倦了,拍屁股走人了,再招人,就得招兩個人,因?yàn)橄到y(tǒng)的復(fù)雜度又增加了,需求又增加了。
這樣的結(jié)果很可怕,沒有時間來與時俱進(jìn),沒有時間做提高用戶體驗(yàn)、有價值的、增強(qiáng)用戶粘性的功能了,沒有創(chuàng)造性的工作,那些有創(chuàng)造力的人最終會含狠而去。
增強(qiáng)人力資源的儲備和技術(shù)儲備,是一個有效的措施,在平時做,而不是到關(guān)口了才想起,手忙腳亂的。
招聘人,要招self-proactive的人,能夠帶來變化,能夠解決問題,而不是抱怨的人,等著媽媽把飯嚼完送到嘴里的小鳥,否則就是效果相反,就造成了,加人,越加越累,因?yàn)槟闼拥模疾皇墙鉀Q問題的人,而且加人的時機(jī)也不對,平時,都沒有儲備,關(guān)鍵時候,才想起要人,太晚了。
考慮一下,隨便招一個普通的程序員,對于周圍關(guān)聯(lián)人的影響和所帶來的成本:
增加一個測試人員的工作量(可能他的BUG增多),增加美工的工作量(他不會寫頁面,不懂JS,不懂CSS),增加項(xiàng)目經(jīng)理的工作量,增加TeamLeader的工作量(做培訓(xùn)計(jì)劃,講需求,講技術(shù)),增加DBA的工作量(因?yàn)樗欢當(dāng)?shù)據(jù)庫,老寫一些讓服務(wù)器心臟博起的SQL 代碼)。
7. 松散的組織架構(gòu)
一個網(wǎng)站,大的網(wǎng)站,幾十個頻道,一般的也有十幾人項(xiàng)目組,他們在維護(hù)同一個網(wǎng)站,彼此之間的聯(lián)系很多,共同點(diǎn)也很多,看起來應(yīng)當(dāng)統(tǒng)一,都是自己人,也不難統(tǒng)一,但是現(xiàn)實(shí)卻是非常的艱難,卻如此的松散。
任何東西,自下而上,所帶來的必然是混亂和無序,考慮一下從組織架構(gòu)上來改變,建立CTO team,從全局的范圍內(nèi),自上而下的推動、控制,加強(qiáng)全局控制力,改變各個頻道或項(xiàng)目組各自為政的情況。將復(fù)雜的東西控制在上層,而不是程序員中間,任由其蔓延。
改變架構(gòu)師缺位,吃白飯的現(xiàn)狀,公司不是養(yǎng)著架構(gòu)師,學(xué)習(xí)新技術(shù)的,滿口之呼者也,酸腐的人,誰都要學(xué)習(xí),但要去一線解決問題。
架構(gòu)師要有責(zé)任,要有技術(shù)領(lǐng)導(dǎo)能力,要去Push別人,當(dāng)開發(fā)人員在造輪子的時候,首當(dāng)其首,責(zé)任就是架構(gòu)師,如果開發(fā)人員在重復(fù),還要你架構(gòu)師做什么?很多開發(fā)人員自己寫,是因?yàn)闆]有辦法,他也不想寫,但是現(xiàn)有的代碼庫當(dāng)中,沒有,或者沒有他適合用的東東。
posted on 2008-01-01 15:29 Speed 閱讀(2376) 評論(2) 編輯 收藏 所屬分類: 項(xiàng)目管理之道