校園級(jí)別的程序員的標(biāo)志：

代碼中最多的是嵌套if（null == xxx），還要告訴你，null必須寫在前面，我靠。

防止把==寫成=，c語言時(shí)代常犯的錯(cuò)誤。由于null不能做左值，在寫=的時(shí)候出現(xiàn)編譯錯(cuò)誤。一般來講，在java中，由于boolean和其他類型不會(huì)作隱式轉(zhuǎn)換，因此這么寫沒有意義。

寫著寫著突然想起來這么個(gè)代碼：

Boolean b = true;

if（b=null）

{

}

順利編譯通過，也許把null寫在==的左側(cè)還是有意義的。

后臺(tái)滿是system.out.println（“--------程序應(yīng)該會(huì)運(yùn)行到此處的。。。userId：”）。

調(diào)試程序過程中，如果想在控制臺(tái)中打印什么東西，最好用log工具，如已經(jīng)在多少年前就俗到家了的log4j。好處是：打印日志的語句和控制是否打印日志、控制怎樣打印日志的語句是解耦的，可以在程序中隨便寫打印log的語句，然后在正式上線后，通過某個(gè)選項(xiàng)，令其全部失效。

當(dāng)年流行的組合是log4j+apache commons logging，在程序中引用commons logging的api，build path中放一個(gè)log4j的jar包然后再寫個(gè)log4j的配置文件并且初始化一下，實(shí)際生效的就是log4j了。這樣做的好處是，想換日志實(shí)現(xiàn)類的時(shí)候，不用修改程序代碼。

今年的流行款是logback+slf4j，對(duì)應(yīng)上面那兩個(gè)東西。logback的實(shí)現(xiàn)據(jù)說效率高了多少倍，不過除了非常關(guān)鍵的模塊外，這點(diǎn)開銷基本可以忽略不計(jì)。

html頁面總是對(duì)不起一兩個(gè)div的線，老用firefox去框框顯示那個(gè)div。

搞前端的都是神，我到現(xiàn)在也對(duì)不齊那堆div。另提一句，bootstrap是良心作，好人一生平安。

IO異常處理那個(gè)就是疊羅漢啊。

異常處理是個(gè)技術(shù)活，我當(dāng)年的思路是，根本不知道有非受控異常這件事，出現(xiàn)受控異常未處理的編譯錯(cuò)誤時(shí)，點(diǎn)開eclipse的自動(dòng)處理選項(xiàng)，然后按照心情選一個(gè)。

一點(diǎn)經(jīng)驗(yàn)：

數(shù)據(jù)庫異常、io異常就直接上拋，如果框架非得搞成checked的話（譬如ibatis2.x），發(fā)現(xiàn)了就給封一層RuntimeException，一直拋到頂層讓這個(gè)事務(wù)掛了就好了。然后客戶會(huì)明確的知道這個(gè)程序sb了，怒不可遏的給維護(hù)打電話，然后維護(hù)遠(yuǎn)程ssh，重啟數(shù)據(jù)庫了事。如果項(xiàng)目經(jīng)理稍稍良心一點(diǎn)的話，針對(duì)這種錯(cuò)誤可以做的包括：1、打異常log，2、給客戶一個(gè)明確的提示“系統(tǒng)掛掉了，請(qǐng)聯(lián)系系統(tǒng)維護(hù)人員電話是13xxxxxxxxx”而不是顯示一堆異常堆棧然后再讓客戶翻電話本。想寫段代碼自動(dòng)處理這些異常的想法不是不能實(shí)現(xiàn)，但對(duì)于業(yè)務(wù)定制類的系統(tǒng)來說，代價(jià)太大。

nullpointerexception、各種illegelxxxexception，其它各種開發(fā)人員懶得去學(xué)的異常，這些基本上都是程序的bug，開發(fā)測(cè)試階段出現(xiàn)了就調(diào)整，打各種補(bǔ)丁，直至所有的測(cè)試流程都走通。實(shí)際運(yùn)行階段再出的話，類比上一條。

