這輩子怕是沒(méi)機(jī)會(huì)當(dāng)CTO了，只能假如一下了。CTO的主要職責(zé)是了解當(dāng)前流行的技術(shù)并有前瞻性地設(shè)定技術(shù)戰(zhàn)略；預(yù)先感知未來(lái)的技術(shù)發(fā)展方向，保持市場(chǎng)競(jìng)爭(zhēng)中技術(shù)較為領(lǐng)先的地位，這種領(lǐng)先應(yīng)該是可以轉(zhuǎn)化為商業(yè)價(jià)值的。CTO可以很大程度上左右技術(shù)型公司的命運(yùn)，如果作出正確的技術(shù)決策，就能在競(jìng)爭(zhēng)中牽著對(duì)手鼻子走，成為游戲規(guī)則的制定者；一旦做錯(cuò)決策，可能接下來(lái)幾年公司在技術(shù)上的投入都要化為泡影，浪費(fèi)大量人力財(cái)力。
商業(yè)公司追求最大化商業(yè)利潤(rùn)，CTO應(yīng)該能夠感知公司所處的業(yè)務(wù)市場(chǎng)的前景，如果整個(gè)市場(chǎng)處于萎縮狀態(tài)，公司難保獨(dú)善其身，所以CTO”最怕入錯(cuò)行"，CTO有責(zé)任勾畫公司未來(lái)的技術(shù)藍(lán)圖，并且他還應(yīng)該懂市場(chǎng). 我假想IBM當(dāng)初從軟件轉(zhuǎn)向服務(wù)，背后的推手應(yīng)該是CTO, 即使很多操作是由CEO來(lái)做，有前瞻性地提出轉(zhuǎn)型的人應(yīng)該是CTO，因?yàn)樗私饧夹g(shù)前景，或者說(shuō)，他了解某些方面的技術(shù)是否在未來(lái)有市場(chǎng)。
整個(gè)軟件行業(yè)都在流行收購(gòu)，但最初堅(jiān)定走收購(gòu)道路的先驅(qū)并不能得到廣泛的理解和認(rèn)可。多年以前，oracle開(kāi)始展現(xiàn)收購(gòu)戰(zhàn)略的時(shí)候，他的對(duì)手SAP有些揶揄意味地，針?shù)h相對(duì)提出“organic grow”, 依靠自身成長(zhǎng)。結(jié)果“成長(zhǎng)”了幾年發(fā)現(xiàn)還是對(duì)手依靠收購(gòu)擴(kuò)張得更快，才開(kāi)始跟著花錢收購(gòu)，從這個(gè)角度說(shuō)，SAP在戰(zhàn)略上已經(jīng)先輸一招兒了。收購(gòu)戰(zhàn)略或許是Larry Ellison的靈光一現(xiàn)，具體擴(kuò)充哪些方面的市場(chǎng)，選擇哪些技術(shù)領(lǐng)先的對(duì)手進(jìn)行收購(gòu)，收購(gòu)之后的整合規(guī)劃，這些應(yīng)該都屬于CTO的職責(zé)范圍。不過(guò)就Oracle這個(gè)例子，Larry的技術(shù)嗅覺(jué)可能已經(jīng)達(dá)到獵狗水準(zhǔn)了。
隨著開(kāi)源越來(lái)越盛行，技術(shù)也越來(lái)越傾向于開(kāi)放。在開(kāi)源盛行之前，每個(gè)公司，無(wú)論大小，都有自己的技術(shù)框架。發(fā)布的各個(gè)產(chǎn)品都架構(gòu)在這個(gè)框架之上。后來(lái)出現(xiàn)了不同方面的開(kāi)源技術(shù)框架，比如spring, hibernate, 各種MVC框架，CTO應(yīng)該直接領(lǐng)導(dǎo)團(tuán)隊(duì)對(duì)潛在可能吸收的新技術(shù)進(jìn)行評(píng)估。這些開(kāi)源的技術(shù)往往更優(yōu)秀，因?yàn)樾录夹g(shù)往往吸收了已有技術(shù)的精華并加以改進(jìn)，另外，開(kāi)源技術(shù)有廣泛的用戶群驗(yàn)證并幫助優(yōu)化。但同時(shí)，技術(shù)優(yōu)秀不表示成熟，公司里需要有專門的團(tuán)隊(duì)評(píng)估哪種技術(shù)可以在什么時(shí)候可以替代公司已有的技術(shù)。 這種選擇應(yīng)該傾向于保守，寧可略微慢一點(diǎn)，也不能冒進(jìn)做錯(cuò)技術(shù)選型。比如flex和html5在三年之前比較，不太容易看出哪種技術(shù)有更好的前景。我個(gè)人覺(jué)得現(xiàn)在比較這兩種技術(shù)的話，html5的優(yōu)勢(shì)明顯更大一些了。開(kāi)放的技術(shù)吸引更多的技術(shù)狂熱者推動(dòng)并完善它，html5似乎越來(lái)越好用了。技術(shù)選型的決策需要審慎地慢慢做，但一旦決策完成，就要雷厲風(fēng)行執(zhí)行決策。如果公司已經(jīng)有十個(gè)產(chǎn)品基于老框架開(kāi)發(fā)，那么不急于用新框架替代老框架重新修改老產(chǎn)品，畢竟商業(yè)產(chǎn)品最終目的是為了賣錢，而不是追求完美技術(shù)。更替已有產(chǎn)品框架無(wú)謂地引入風(fēng)險(xiǎn)。但是對(duì)于新產(chǎn)品，就要堅(jiān)定不移地使用經(jīng)過(guò)評(píng)估的新技術(shù)，如果公司范圍里，有不同的新老技術(shù)框架，維護(hù)起來(lái)的確有格外的成本，但死守老技術(shù)肯定是死路一條。CTO做技術(shù)決定的時(shí)候，需要把各個(gè)方面的考慮寫成文檔，讓一線技術(shù)人員了解技術(shù)決策的背景。上面用flex和html5舉例，并認(rèn)為CTO應(yīng)該讓一線技術(shù)人員了解技術(shù)決策背景，原因就在于我所在的公司一直在推行flex，而我一直疑惑這個(gè)決定是怎么做出來(lái)的，背后的依據(jù)是什么。
搞創(chuàng)新性的技術(shù)，申請(qǐng)專利當(dāng)然好，這個(gè)沒(méi)啥可說(shuō)的。 沒(méi)有一直追蹤新技術(shù)，況且最近幾個(gè)月在學(xué)數(shù)學(xué)，統(tǒng)計(jì)，sas之類跟java沒(méi)啥關(guān)系的技術(shù). 只是亂談一下對(duì)技術(shù)的看法，java方面?zhèn)€人看好的技術(shù)包括，
Spring —— 它的對(duì)手是JBoss seam, seam當(dāng)然也值得關(guān)注。在之前的博客討論Domain Driven Design的時(shí)候說(shuō)過(guò)，并不喜歡Spring所有方面，尤其它跟DDD的思路有相悖的地方。但Spring已經(jīng)成為一個(gè)流行平臺(tái)，它太流行了，所以各路專家好手都會(huì)在它的基礎(chǔ)上幫助改進(jìn)Spring. 連DDD理論的創(chuàng)建者Eric Evans都說(shuō)要把DDD的思想帶入Spring中，這就是龍頭的優(yōu)勢(shì)。公司跟進(jìn)Spring的技術(shù)風(fēng)險(xiǎn)小。Spring Roo是個(gè)格外值得關(guān)注的項(xiàng)目。
AspectJ —— AspectJ可以支撐技術(shù)框架，但是不適合大量用在應(yīng)用層面的程序里。
OSGI —— 其實(shí)不太了解OSGI，但他看起來(lái)比較容易成為標(biāo)準(zhǔn)
Groovy —— 很多人在討論誰(shuí)可以替代java， ruby, scala, phython還是groovy。我個(gè)人不覺(jué)得什么能替代java。橫向比較這幾個(gè)技術(shù)，比較看好groovy, 因?yàn)樗莏ava的親戚， 能自然地復(fù)用java成熟的產(chǎn)品應(yīng)用，所以它天生就有“成熟”的因子。人們往往看重快速開(kāi)發(fā)的特性，而我覺(jué)得，支持底層開(kāi)發(fā)和易維護(hù)性才更適合企業(yè)級(jí)開(kāi)發(fā)應(yīng)用。