原文地址:http://sjtu.blog.sohu.com/108202346.html
------------------------------------------軟開開發篇-------------------------
--------------------------
在我剛進軟開的時候,我想,這有什么啊,泡著茶寫點兒JAVA的日子么?最多用JAVA查
個數據庫,插個數據庫,還有啥?取錢存錢不也就是個人帳戶數據的此消彼長么?IDE會幫你
發現任何一個細小的失誤,而JAVA的簡單語法也不會讓你擔心有什么疑難雜癥.我不知道
跟我想法法一致的人有多少,但這確實就是我剛開始看軟開的眼光,安逸,掙閑錢的地方.
然則,就類似于能量守恒的定理,你做的東西少,一定是有人幫你做的東西多,JAVA是
簡單,可是那是JVM做的東西多,就如銀行,銀行的系統之復雜,是任何一個人無法想象的,
然而它的真正目的不是像IBM一樣要向別人出賣技術,所以對人才要求很高,它只是要使成
熟的技術造福于自己特色業務的推廣,造福于針對業務的系統的開發,說白了,是靠業務的
走紅而不是技術的復雜來掙錢,.JAVA雖簡單,但是要想徹頭徹尾學明白也難,那么銀行軟
開不允許這種復雜性存在,它簡單,但不徹底,那么我們就要讓它變得徹底的簡單,我們要
繼續開發自己的系統,提供一套很容易的開發平臺,當這套平臺開發出來之后,就招一批能
夠泡著茶寫JAVA的人去為業務服務,所以這就是軟開表面給大家造成這樣一種映向的原因
,工作難度是不大,但是絕對不是說銀行系統無人,只是那些平臺的工作者沒有浮出水面,
或者相對來說比較低調而已.
回到了我不屑的泡著茶寫JAVA,啊,的確,難度是不大,數據庫查來查去,日志記來記去
,流程可能夠復雜,但不是算法的復雜,只是實現起來很煩而已.但是,這些人真的有足夠的
工夫泡茶么?大家喜歡用日新月異來形容當今社會的發展,形勢日新月異了,業務需求一樣
也是日新月異,于是他們每天都要針對各種業務需求寫出不同的程序來,這個時候,他們的
關注點應該從技術轉向業務上來.業務需求給他們的壓力使他們再無暇關注技術本身,所
以寫JAVA的人也有寫JAVA的人的難處,只是業務上的繁瑣,向來被純正的喜歡搞底層/搞算
法的人所鄙視,的確,你的腦筋可能是很活,但是物盡其才,如果真的有這樣的思維,是應該
去搞一些高深的東西,研究技術的創新,寫JAVA,面對各種應用需求,是有些埋沒,但是話又
說回來,這樣腦筋很活的人能干這樣的工作么?工作再枯燥也需要有人做,他們能有耐心應
付這樣的枯燥么?
現在滿大街的小公司,沒有幾個是真正搞什么底層東西的,大家其實都在針對各種業
務做各種項目,銀行的開發之所以顯得有些乍眼,主要是因為:1,國企大氛圍;2,做出的東
西不用面對銷售壓力.其開發從技術含量來講,并無本質區別.
所以在銀行軟開工作,絕大部分人,絕對部分學計算機的人,需要面臨的是一個方向的
調整,需要將注意力從技術的深度轉到業務的廣度上來,一味盲目的覺得人家的工作乏味,
沒技術含量是不現實的,這也是我目前一個態度的轉變.
技術做到最后,就是大同,惟有業務,才能使其中的努力變成鈔票,大家(尤其是學計算
機的人,尤其是并不適合搞算法,搞底層的人)如果想進軟開,一定要有這樣的認識.
----------------------------------------------------------------------------
---------------------------------
------------------------------軟開的壓力篇----------------------------------
---------------------------
銀行軟開之所以有些乍眼,前面說過一條,不用面對銷售的壓力,是,我們做出來,業務
人員就得用,可是真的沒有壓力么?
我曾經聽說過這樣一個例子:一個工行網點的客戶經理,費盡了口舌,花了半天工
夫,說服了兩個客戶買基金,終于她們被說動了,坐下來填單子準備簽字了,這個時候,系統
出故障了,交易無法進行,沒辦法,客戶經理只能含著淚,帶著她們出來,把她們指給旁邊的
農行/建行(本人屬于工行,這些時候自然偏向工行,其他銀行朋友勿怪).這個例子,體現了
銀行軟開的一點壓力吧,不論什么時間,不論什么情況,不論你用什么手段什么方法,請你
給我保持住穩定,如果系統慢,客戶經理還可以陪客戶聊天,可是如果宕了,什么叫所有努
力付諸東流,這就是.
銀行在全國的網點,大的數以萬計,小的也數以千計吧,各個地方,招來的柜員,那是怎
么樣素質的都有,我曾聽說過這樣的柜員,這輩子她就會干兩件事,做取款的交易和存款的
交易,轉賬怎么辦?不會直接轉賬,先給A做提現的交易,再給B做存現的交易.內部實現怎么
別扭,但是外部的易用性你可得給我做足了,要不人家網點柜員是真不明白.記得唐朝詩人
白居易還是王安石,每寫一首詩,都要問老百姓能不能看懂,軟開面臨的情況也很類似,白
居易王安石歷史上就這么兩個人,然而你要求每個軟開員工每個項目都能做到這樣,不覺
得有壓力么?尤其是心高氣傲的計算機人,那 更是不屑了.可是,這是軟開,如果想進來玩,
請放下你的架子,認真/細致的處理好所有細節.
還有一個路人皆知的壓力,如何保障運營系統的安全,大家存錢的時候按完密碼鍵盤
了,系統沒有響應,柜員要求你重新輸入你會怎么想?難道不是我的密碼被盜了?你怎么能
保證?這樣的事情只要發生,只要桶上來,整個銀行總部的領導層都會開始關注這個問題,
甚至銀監會也要監督你的處理方式.這個時候,軟開員工身上的壓力將會可想而知,一旦最
后查明是程序的問題,所有一干人等(開發/測試/小組領導/部門領導),全部要受罰,這是
肯定的.網銀的運營,得有多少加密措施來保障數據的安全,且不說技術上的加密算法,就
拿業務來說,大家去辦個U盾,看那個網點工作人員得填多少單子,就知道銀行為保證安全
,得下多少精力了.
很多小公司,常年就給一個醫院/一個機關做項目,每做一個,掙10幾萬,然后全組人出
動到現場,花幾天時間,解決各種安裝遇到的問題,保證沒問題后再大家都撤,老總請大家
吃飯.銀行是怎么樣?做一個項目,全國所有省份所有網點均要投產,如果大家各自全都出
動,人手夠么?各種不一致的現象報上來,就是招10倍人也解決不了,所以銀行軟開壓力最
大的時候就是投產前夕,所有人從老總到小兵全部通宵達旦地守在電腦旁,應付各種可能
問題的出現,而且作為高風險機構,銀行在投產時候遇到的問題的解決,一定要準,一次性
成功!就如密碼鍵盤來說,出現問題是系統不響應,馬上回來改了,自己測過之后沒問題,再
發補丁,結果造成系統崩潰,你可以想象一下客戶的憤怒和不安!全中國這么大,我們不可
能到處跑過去看問題,所以,怎么樣才能保證程序在全國跑都沒問題,這是問題,也是巨大
的壓力.
銀行軟開的壓力,不來自于有沒有客戶,而來自于客戶太多,給我們系統造成的壓力,
無人問津的悲哀和無數人目光如炬的質詢,后果都一樣,讓你身心俱疲.
----------------------------------------------------------------------------
-------------------------------------
------------------------------銀行軟開的發展篇------------------------------
-----------------------------
銀行軟開的發展,對于學計算機的人來說,是一個不小的難題,也是很多人對于要不
要來這很猶豫的問題,技術和業務上的難以抉擇.還有國企多少的一點特色對自己發展造
成的干擾.
是的,這些都是問題,值得研究,第一個關于技術和業務的問題,我不想再多說,以掙錢
為終點,那么條條大路通羅馬,以境界的追求為終點,軟開可能不屬于一個好的地方,畢竟
你的心高高在上,不屑于一些簡單的活.路是自己選的,怎么走都可以,但是有一點要注意,
軟開是有一部分專搞技術的人的,只是因為銀行軟開的出發點是針對業務做開發,所以為
開發提供更便捷方式的平臺方面的人屬于少而精的配置.因為一些國企的特色,進來后可
能因為我這篇文章,一些想要進來做平臺的計算機人,有可能被領導分配到業務為主的開
發部門,關于這些人我想說的是,軟開屬于計算機研發為主的企業性質單位,人與人之間的
關系,沾點國企的影子,卻遠沒有那么復雜,關于自己角色的的定位,你可以跟領導好好溝
通你的長處和你希望干的內容,一般來說,領導是會多少考慮的,即便不能百分百滿足你需
要,百分之三十/四十/五十等等也能滿足一些,只會悶頭做技術,不會與人交流的人還是不
要來了,這里不適合你,即便你不跟領導溝通,你也需要跟下面分行的人溝通,交流,是工作
需要.
有的人會說,銀行軟開不掙錢,掙錢的是那些懂業務的人,這里首先要明確,什么樣算
掙錢,工資是每個人都掙的,要是拿這個說的話就沒意思了.大家說的應該是提成/分紅的
那一類人,的確,軟開掙不到那樣一些錢,那些屬于業務部該掙的錢.我覺得大家在討論這
樣一些問題的時候,首先要把自己擺正,軟開的人,其實也就相當于一個IT公司的人,IT公
司的那一部分分紅,軟開一分錢都不會少,而且軟開的錢有保證,不隨經濟危機而起伏.平
時福利也還可以.大家在羨慕業務的人拿得多的時候,是否可曾想到自己公司的銷售在談
好一個項目的時候提成也是遠勝于自己工資的呢?只要你自己肯轉變思路,專心學業務,借
助于自己的技術優勢,以后去業務部分掙錢也不是沒可能,關鍵就在于自己怎么看,不能既
不想作出改變現狀的努力,又覺得人家掙錢掙那么多不公平.再者如果你實在干不了業務,
那么就干技術,轉管理或者技術做到死當技術經理,總之就是成為領導,軟開領導同樣掙不
少錢,他們地位也和HP/IBM的高管地位一樣,也許錢一年比人家的少些,但是國企有國企的
福利,這個是外企不能比的.每個人都該知足,生活提高一點,抱怨就該少一點,自己已經掙
了30W一年,夠花了,聽說別的部門一年年終獎拿了20W,全年工資50W也該把心態放平和些,
不就是錢么,又不是不夠花,何不知足長樂呢?(注:業務部門不包括那些網點的柜員,他們
工資很少的).
軟開的發展空間最大的難處在我看來,是這里雖然由業務指導開發,但是開發量很大
,導致你也不能完全放下你的技術,這樣技術和業務之間徘徊不定,最終會有礙人的成長,
而且他的技術為了業務開發的便捷,被很好的簡化了最后有可能技術沒學成技術,業務也
沒懂多少.這個是確實,一個地方不可能十全十美.
我的意見是,你一生比較想過安穩的生活可以來這,你如果是一個有追求的人,并且腦
筋可以變通的人,也可以來這,你如果是是一個有追求的人,并且好學的人(無論是業務還
是技術,都多得讓你學不完,當你學得夠多就有資格提前成為領導了),也可以來這.一個有
追求的人,并且勤勉踏實的人也可以來,有這么兩類人,技術的大牛人不要來,你應該去百
度/GOOGLE發揮你的優勢所在,有追求,但是沒有什么魄力改變現狀的人,就不要來,免得一
輩子平庸的現狀可能讓你萬分苦惱.
還有一個難處我也提一下,它終歸是國企,它注重能力,畢竟銀行的系統不能瞎來,同
時也要求年限,年限一到才能往上升,所以不能忍的人也不要來了吧,當然也可以來了再走
~呵呵
最后我說一下薪資發展空間吧,現在銀行軟開一般待遇都不差,但是升值空間,在你沒
成為領導之前漲幅不大,其實任何地方都一樣,只有當領導,工資才能有質的變化,只是軟
開要當上領導的周期比外企要長一些,也不會長得不可理喻,大家有的總說想來這,覺得穩
定但是又嫌工資漲得不快,這就是典型的魚和熊掌都想得到的心理了,選擇了軟開,選擇了
國企的穩定,必然要放棄一部分收入的增幅,既然思想不夠純粹,要為追求奮斗一生,而是
選擇既有保障也要有追求的奮斗,那么你的生命里必將在別的地方付出一些代價,怎么樣
都能成功,問題還是在于個人吧.
我簡單說明一下,工行軟開,屬于總行編制,恩,就這么多了.
代理模式
代理模式的作用是:
為其他對象提供一種代理以控制對這個對象的訪問。在某些情況下,一個客戶不想或者不能直接引用另一個對象,而代理對象可以在客戶端和目標對象之間起到中介的作用。
代理模式一般涉及到的角色有:
抽象角色:聲明真實對象和代理對象的共同接口;
代理角色:代理對象角色內部含有對真實對象的引用,從而可以操作真實對象,同時代理對象提供與真實對象相同的接口以便在任何時刻都能代替真實對象。同時,代理對象可以在執行真實對象操作時,附加其他的操作,相當于對真實對象進行封裝。
真實角色:代理角色所代表的真實對象,是我們最終要引用的對象。
以下以《Java與模式》中的示例為例:
代碼: //抽象角色:
abstract public class Subject{
abstract public void request();
}
//真實角色:實現了Subject的request()方法。
public class RealSubject extends Subject{
public RealSubject(){
}
public void request(){
System.out.println("From real subject.");
}
}
//代理角色:
public class ProxySubject extends Subject{
private RealSubject realSubject; //以真實角色作為代理角色的屬性
public ProxySubject(){
}
public void request(){ //該方法封裝了真實對象的request方法
preRequest();
if( realSubject == null ){
realSubject = new RealSubject();
}
realSubject.request(); //此處執行真實對象的request方法
postRequest();
}
private void preRequest(){
//something you want to do before requesting
}
private void postRequest(){
//something you want to do after requesting
}
}
//客戶端調用:
Subject sub=new ProxySubject();
Sub.request();
由以上代碼可以看出,客戶實際需要調用的是RealSubject類的request()方法,現在用ProxySubject來代理RealSubject類,同樣達到目的,同時還封裝了其他方法(preRequest(),postRequest()),可以處理一些其他問題。
另外,如果要按照上述的方法使用代理模式,那么真實角色必須是事先已經存在的,并將其作為代理對象的內部屬性。但是實際使用時,一個真實角色必須對應一個代理角色,如果大量使用會導致類的急劇膨脹;此外,如果事先并不知道真實角色,該如何使用代理呢?這個問題可以通過Java的動態代理類來解決。
2.動態代理
Java動態代理類位于Java.lang.reflect包下,一般主要涉及到以下兩個類:
(1). Interface InvocationHandler:該接口中僅定義了一個方法Object:invoke(Object obj,Method method, Object[] args)。在實際使用時,第一個參數obj一般是指代理類,method是被代理的方法,如上例中的request(),args為該方法的參數數組。這個抽象方法在代理類中動態實現。
(2).Proxy:該類即為動態代理類,作用類似于上例中的ProxySubject,其中主要包含以下內容:
Protected Proxy(InvocationHandler h):構造函數,估計用于給內部的h賦值。
Static Class getProxyClass (ClassLoader loader, Class[] interfaces):獲得一個代理類,其中loader是類裝載器,interfaces是真實類所擁有的全部接口的數組。
Static Object newProxyInstance(ClassLoader loader, Class[] interfaces, InvocationHandler h):返回代理類的一個實例,返回后的代理類可以當作被代理類使用(可使用被代理類的在Subject接口中聲明過的方法)。
所謂Dynamic Proxy是這樣一種class:它是在運行時生成的class,在生成它時你必須提供一組interface給它,然后該class就宣稱它實現了這些interface。你當然可以把該class的實例當作這些interface中的任何一個來用。當然啦,這個Dynamic Proxy其實就是一個Proxy,它不會替你作實質性的工作,在生成它的實例時你必須提供一個handler,由它接管實際的工作。(參見文獻3)
在使用動態代理類時,我們必須實現InvocationHandler接口,以第一節中的示例為例:
代碼: //抽象角色(之前是抽象類,此處應改為接口):
public interface Subject{
public void request();
}
//具體角色RealSubject:實現了Subject接口的request()方法。
public class RealSubject implements Subject{
public RealSubject(){
}
public void request(){
System.out.println("From real subject.");
}
}
//代理角色:
import java.lang.reflect.Method;
import java.lang.reflect.InvocationHandler;
public class DynamicSubject implements InvocationHandler{
private Object sub;
public DynamicSubject(Object sub){
this.sub = sub;
}
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
System.out.println("before calling " + method);
method.invoke(sub,args);
System.out.println("after calling " + method);
return null;
}
}
該代理類的內部屬性為Object類,實際使用時通過該類的構造函數DynamicSubject(Object sub)對其賦值;此外,在該類還實現了invoke方法,該方法中的"method.invoke(sub,args)" 其實就是調用被代理對象的將要被執行的方法,方法參數sub是實際的被代理對象,args為執行被代理對象相應操作所需的參數。通過動態代理類,我們可以在調用之前或之后執行一些相關操作。
客戶端:
代碼: import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
public class Client{
static public void main(String[] args) throws Throwable{
RealSubject rs = new RealSubject(); //在這里指定被代理類
InvocationHandler ds = new DynamicSubject(rs); //初始化代理類
Class cls = rs.getClass();
//以下是分解步驟
/*
Class c = Proxy.getProxyClass(cls.getClassLoader(),cls.getInterfaces());
Constructor ct=c.getConstructor(new Class[]{InvocationHandler.class});
Subject subject =(Subject) ct.newInstance(new Object[]{ds});
*/
//以下是一次性生成
Subject subject = (Subject) Proxy.newProxyInstance(cls.getClassLoader(),cls.getInterfaces(),ds);
subject.request();
}
通過這種方式,被代理的對象(RealSubject)可以在運行時動態改變,需要控制的接口(Subject接口)可以在運行時改變,控制的方式(DynamicSubject類)也可以動態改變,從而實現了非常靈活的動態代理關系。
3.代理模式使用原因和應用方面
(1)授權機制 不同級別的用戶對同一對象擁有不同的訪問權利,如Jive論壇系統中,就使用Proxy進行授權機制控制,訪問論壇有兩種人:注冊用戶和游客(未注冊用戶),Jive中就通過類似ForumProxy這樣的代理來控制這兩種用戶對論壇的訪問權限.
(2)某個客戶端不能直接操作到某個對象,但又必須和那個對象有所互動.
舉例兩個具體情況:
如果那個對象是一個是很大的圖片,需要花費很長時間才能顯示出來,那么當這個圖片包含在文檔中時,使用編輯器或瀏覽器打開這個文檔,打開文檔必須很迅速,不能等待大圖片處理完成,這時需要做個圖片Proxy來代替真正的圖片.
如果那個對象在Internet的某個遠端服務器上,直接操作這個對象因為網絡速度原因可能比較慢,那我們可以先用Proxy來代替那個對象.
總之原則是,對于開銷很大的對象,只有在使用它時才創建,這個原則可以為我們節省很多寶貴的Java內存. 所以,有些人認為Java耗費資源內存,我以為這和程序編制思路也有一定的關系.
(3)現實中,Proxy應用范圍很廣,現在流行的分布計算方式RMI和Corba等都是Proxy模式的應用
本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/goodHabit/archive/2009/11/08/4784461.aspx
JAVA反射機制