在業(yè)務(wù)基本走通，正常流程都沒問題了，而項(xiàng)目組又恰好有足夠的時(shí)間投入在異常架構(gòu)上，可以做下面的事：分析業(yè)務(wù)，找出需要處理的業(yè)務(wù)異常，如根據(jù)身份證號(hào)查出了兩個(gè)完全不同的人等，定義處理這些異常的邏輯，定義項(xiàng)目級(jí)別的異常基類api，之后就可以從底層一層層的加各種if判斷，拋出異常，再向上找到該處理異常的地方，寫catch代碼。最重要的就是在拋異常的時(shí)候，把所有有意義的信息都記錄下來，比如上面說的身份證號(hào)的異常，起碼要記錄身份證號(hào)是什么、找出的兩個(gè)人的主鍵，另外還可以記錄操作時(shí)間、操作人等信息。只要在異常拋出的時(shí)候做到這一點(diǎn)，隨便你決定在哪一層catch，哪怕只做個(gè)log，都會(huì)讓維護(hù)人員、后續(xù)開發(fā)人員感謝你的良心。

一般級(jí)別的程序員標(biāo)志：

會(huì)struts+spring+hibernate|mybatis，面試神器。

曾經(jīng)的觀點(diǎn)：

怎樣用這些東西：找個(gè)文檔讀一點(diǎn)，都能學(xué)會(huì)。

為什么要用這些東西：體現(xiàn)真正水平的問題。

現(xiàn)在的觀點(diǎn)：

怎樣用這些東西：做到隨便給給技術(shù)，讀讀文檔就能用上的，都是水平已經(jīng)不錯(cuò)了的人。

為什么要用這些東西：網(wǎng)上答案一搜一大把，需要分辨是直接拿的結(jié)論，還是真被某些雷炸過然后很良心的告訴你，struts2真操蛋。

struts1、2、spring mvc這一層，用的并不多。由于沒做過什么訪問量特別高的項(xiàng)目，因此對(duì)struts2的效率并沒有太多吐槽。現(xiàn)在的選擇標(biāo)準(zhǔn)：1、是否提供了足夠的語法糖讓一般水平的人也能夠快速開發(fā) 2、是否沒有提供不恰當(dāng)?shù)恼Z法糖，從而大幅度的增加維護(hù)難度。annotation、零配置這些東西，個(gè)人覺得最好用于元屬性設(shè)置，而不要用于流程控制。曾經(jīng)有個(gè)同事發(fā)現(xiàn)前臺(tái)傳進(jìn)來的參數(shù)莫名其妙的會(huì)丟一個(gè)，后來發(fā)現(xiàn)在引用的某個(gè)jar包中有一個(gè)annotation方式定義的filter。盡管實(shí)際上的問題是架構(gòu)組沒有寫完善的文檔，沒有做培訓(xùn)，但是經(jīng)過那件事之后我也同意，這種東西放在一個(gè)統(tǒng)一的配置文件里面看著會(huì)更清楚一點(diǎn)，控制粒度也更細(xì)一點(diǎn)。

當(dāng)年實(shí)訓(xùn)初學(xué)spring就覺得這東西很蛋疼，迄今為止一直沒遇到復(fù)雜度高到有大批量屬性需要注入的地方。aop的應(yīng)用場(chǎng)景倒是遇到幾個(gè)，不過出于對(duì)龐大的spring以及配置文件膨脹的恐懼，我寧愿改變整個(gè)的框架，定一個(gè)抽象層然后用各種各樣的strategy模式。倒是覺得有完善annotation支持的輕量級(jí)aop應(yīng)該是個(gè)不錯(cuò)的選擇。

hibernate用的也不多，我好像對(duì)主流的s2sh有本能的抗拒……一直對(duì)sql的結(jié)構(gòu)化有深深的執(zhí)著，因?yàn)槟阏娴牟幌霙]事總給別人調(diào)那一堆動(dòng)輒五六行變量名很奇怪大小寫都有的sql語句。所以在看到hibernate做某些復(fù)雜查詢必須用hql的時(shí)候就放棄了這門技術(shù)了，sql本身就不想看，再發(fā)現(xiàn)這sql實(shí)際上是在java里面用String拼起來的……

ibatis/Mybatis一系用的比較多的原因是，職業(yè)生涯用到的首套一站式框架的作者就用的這玩意兒，屬于馬屁股性質(zhì)的事情。這東西的好處就是把sql和java代碼分離開了，程序看起來比較干凈。但是讓每個(gè)模塊的程序員都去決定要寫哪些sql，怎樣寫，同樣是個(gè)很可怕的事情。所以當(dāng)年我定義了一套針對(duì)每張表的標(biāo)準(zhǔn)sql列表，幾項(xiàng)最基本的CRUD操作。select操作只支持id查詢和各個(gè)屬性的and相等查詢。這個(gè)基本上已經(jīng)可以滿足80%的需求了，剩下20%，定好了配置文件分割策略后，找個(gè)sql好點(diǎn)的人慢慢寫就是了。另外，這東西的一大槽點(diǎn)是只支持假分頁，我們的處理方式一般是忽悠客戶買個(gè)內(nèi)存大點(diǎn)的機(jī)器就得了，不具備這種忽悠機(jī)制的同行們請(qǐng)慎重選擇，ibatis想解決這個(gè)問題需要hack jar包，mybatis也需要自己寫個(gè)插件支持，大概有個(gè)半天到一天的工作量。

