程序員遇到問題時怎麼辦

今日要聞:

新浪創業上線

毫無疑問，2015是屬於創業者的時代，O2O將顛覆每個服務細分行業；

出行相關的應用層出不窮，大大下降了出行成本；

在線教育正在革新咱們獲取知識的方式；

全新的移動社交生態體系將咱們拉的更近。

每個顛覆的機會都是從創業者小小的夢想開始的，在夢的起點最須要支持和幫助。

咱們但願新浪的平臺可以全力幫助創業者和創新產品加速成長。同時，

也讓咱們的用戶儘快用上這些足以改變咱們生活的新創想，這就是新浪創業頻道的使命。

 

今日英文:

http://docs.oracle.com/cd/E11882_01/java.112/e16548/apxtips.htm#JJDBC28948

Oracle11g中JDBC的編程建議：

避免多個線程同時使用同一個鏈接

禁用自動提交

加大fetch size,默認爲10,但要在生成結果集以前設置

設置batch size,建議50到100,

    但只對預編譯語句有效,而且不能返回結果集

    對於存儲過程語句永遠都是1,除非用Oracle的非標準實現,但並不推薦

在物理鏈接上啓用statement caching,那將會使邏輯鏈接受益

number 類型能表明全部數字,但最好映射到最合適的java類型,從short,int,float一直到BigDecimal

char 類型最好映射爲String

 

技術區:

程序員遇到問題時怎麼辦:

根本的指導方針

1.首先寫代碼的時候最好不要有缺陷。最好的修復方法就是讓bug胎死腹中。

• 良好的單元測試
• 強制數據庫約束
• 使用輸入驗證框架
• 避免未實現的「else」條件
• 在應用到主程序以前知道如何在孤立的狀況下使用

日誌

2.print語句。每每額外輸出個一兩行將有助於隔離問題。

3.切換至詳細的日誌記錄。詳細的日誌記錄有助於發現更多的線索。

4.搜索日誌。若是日誌太多，可採起關鍵字或錯誤代碼來搜索日誌文件。

5.開啓自動換行和關閉自動換行。控制日誌的自動換行也很是有用。

6.搜索不一樣的日誌。主服務器的日誌可能並非惟一有用的日誌。

7.Windows事件日誌。日誌文件的另外一個來源多是操做系統自己。

8.製做有用的日誌記錄。有時，若是你沒有獲得任何有用的日誌記錄，那麼你可能須要本身寫。

與其餘人交流

9.詢問一些可能知道問題答案的人。

10.問」愚蠢「的問題。可能你以爲這些問題很愚蠢，但其實並非。

11.將問題解釋給隊友。他們可能知道答案或者能提出一些你並無想到過的事情。

12.將問題解釋給你的狗。述說的對象是誰其實沒有關係，可是能讓你從不一樣角度分析問題。

寫做

13.描述問題。用最準確和最精確的語句描述問題，有助於你去思考可能的解決方案。

14.問題日記。建立一個文本文件來記錄已經嘗試的各類方法，包括代碼片斷、配置設置以及產生的任何錯誤。

15.記錄問題和解決方案。有沒有這樣的狀況，忽然看到一個似曾相識的問題，只記得解決過但卻忘記了是如何解決的？能夠將問題和解決方案記錄到一個容易搜索的地方，如維基、缺陷跟蹤，甚至能夠發送電子郵件給本身。

支持

16.閱讀FAQ。

17.提交支持請求。若是有可用的產品/庫的支持，那麼就用。

18.在你點擊send以前，請三思。寫支持請求能讓你再一次思考問題，有時候就在你點擊send按鈕之時，忽然靈機一動就想到了解決問題的方法或者是新的線索。

19.其餘方面的支持。能夠與開發人員直接面對面交流，最好是實時聊天/ SKYPE/屏幕共享。

離開鍵盤

20.散散步。

21.打個盹。

22.重置優先級。暫時從鍵盤上離開還有一個好處就是可讓你從新評估這個問題的重要性，也許這個問題只是個CSS/佈局問題，根本不值得你花上16個小時。總之要有效分配和使用時間。

23.暫時將這個問題放在一邊。實在解決不了的話，能夠將這個問題先擱置起來。也許幾天後你在閱讀相關問題的時候，忽然一個激靈，解決問題的關鍵就來了。

隔離

24.肯定是哪行代碼。首先要肯定是哪行代碼致使的問題，以便於插入print語句。

25.將問題分割爲一個單獨的程序。有時候對於庫和產品的問題，咱們能夠將它的相關代碼從主程序中分離開來。這可能須要一點時間，但每每處理一個孤立的程序比應對整個的項目構建過程要容易得多。而後在解決這個單獨程序的基礎上再去和主程序做比較。

更改代碼

即便你一點都不知道如何解決問題，更改代碼也是一個挺有效的解決方法。

26.寫新的單元測試。

27.重構。有問題的代碼每每顯得有點亂，經過一些簡單的重構方法，例如重命名變量或展開嵌套的if / then/ else模塊等均可以讓代碼整潔起來。

28.發現bug。另外一個整潔代碼的手段是查閱相關代碼的「Find Bugs」 報告，咱們之因此首先要整潔代碼是由於：做爲一個能讓咱們的大腦專一於代碼的方法，既簡單又划算。

