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