再后來覺得配置文件有些繁瑣，所以又在apache commons dbutils基礎(chǔ)上封裝了一套，不用寫配置文件，定義好列名和屬性名的映射關(guān)系后，自動(dòng)生成CRUD操作并作db訪問操作。在封裝復(fù)雜的select操作時(shí)發(fā)現(xiàn)了nutz這個(gè)東西，覺得思路基本一致，就懶得再繼續(xù)寫了。

nutz提供的dao工具實(shí)現(xiàn)了用比較結(jié)構(gòu)化的方法拼sql語句，試了試，用著還不錯(cuò)。事務(wù)管理機(jī)制據(jù)說有槽點(diǎn)，沒細(xì)看。

決定我沒有實(shí)際使用的槽點(diǎn)：1、不支持手動(dòng)配置db和java的名稱映射，而我給項(xiàng)目組定的映射規(guī)則又比較奇葩，給每個(gè)屬性都寫個(gè)annotation有點(diǎn)蛋疼。2、貌似是用反射方式直接讀寫java屬性，而不是用java bean規(guī)范的get、set方法，而我的很多工具類都是做的虛擬屬性，只有兩個(gè)無比復(fù)雜的get/set方法，沒有實(shí)際的屬性。當(dāng)發(fā)現(xiàn)annotation只能加在字段上時(shí)，欲哭無淚只好放棄了。

現(xiàn)在項(xiàng)目中用著的還是mybatis，用官方提供的mybatis generator生成配置文件，單表操作支持得很完善，多表操作自己寫sql解決。

能分清楚group和having的區(qū)別。

關(guān)于db另一個(gè)要說的問題：復(fù)雜的東西盡量別放sql里面。orm層提供基本操作就夠了，剩下的邏輯交給java層表達(dá)。做好封裝，實(shí)在有效率問題，再專門進(jìn)行優(yōu)化。好吧，我承認(rèn)我不知道這哥倆到底有什么區(qū)別。

數(shù)據(jù)庫里的字段必須只能2個(gè)長度，不能32個(gè)長度，性能問題。表名要以T開頭，蛋快碎了。

長度問題沒看懂要說什么。前兩天遇到一個(gè)問題，在oracle中如果用char類型的，而實(shí)際內(nèi)容又不正好等于char長度的時(shí)候，select出來的數(shù)據(jù)是帶空格的……各種trim都感覺不太好使之后，果斷varchar2了。反正這點(diǎn)效率差異，早就被各種奇葩的業(yè)務(wù)邏輯給抵消了，還是那句話，有問題的時(shí)候再優(yōu)化。

表名問題，我覺得加前綴還是為了跟視圖進(jìn)行區(qū)分。當(dāng)表只有幾張時(shí)，什么區(qū)分也不用做，當(dāng)表有一百七十張時(shí)，什么區(qū)分都不管用。所以，戰(zhàn)略上看需求決定就行了……

一點(diǎn)經(jīng)驗(yàn)：通通加T跟沒加是一個(gè)效果。現(xiàn)在項(xiàng)目中的做法：數(shù)據(jù)庫中大部分的表都是對(duì)應(yīng)了一個(gè)業(yè)務(wù)實(shí)體，這些類直接寫名字就行，在這些表上建的視圖統(tǒng)一加一個(gè)V_前綴，也就能起到區(qū)分效果了。一般來講，一百七十張表中至少有一百五十五張以上都是這種表。其他的表，則大多對(duì)應(yīng)了某些特殊場(chǎng)景或算法，實(shí)際開發(fā)中一般由專門的核心人員負(fù)責(zé)，可以按照權(quán)限控制、事務(wù)控制等實(shí)際用途，加個(gè)什么前綴，誰負(fù)責(zé)哪個(gè)模塊就關(guān)注哪個(gè)前綴就好了。