29.重寫。轉存全部的相關代碼，從頭開始重寫。一個全新的視角也許能讓你徹底規避這個問題。

30.爲一些沒必要要的代碼添加註釋——或者至少是你覺得是沒必要要的。而後你會發現可能這些代碼流並不像你曾經覺得的那樣「沒有必要」。

31.實驗。若是你不能肯定底層產品或庫是如何工做的，那麼一些小實驗，特別是圍繞邊界條件的實驗會很是有用。

32.回到乾淨的狀態。若是你在代碼中作了各類變更，或者是搞了不少配置設置，那麼按期回到一個乾淨的狀態就很是重要。不然，實驗結果可能會影響正確答案，這樣你就永遠也找不到正確的解決方案了。

33.切換技術。

產品

34.升級到更高的版本。也許你正在處理的問題已經被修復了，能夠試試先升級到另外一個版本。

35.降級到之前的版本。也許問題正是因爲與你目前正在使用的其餘產品/庫不兼容而引發的。

36.打補丁。

37.下載並安裝源代碼。

文件

38.閱讀手冊。大多數開發人員可能會認爲這是一個低機率的策略，可是，嘿嘿，你永遠不知道，也許答案就在文檔中。

39.閱讀手冊的正確版本。

40.手冊是否正確？有時候代碼已被更新，但手冊尚未。

調試器

41.瞭解鍵盤上的快捷鍵。

42.倒退。這是調試器的一個功能，讓你的代碼退後一步。

43.編寫斷點代碼。

44.異常中斷。調試器的一個蠻有用的功能就是能夠捕捉到任何地方的特定異常。

45.專業化的調試工具。例如：

• Plumbr
• AppDynamics
• Chronon
• Wireshark
• HTTP profilers：Fiddler二、Charles、Live Http Headers

源代碼控制

46.對bug缺陷進行編號標記。你有沒有碰到過這樣的問題：先是用這種方式被修復了，而後幾周後又成爲了bug被其餘人用另外一種方法修復了。這樣問題貌似就有兩個正確答案。解決辦法就是對源代碼中相關的bug缺陷進行標記，並記錄一些關於爲什麼改變以及誰參與決策等更爲詳細的說明。

47.Blame功能。這個可愛的小工具能告訴你是誰最後更改的代碼。

48.Git bisect功能。Git有一個有意思的「bisect」命令，能自動經過你提交的歷史進行二進制搜索發現故障。

尋找答案

49.谷歌搜索。

50.論壇帖子。

52.在stack exchange上溝通交流。

53.在stack exchange上提交問題。

其餘

54.聘請專家。可能在短期內成本很高。

55.招實習生。聘請專家的相反方法就是聘請新手。有時候初學者飽滿的熱情能讓他們從不一樣的角度來解決問題。

56.改變要求。若是你不能修復缺陷，那麼能夠改變要求。經過解釋各類成本須要，也許能讓客戶改變他們的初衷。

57.更改上/下游系統。

58.按部就班地學習技術。

59.經過斷點檢查配置。更改關鍵配置值，並確保已經斷點，這樣可以讓咱們無所顧忌地設置配置。

60.系統化。有時候咱們須要將三四件事情組合在一塊兒，那麼能夠將已經試過的組合記錄下來，若是須要的話必定要嘗試各類的組合。

 

非技術:

小米科技（全稱：北京小米科技有限責任公司，簡稱：小米）是中國一家移動通訊終端設備研製與軟件開發的企業，由雷軍組建，於2010年4月6日正式成立。 2011年8月16日，小米科技在北京發佈了小米手機。

小米的LOGO是一個「MI」形，是Mobile Internet的縮寫，表明小米是一家移動互聯網公司。 另外，小米的LOGO倒過來是一個心字，少一個點，意味着小米要「讓用戶省一點心」。

小米公司由著名天使投資人雷軍帶領建立。小米公司共計七名創始人，分別爲創始人、董事長兼CEO雷軍，聯合創始人兼總裁林斌，聯合創始人及副總裁黎萬強、周光平、黃江吉、劉德、洪鋒。

小米科技 CEO 雷軍有一句名言，「站在風口上，連豬都會飛。」

雷軍變成本身口中的「飛天豬」。高調、大動做不輸狂妄的阿里巴巴創辦人馬雲。

2014 年底倒數時刻 12 月 29 日，44 歲的雷軍在微博上宣佈完成新一輪 11 億美圓的融資。小米估值高達 450 億美圓，這個數字超越紅透半邊天的 Uber，超過京東 330 億美圓的市值。小米趕在 2014 年結束前，成了中國媒體眼中，BAT（百度、阿里、騰訊）以後，中國第四大網絡公司，並且是同時握有軟件和硬件的第四大網絡公司。

即使雷軍口說有信心，但他日前接受媒體訪談仍透露，「若是咱們不能用大數據技術轉化出價值，那咱們公司再撐下去就真的破產了……如今我扛得住，明年我也扛得住，後年我也扛得住，大後年要沒價值，那我就破產了。」

站上山頂的雷軍，走錯一步，均可能是萬丈深淵。