會(huì)用jquery.ajax獲取數(shù)據(jù)，不知道ajax的同步鎖。

我也不知道。對(duì)于一切鎖，我的意見都是，上個(gè)最大粒度的，保證數(shù)據(jù)一致性。出現(xiàn)的所有問題具體分析，逐個(gè)減小鎖的粒度。

一會(huì)顯示的表格有數(shù)據(jù)，一會(huì)又沒數(shù)據(jù)啊，太生氣了。

遇到此類抱怨時(shí)：1、告訴他，工業(yè)界沒有玄幻故事，2、再提同樣的問題的話，辭了他。讓這種人覺得自己還有混在程序員界的錯(cuò)覺是對(duì)他的不負(fù)責(zé)。

詳細(xì)記錄當(dāng)時(shí)的運(yùn)行環(huán)境，一般都會(huì)找到原因的。

騷年級(jí)別的程序員標(biāo)志：

懂div的float，clear的含義。

1、上一套bootstrap，解決80%的問題。2、剩下20%的問題，找個(gè)跟你關(guān)系不錯(cuò)的前端，沒事多請(qǐng)人家吃吃飯，然后就解決了。

數(shù)據(jù)庫超過n記錄表橫向縱向分表。

問題在于，n等于幾。高估n無所謂，反正要出現(xiàn)的問題肯定會(huì)出現(xiàn)。低估n的話，造成的進(jìn)度損失會(huì)讓你有自殺的沖動(dòng)，造成的數(shù)據(jù)損失會(huì)讓項(xiàng)目經(jīng)理有殺了你的沖動(dòng)。

知道oracle的用with，這個(gè)sql寫起來看起就舒服了。

這個(gè)也不會(huì)，粗略google了一下，確實(shí)有點(diǎn)用途。

看到aop能說一大堆廢話，又是代理又是反射，就是沒寫過。

你的錯(cuò)誤在于，不知道用途就研究實(shí)現(xiàn)原理。

DateUtil一定寫過好多次，簡(jiǎn)直太復(fù)雜了，非常多的格式定義，那個(gè)static格式變量，必須要深刻理解才能知道。

1、有句評(píng)價(jià)說的好：把一個(gè)工具包的幾乎所有方法都寫到標(biāo)記過時(shí)，這是得有多仇視這個(gè)社會(huì)。

2、自從有了JodaDate，媽媽再也不擔(dān)心我的日期處理了。當(dāng)一個(gè)同事又一次熬通宵寫出一個(gè)DateUtil然后我拿出了JodaDate之后……

砥柱級(jí)別的程序員標(biāo)志：

會(huì)架構(gòu)程序，能用extjs或者easyui寫個(gè)框架frame，還能寫個(gè)遞歸menu。

所有的知識(shí)點(diǎn)都很基礎(chǔ)，但是能把這一切都完整寫出來，完成debug之后讓項(xiàng)目組用上，一段時(shí)間之后還能維護(hù)或者添加點(diǎn)新功能的，都是中流砥柱。說白了，這是個(gè)情商要求大于智商要求的活。業(yè)務(wù)系統(tǒng)定制開發(fā)，實(shí)際上都是這種類型的活。你并不需要有特別高深的技術(shù)，也不會(huì)突然面對(duì)多么巨大的困難，只會(huì)在一個(gè)個(gè)看似不起眼的bug中，把所有激情都消磨殆盡。

會(huì)用ps處理圖片，還能寫上幾個(gè)字，XXXX系統(tǒng)beta版本。

會(huì)ps的都是神，不解釋。

基本上util包的作者，用log或者攔截器記錄日志。

并且，愿意跟一切動(dòng)過你util包的人玩命。

能用fiter或者Interceptor處理權(quán)限，但是搞不懂如何處理button的權(quán)限。

在業(yè)務(wù)級(jí)別去掉button權(quán)限的需求就好了。

真正的解決方案沒有實(shí)際執(zhí)行過，只是一個(gè)想法：系統(tǒng)建模的時(shí)候，權(quán)限模型直接建到操作級(jí)，比方說每個(gè)Action處理函數(shù)對(duì)應(yīng)一個(gè)操作，針對(duì)這個(gè)操作定義每個(gè)角色的權(quán)限。button在概念上同樣映射到權(quán)限就可以了。至于怎么針對(duì)函數(shù)做權(quán)限控制，隨便你用xml或者annotation定義一下就行。

明白了異常處理轉(zhuǎn)換成RuntimeExcetion太好了，不會(huì)丟失而且好處理。

異常處理真是個(gè)技術(shù)活。當(dāng)我說，我也不知道我的方案好在哪，只是覺得你們的方式不優(yōu)雅時(shí)，我清楚的聽到了對(duì)方心里的嗤笑聲。往往我的結(jié)論都會(huì)在大概三個(gè)模塊開發(fā)周期之內(nèi)被確認(rèn)。

page分頁里代碼和css樣式和類class都在jsptag里，認(rèn)為沒法分啊，這個(gè)是典型。

前端用于提交參數(shù)，目測(cè)所說的代碼是計(jì)算page、rowperpage這些屬性的。隨便找套js grid控件，看看他們的參數(shù)提交方式，前端不依賴任何jsp，分到那個(gè)份上我覺得就足夠了。

小牛級(jí)別的程序員：

知道url資源樹和menu的區(qū)別。

不明覺厲。這種概念性的東西其實(shí)挺多人都挺不重視的，曾經(jīng)很反對(duì)這種不重視，但是重視了很多年還真沒重視到什么收獲。現(xiàn)在的觀點(diǎn)就是，用到了再說。

能手寫css，懂important能拿來做啥，這個(gè)好玩得很。

又是前端，上bootstrap吧

能夠理解數(shù)據(jù)庫必須用主外鍵，否則那幫家伙一定會(huì)亂寫程序。

只要是實(shí)體類，必須有主鍵，并且一定要有物理主鍵，不能只依賴于邏輯主鍵。id這東西，找不到其他用途的話就簡(jiǎn)單的當(dāng)個(gè)快速查詢定位的工具就行。隨著業(yè)務(wù)復(fù)雜度的增加，你會(huì)發(fā)現(xiàn)它的表現(xiàn)力越來越強(qiáng)。在大部分依賴于持久化的業(yè)務(wù)類系統(tǒng)中，可以簡(jiǎn)單的定義，有id就代表這東西存在，沒id就代表不存在，順著這條思路往下想，很多業(yè)務(wù)都會(huì)簡(jiǎn)化。

只用id做外鍵，不要用神馬身份證號(hào)、訂單編號(hào)之類的東西。然后你的程序隨便怎么寫都能寫得下去。

會(huì)設(shè)計(jì)數(shù)據(jù)庫模型，幾百張表的小意思。

針對(duì)真實(shí)世界，只作抽象，不作修改，保持整個(gè)系統(tǒng)概念上的一致性。然后你會(huì)發(fā)現(xiàn)，設(shè)計(jì)的模型會(huì)恰好符合數(shù)據(jù)庫設(shè)計(jì)的各種準(zhǔn)則。這時(shí)候這個(gè)數(shù)據(jù)庫結(jié)構(gòu)就能用了。

如果你設(shè)計(jì)出一張自認(rèn)為很有用的關(guān)系表，卻起不出合適的名字來；或者數(shù)據(jù)庫中有一個(gè)不是純粹為了效率問題而設(shè)置的冗余字段，相信我，你終將遇到一個(gè)你的模型無法表現(xiàn)的業(yè)務(wù)需求。

注釋用//只有一行，不用/**多行，因?yàn)槌绦蚣醋⑨尅?/p>

jdk標(biāo)準(zhǔn)注釋都不用，那javadoc咋辦？

好吧，程序即注釋這東西，幾個(gè)水平相當(dāng)、思路相近的人，通過不定期的結(jié)對(duì)編程、互相重構(gòu)代碼，還是可以做到的。如果是大規(guī)模的開發(fā)，還是建議通過架構(gòu)層面合理的分層解決。

知道struts模型驅(qū)動(dòng)代替屬性注入，方便太多事了。

又一個(gè)語法糖。有了實(shí)際需求再用，到底用不用不要爭(zhēng)論起來沒完，遵循這兩點(diǎn)就行了。這個(gè)真心不是核心問題。

用過this做參數(shù)傳遞，哈好多人都沒用見過。

哈真神奇！這話真有人對(duì)我說過。

技術(shù)上this就是個(gè)指向自身的引用。某些具體的場(chǎng)景確實(shí)用起來很有意思，高層面的意義還沒太想清楚，只有一個(gè)模模糊糊的印象，大概就是做了一件把自身委托給其他對(duì)象的事，封裝了某個(gè)參數(shù)傳遞的過程，也就是封裝了自身和被委托類的關(guān)系。

SE級(jí)別的程序員：

研究過struts，hibernate的源代碼，ui里有顏色互補(bǔ)概念，看起來是要舒服點(diǎn)啊。

學(xué)源代碼要跟寫代碼結(jié)合起來執(zhí)行，學(xué)到了新的模式之后，多想想有什么應(yīng)用場(chǎng)景，但是真的實(shí)際使用要慎重。譬如說看到struts2的層層wrapper模式后就用了一次，被噴了好長時(shí)間

覺得struts，hibernate，spring，要扔掉一個(gè)框架，一定是spring，這個(gè)廢啊。

讓我選的話，我扔hibernate。

寫過mvc，知道前端攔截器，中心分發(fā)器，后置處理，bean映射。

要知道就算沒有這些概念，代碼層面也一定會(huì)實(shí)現(xiàn)mvc的全部功能。然后找到?jīng)]有這些概念的代價(jià)，哪些東西就耦合了，哪些變更就應(yīng)對(duì)不了了等等。最后你的水平就提高了。

會(huì)用模型驅(qū)動(dòng)user.save（），代替dao。

少傳一個(gè)參數(shù)，概念上優(yōu)雅了一些。模型驅(qū)動(dòng)太考驗(yàn)建模能力，一定要在一個(gè)范圍內(nèi)把所有問題想清楚再使用。建議把DDD那本書看個(gè)兩三遍再說。

不過這東西看上去真的很吸引人。

能用metadata生成一堆亂七八雜的代碼，這下爽多了。

metadata的解釋是“描述數(shù)據(jù)的數(shù)據(jù)”，比方說數(shù)據(jù)庫的表結(jié)構(gòu)定義可能就算是一種metadata。在寫代碼過程中能正確的抽象出元數(shù)據(jù)之后，眼光會(huì)提高一個(gè)層次，至于是不是要搞生成代碼的工具，因項(xiàng)目而異。

曾經(jīng)用過一段時(shí)間的freemarker，寫一些輕量級(jí)的代碼生成工具還是挺好用的。

研究過Annotation，用Annotation寫過注解，知道Annotation如何繼承，太復(fù)雜搞不懂。

拿Annotation實(shí)現(xiàn)過一套Model工具，沒有深入了解過ejb，可能有點(diǎn)entity bean的思路在里面把。

前面說過一部分annotation了。這東西的好處就是把元數(shù)據(jù)跟java代碼放到一起了，于是好找也好改了，壞處也是放在一起所以耦合了。如果代碼量大到一定程度之后，最好把所有主力都集合到一塊兒商量一下，到底是xml好還是annotation好。

在代碼量沒大到一定程度，或者annotation配置的數(shù)據(jù)僅僅是annotation所在的類自己用的話，可以在開發(fā)效率上考慮一下這個(gè)問題。jdk提供了語言層面的annotation操作工具，使用簡(jiǎn)單，有一部分的編譯期檢查，寫起來比xml要舒服。另外，個(gè)人認(rèn)為annotation的語法不太適合定義層次太深的結(jié)構(gòu)，在類前面寫上四層annotation再用ide做個(gè)formatter，說實(shí)話挺愁人的。

BOSS級(jí)別的程序員：

仰慕一下。。。。

以上經(jīng)驗(yàn)建立在如下基礎(chǔ)上：

我做的項(xiàng)目是大部分是技術(shù)要求特別簡(jiǎn)單，業(yè)務(wù)要求中等復(fù)雜，需求變更特別頻繁，開發(fā)人員平均素質(zhì)不足，工期不是很緊的類型，所以關(guān)注點(diǎn)集中在如何通過分層隔離業(yè)務(wù)復(fù)雜度，以及如何通過語法糖來降低開發(fā)復(fù)雜度。bug方面，比較關(guān)注的是影響數(shù)據(jù)一致性的bug，只要不影響數(shù)據(jù)一致性，哪怕系統(tǒng)直接掛了，都不是影響項(xiàng)目的生死因素。

在做技術(shù)方案的時(shí)候，比較傾向于：

1、通過各種設(shè)計(jì)模式封裝復(fù)雜度，提供盡量簡(jiǎn)單，甚至無腦開發(fā)的接口

2、忽略一切效率問題，在業(yè)務(wù)打通之后再想優(yōu)化的事

3、能在編譯器做的事就不往運(yùn)行期放，哪怕會(huì)影響開發(fā)的靈活性