⑴ 測試中遇到不可重現的Bug怎麼辦 詳細�0�3
！ 1． 記得有這么個缺陷，以後再遇到的時候可能就會了解發生的原因。 2． 盡力去查找出錯的原因，比如有什麼特別的操作，或者一些操作環境等。 3． 程序員對程序比測試人員熟悉的多，也許你提交了，即使無法重現，程序員也會了解問題所在。 4． 無法重現的問題再次出現後，可以直接叫程序員來看看問題。 5． 對於測試人員來說，沒有操作錯誤這條.既然遇到，就是問題。即使真的操作錯了，也要推到程序員那裡，既然測試人員犯錯誤，用戶也可能會犯同樣的錯誤。錯誤發生的時候， Tester 最大。 二、程序不是測試人員寫的，出問題也不是測試人員的原因。 至於無法重現，可能的原因很多，因為測試人員看到的只是程序的外部，無法深入程序內部，所以把責任推給測試人員是不對的。 測試人員的任務只是盡力重現問題，而不是必須重現！！ 三、下次再遇到的時候，拉他們來看就可以了。 因為問題如果無論如何無法重現，程序員確實也沒有什麼好的解決方法。 而且此類問題即使程序員說修改了，測試員也沒有好的方法去驗證是不是。 四、你可以告訴程序員，測試過程是沒有錯誤的。 測試人員只是檢查程序中可能存在的問題，雖然測試人員使用一定的手段方法努力去覆蓋所有的情況，但這些都是理論的推測。在實際中，可能因為人員、環境、配置等種種原因出現各種各樣的問題，在測試人員這里發現問題是公司內部的事情，程序發到外面可就是公司的形象問題了。 需要讓程序員理解，測試人員是幫助他們的，不是害他們的。 客戶那裡發現問題比測試員發現問題結果要嚴重的多。 五、測試部門是獨立於開發部門的呀，真的打交道，也是經理對經理。 在我們這里，工作上面的事情，和程序員相互只能商議解決，並沒有誰高誰低。 問題無法重現，也要提出，程序員那裡可以回復無法再現。問題放在那裡，等到再次出現的時候，就立刻叫程序員過來查看。 實在沒有再次出現，最後可以寫到報告中，說出現了什麼現象，但無法再現（比較嚴重的問題才如此處理，小問題經理之間商量商量可能就算了）。 至於測試人員必須重現bug，你殺了我好了，我每次測試項目都有無法重現的問題，很多我能找到大概的原因，有些根本無法重現（僅僅出現一次）。 這種事情是無法避免的，並不能說測試人員無法重現問題，就是工作不到位（哼，程序有 bug，是否可以說程序員工作不到位的呀）。 六、測試部門要獨立，最好不受開發的制約。其實真正要重視，就應該有否決的權利。 我們公司就是項目承包，要拿最後的項目尾款，就要測試部簽字通過，這樣就避免了很多的問題。 其實只要自己盡到心就可以了，管別人怎麼說呢。 七、我們使用的狀態有： 程序員處理的狀態（由測試員提交的Action）：等待處理的，再次出現的。 測試員處理的狀態（由程序員提交的 Action）：已經修改的，暫不修改的，系統限制的，使用錯誤的，無法再現的。測試員可以修改記錄。 經理處理的狀態（由測試員提交Action）：管理員處理的。經理還可以刪除記錄。 按照比較標準的說法，其實對於缺陷還應該有「等待確認的」、「已經確認的」和「重復提交的」的狀態，我們為了省事，統一使用了「等待處理的」。 最後結項的時候，缺陷的狀態對我們來說有兩種，「已經關閉的」（由測試員或經理確認）和「暫不修改的」（比如下一個版本處理等）。 呵呵，狀態多，有些煩瑣，特別是程序員很多的時候都不清楚應該回復什麼狀態，但我個人覺得對測試人員來說，這些狀態比較清晰明了，容易處理。 八、一個叫 doer_ljy(可戰)的網友回復了一些內容，我個人認為不很妥當，就回復了一些內容，綠顏色的是doer_ljy(可戰)的內容： 關於「無法重現」我看是有這么個問題存在。 首先如果你在測試之前有嚴格的測試計劃，就很難出現「無法重現」這種現象。「無法重現」的意思是不知道怎麼操作才能再次看見這個BUG。那麼這個BUG 多半是「計劃外」的。 不清楚你是否是測試人員。「計劃外」這個詞，對測試員來說應該不存在。測試用例的粒度一直是個在討論中的問題，測試人員很難有時間和精力寫出包含內容、數據、步驟等等全部操作一切的測試用例（說白了，只要一個長手識字的人，按照測試單做，就能發現所有的問題，呵呵，有軟體藍領的感覺了）。即使真的有，意義也不大，測試很多的時候，是發散性的思維，帶點創造性，想事先考慮完全，很難。所以更多時候，是在測試過程中逐步對用例等進行完善，所以說「計劃外」最好不要提。 說說我現在測試的一個項目，有一個業務，首先查詢出人員，有個「全選」按鈕，「全選」後，再用滑鼠一個一個取消選擇，這個時候進行業務辦理的時候，就會提示「沒有選擇人員」，至今為止一切都正常，但是這個時候再次點選人員進行業務處理，仍然會提示「沒有選擇人員」，這就是一個缺陷了。這個問題我想一般人都不會在測試用例中考慮到吧，因為發生的條件很苛刻：不用「全選」按鈕的時候不會發生；全選後點擊「取消全選」按鈕再辦理業務不會發生；全選全消後，先點擊人員再辦理業務也不會發生。 其次，成熟的測試人員即使無法再現 BUG，也能准確的描述出 BUG 發生之前幾個步驟的操作方法，測試用例情況。這些對開發人員分析BUG 原因很重要。所謂的BUG 發現環境。 呵呵，看來我不是成熟的測試人員。手工測試，比較熟練的時候，和打字可以說差不多，應該進行到哪裡，心中是有數的，但讓我完全從頭到尾的重復，不容易呀。寫測試缺陷報告單的時候，也只是說明操作步驟和發生的現象。其實無法重現的問題，既然說「無法重現」，也就是測試人員已經對這個現象進行了多次的驗證，一般從程序外部來說，測試人員的操作比程序員要熟練的。 最後，我不同意測試人員不假思索把發現的「問題」直接推給編碼人員的做法。畢竟是大家合作，目標是一致的。測試人員總是處在 BUG 發生的第一現場，應該幫助分析出現問題的原因。確認是不是自己的此時Miss. 測試人員提交任何一個問題，都會經過反復的驗證，如果容易重現，早就提出來了。絕對不是在推脫責任，還是那句話，對程序的結構，做的人當然比不做的人要清楚。另外，除非程序員詢問，否則我不會給程序員提出修改分析和建議！！測試人員的任務是發現問題，解決問題是程序員的事情。這么做可能會影響程序員思考問題的思路；而且測試人員做的多了，程序員不但不感激，可能反而會反感（好像程序員對測試人員有好印象的不多）。 再說兩個我這兩天遇到的問題。第一個就是我們的程序有一個鎖定數據的功能。鎖定後，在其它的業務，此數據將不能再使用。我當時發現這個功能無效，而且經過了幾次的驗證都不行，我當然就提出了。但是程序員那裡說此功能好使，我再驗證的時候，就沒有問題了，這個問題當時可以重現（但是我不可能遇到問題就拉程序員來看吧），後來卻沒有了，只能放在那裡，最後關閉掉。第二個就是在一個界面中，錄入有順序要求，必須先選擇一個ListBox （必填）再進行Edit 的錄入，但一次操作我沒有選擇 ListBox 就錄入的Edit，也正常保存了。後來無論我怎麼操作此問題都沒有出現（不夠成熟呀），我就放棄了，也沒有提交記錄（為了避免麻煩）。 測試人員的時間是有限的，進度給的都很少，一般連用例都沒有時間寫，還要去花很多時間驗證「無法重現」的問題？反正 10 分鍾如果試驗不出來，我就會放棄。嚴重的就提交，不影響的就當不知道。 下面是其它一些人的觀點： doublefalse(散諸懷抱)：如果不能重現的 bug 確實比較麻煩，但最好在測試過程中注意干凈環境、正確的操作、相同的數據源，只要真的有問題，一定能否復現的。呵呵，多試試！！！我們以前一直有客戶反映入庫的數據經常有無關數據，但在家裡測試沒有問題，後來才發現是漢字編碼錯位，這樣同樣的字，錯位後就變成另外的東西了。 liuxiaoyuzhou(蟀哥)：遇到過同樣的問題!主要是記住BUG 出現的環境!測試的時候這是關鍵! 在我們這里不能重現的BUG,是測試人員的工作不到位!我們這里程序員比測試人員說話有力度!郁悶呀! ericzhangali(另一個空間)：首先一定要提交bug；其次不要企圖RD 一定去解這個bug；某些時候還得關閉這個bug。如果RD 認為是測試錯誤，（不明白什麼叫測試錯誤，是不是說他從測時要告訴你千萬不要怎麼怎麼做，否則後果自負啊，）那也沒什麼辦法，如果溝通解決不了，愛咋認為就咋認為吧。 darkcat_c(錯了重來)：沒有 bug 是不可以重現的，bug 本事是建立在標準的規程上所出現的異常，如果你按test case 步驟做的話不太可能出現此類bug。作為測試人員一定要具備良好的記憶能力，一旦出現一些不知如何產生的bug，至少你要知道剛才你大致進行了那些操作。良好的分析能力，盡管你只是測試，但你應該全面的了解程序的架構，和一些重要的內部細節，不然你這個測試就是不合格的。定位bug 是開發的事情，而重現一個bug 是測試的本職工作，不要把所有的事情推給開發，不然你的確比開發要低一等。（編者按：這種話，不願意去辯駁，標准開發人員的看法，也許應該讓他們也來做做測試） liyan_1014(雁子)：我覺得應該是這么處理： 1、一定提交bug，必須由負責bug 的tester 詳細描述測試操作步驟，bug 發生的症狀，並將 bug 發生的具體環境也描述清楚；這樣對於再次重現也有一定的參考性。 2、測試和開發之間是需要良好溝通的，如果得到的回復是操作錯誤，那麼請開發人員解釋，為什麼會允許存在操作錯誤，一般來說，對於錯誤控制，開發那邊應該能很好的把握。
⑵ 程序員遇到解決不了的bug怎麼辦
但大部分程序員都有一個問題就是不太願意測試自己的代碼。他們草草的調式完成以後就認為工作結束，測試那是測試人員的工作。
1. 影響了程序員自己的聲譽
2. 影響了產品的質量
3. 影響了客戶的信任度
4. 這個時候再 DEBUG 難度增大了許多。
大的不說，就說多自己聲譽的影響吧。如果你的程序總會有這樣那樣的 BUG ，你得到收益會減少，即使你寫了很多代碼。
程序員必須克服一些自身的致命缺點才能夠從根本上解決這個問題。那麼這個問題是什麼?前面我們已經提到，程序員對自己的代碼都非常寬容，認為那是正確的沒有問題。實際上這種想法比較正常，程序是通過程序員思考和設計之後才寫出來，程序員不會將自己認為不正確的東西寫到代碼里，而到這個時候都一直假設程序是正確的;但人非聖賢，怎麼可能不犯錯誤來。實際上程序員在對待其他程序員時候的態度就很好，帶著一種挑剔和學習的態度;但一旦對待自己的代碼就很難這么做;這就是最致命的。程序員也必須對自己的代碼帶著挑剔和學習的態度;這個基礎是假設自己的代碼是錯誤的，然後需要做的是怎麼樣證明自己的代碼是正確的。程序員自身可以在程序生成的每個階段做這些工作：仔細的設計(這個時候畫點時間是值得的，必須保證我們對自己的程序有清晰的輪廓後才能開始動手寫)、編寫代碼時、單元測試(單元測試的重要性就不在贅婿了)、功能測試。
仔細的設計：這個的仔細是說在程序員編寫代碼之前，其必須對代碼的整個結構以及邏輯結構有明確的清晰的了解，只有這個時候才可以去寫代碼。這里沒有談到文檔，但我說到了一定要清晰的思路，但清晰的思路不是每個人都可以在腦袋中直接形成的，很多人都是普通人，沒有辦法在腦袋瓜中把所有問題都想清楚，那麼就記下來，特別對於復雜的邏輯。
編寫代碼：對於沒有把握的代碼，例如：新設計的演算法，最好保證其正確性。可以單獨將這部分測試，這可以讓代碼模塊化的同時又保證了代碼的正確性。一句話：少量的代碼保證質量還是比較簡單的。
單元測試：單元測試的重要性不在贅敘了，現在也有許多工具可以幫助程序員並減少工作量。
功能測試：程序員保證自己代碼質量的最後一關;為了做這樣的工作我們可能必須寫一些代碼來測試，甚至是測試工作。使用大量的 CASE 來測試，以及錯誤的 CASE 。這里和測試人員的測試不同之處在於：仍然讓程序員的注意力放在其自己的代碼范圍內，減小了排錯的難度。
如果你通過了以上的步驟都找不出你程序中有任何問題的話，那麼我想你的程序應該足夠健壯了。其實還有一點必須說明的就是：代碼 REVIEW 。
前面說道了程序員對待別人代碼的態度是挑剔和學習的態度，所以讓其他程序員來 REVIEW 你的代碼也是檢查程序有沒有邏輯錯誤的很好的辦法。團隊中應該交叉 REVIEW 代碼，這是實踐的經驗。
作為一個好的程序員必須有以上的習慣，以及對待自己代碼象孩子一樣，我們要愛惜我們的代碼，同時也要讓代碼走正確的路。
⑶ 我剛做程序員,覺得很多都不會,怎麼辦
別放棄，慢慢就好了都是這樣過來的，最好是找出一個到兩個比較典型的之後再仿著做下，要比只看，學的東西多，不懂就之後再研究，一點點就明白了。
⑷ 我是做程序員的。認真檢查了。還出錯了。自己有點接受不了
其實做事情就難免出錯，哪怕我們是個程序員，哪怕我們覺得自己很認真，不要因此就去否定自己。
⑸ 我是個程序員，在搞測試，發現以前同事編的程序很爛，自己又不好說，怎麼辦
呵呵摟主你應該知道：
科技在進步人們的思維方式也在進步
以前的程序員用他們高超的經驗實現這當時
不可能實現的功能，你應該佩服他們！
你是後輩，你所接觸的新鮮的事物，新的思維！
你可以拿著誠意開誠布公的與那些前輩討論問題！
記住一切都是從公司的角度出發即可！
⑹ 當作為一個初級程序員，自己的業務能力不夠的時候怎麼辦有些功能業務實現不了怎麼辦
你只能繼續深造加強學習，因為你剛參加工作經驗比較少，學的東西和實際結合不進去慢慢的來別著急，多和有經驗的交流，就會改變你現有的壯況。
⑺ 為什麼程序員總是不能准確估測項目時間
為什麼程序員總是不能准確估測項目時間？很多時候程序員估出來的時間都會被領導打折扣的，也可能是出於員工的惰性，但是很多時候需求提出方在項目沒有一個原型的時候他們自己都不知道想要一個什麼樣的，理想中與現實中往往存在著很大的差距。
首先：從程序員自身來說，項目在開發過程中有很多的坑是未知的，比如想要用新學的一個框架去搭建，或者一個前沿的技術去實現等等，甚至有時候一個bug很可能要調試好久好久好久。。（此處省略很多無奈）；
其次：工作本身來說，一個程序員手頭上不可能只有一個項目，不能避免開發這個項目的同時沒有別的需求進來（見識過一天n個緊急需求堆積的一天，悲催的無法形容）；
再次：估-揣測，大致的推算。從字面意思上來說本來就不會准備。之前做了一個有意思的面試題就是從數字1寫到100中間不能有塗改的地方，相信很多人看到這個題目肯定信心滿滿，可是在寫的過程中想快又想准備無誤的完成能有多少人呢？
最後：產品經理方面，我敢說絕對沒有一個項目是確立出來到完成之後所有需求是一樣的，所以需求的更改，需要討論、測試等等，甚至一些潛在的需求也是需要各種溝通~
以上這些都是不可避免也無法預知的情況，哎呀~還有一個就是測試、聯調的時間！這些加在一起很難准確估測時間了。
⑻ 剛踏入職場的程序員，如何快速踏實地提升自己的能力
程序員提升主要靠實踐，跟一個完整的項目能最大限度的提升項目能力，以後找工作不用愁啊，現實工作中很難達成，你可以去找找培養這方面人才的，提升一下自己，你看看願碼ChainDesk，有你需要的
⑼ 我先跟大家說說我的情況，我是個程序員，但是因為我的精力不足了，想要換個工作。下邊是我的具體情況。
給編程愛好者的忠告
近來有不少人問我是學Vb好還是學C好，還有人問Vc和C++Builder哪個更好，還有人說只要是面向對象的就是好的所以C++和Java最有前途。以我從事計算機教育多年的經驗我要告訴這些編程愛好者，如果只是一味追求學會一門所謂的最先進的編程語言（事實上不存在最優），而忽視了編程思想和基礎知識無疑是犯了學習編程的大忌。
就拿面向對象來說，人們一提到它就贊不絕口，然而又有多少人領會到什麼是面向對象的思想，我想如果沒有真正做過大項目的人是很難體會到其優越性的，這不是通過學習C++或Java就能掌握的。我的意思是編程注重的是想法而不是語言，這就是計算機專業要開設「演算法分析」和「數據結構」的原因，如果一頭鑽到某一門語言中無疑於作繭自縛，束縛了自己的思想，打一個不好的比方一個程序員的工作性質和民工沒什麼兩樣只是在壘磚頭，而真正的計算機人才應該是一個設計師、工程師。
現在國外的一些優秀的計算機著作的都是一些從事如生物、化學等領域的專家，我想這是因為他們以前沒學過計算機，沒有被某些傳統的觀點所束縛，從宏觀上來看待問題，反而在思想上有所突破，這是值得我們深思的。
真正的程序員（轉貼）
作一個真正合格的程序員，或者說就是可以真正合格完成一些代碼工作的程序員，應該具有的素質。
1：團隊精神和協作能力
把它作為基本素質，並不是不重要，恰恰相反，這是程序員應該具備的最基本的，也是最重要的安身立命之本。把高水平程序員說成獨行俠的都是在囈語，任何個人的力量都是有限的，即便如linus這樣的天才，也需要通過組成強大的團隊來創造奇跡，那些遍布全球的為linux寫核心的高手們，沒有協作精神是不可想像的。獨行俠可以作一些賺錢的小軟體發點小財，但是一旦進入一些大系統的研發團隊，進入商業化和產品化的開發任務，缺乏這種素質的人就完全不合格了。
2：文檔習慣
說高水平程序員從來不寫文檔的肯定是乳臭未乾的毛孩子，良好的文檔是正規研發流程中非常重要的環節，作為代碼程序員，30％的工作時間寫技術文檔是很正常的，而作為高級程序員和系統分析員，這個比例還要高很多。缺乏文檔，一個軟體系統就缺乏生命力，在未來的查錯，升級以及模塊的復用時就都會遇到極大的麻煩。
3：規范化，標准化的代碼編寫習慣
作為一些外國知名軟體公司的規矩，代碼的變數命名，代碼內注釋格式，甚至嵌套中行縮進的長度和函數間的空行數字都有明確規定，良好的編寫習慣，不但有助於代碼的移植和糾錯，也有助踴同技術人員之間的協作。有些codingfans叫囂高水平程序員寫的代碼旁人從來看不懂，這種叫囂只能證明他們自己壓根不配自稱程序員。代碼具有良好的可讀性，是程序員基本的素質需求。再看看整個linux的搭建，沒有規范化和標准化的代碼習慣，全球的研發協作是絕對不可想像的。
4：需求理解能力
程序員需要理解一個模塊的需求，很多小朋友寫程序往往只關注一個功能需求，他們把性能指標全部歸結到硬體，操作系統和開發環境上，而忽視了本身代碼的性能考慮，有人曾經放言說寫一個廣告交換程序很簡單，這種人從來不知道在百萬甚至千萬數量級的訪問情下的性能指標是如何實現的，對於這樣的程序員，你給他深藍那套系統，他也做不出太極鏈的並訪能力。性能需求指標中，穩定性，並訪支撐能力以及安全性都很重要，作為程序員需要評估該模塊在系統運營中所處的環境，將要受到的負荷壓力以及各種潛在的危險和惡意攻擊的可能性。就這一點，一個成熟的程序員至少需要2到3年的項目研發和跟蹤經驗才有可能有心得。
5：復用性，模塊化思維能力
經常可以聽到一些程序員有這樣的抱怨，寫了幾年程序，變成了熟練工，每天都是重復寫一些沒有任何新意的代碼，這其實是中國軟體人才最大浪費的地方，一些重復性工作變成了熟練程序員的主要工作，而這些，其實是完全可以避免的。復用性設計，模塊化思維就是要程序員在完成任何一個功能模塊或函數的時候，要多想一些，不要局限在完成當前任務的簡單思路上，想想看該模塊是否可以脫離這個系統存在，是否可以通過簡單的修改參數的方式在其他系統和應用環境下直接引用，這樣就能極大避免重復性的開發工作，如果一個軟體研發單位和工作組能夠在每一次研發過程中都考慮到這些問題，那麼程序員就不會在重復性的工作中耽誤太多時間，就會有更多時間和精力投入到創新的代碼工作中去。一些好的程序模塊代碼，即便是70年代寫成的，拿到現在放到一些系統裡面作為功能模塊都能適合的很好，而現在我看到的是，很多小公司軟體一升級或改進就動輒全部代碼重寫，大部分重復性工作無謂的浪費
了時間和精力。
6：測試習慣
作為一些商業化正規化的開發而言，專職的測試工程師是不可少的，但是並不是說有了專職的測試工程師程序員就可以不進行自測；軟體研發作為一項工程而言，一個很重要的特點就是問題發現的越早，解決的代價就越低，程序員在每段代碼，每個子模塊完成後進行認真的測試，就可以盡量將一些潛在的問題最早的發現和解決，這樣對整體系統建設的效率和可*性就有了最大的保證。測試工作實際上需要考慮兩方面，一方面是正常調用的測試，也就是看程序是否能在正常調用下完成基本功能，這是最基本的測試職責，可惜在很多公司這成了唯一的測試任務，實際上還差的遠那；第二方面就是異常調用的測試，比如高壓力負荷下的穩定性測試，用戶潛在的異常輸入情下的測試，整體系統局部故障情下該模塊受影響狀的測試，頻發的異常請求阻塞資源時的模塊穩定測試等等。當然並不是程序員要對自己的每段代碼都需要進行這種完整測試，但是程序員必須清醒認識自己的代碼任務在整體項目中的地位和各種性能需求，有針對性的進行相關測試並盡早發現和解決問題，當然這需要上面提到的需求理解能力。
7：學習和總結的能力
程序員是人才很容易被淘汰，很容易落伍的職業，因為一種技術可能僅僅在三兩年內具有領先性，程序員如果想安身立命，就必須不斷跟進新的技術，學習新的技能。善於學習，對於任何職業而言，都是前進所必需的動力，對於程序員，這種要求就更加高了。但是學習也要找對目標，一些小coding fans們，他們也津津樂道於他們的學習能力，一會學會了asp，一會兒學會了php，一會兒學會了jsp，他們把這個作為炫耀的資本，盲目的追逐一些膚淺的，表面的東西和名詞，做網路程序不懂通訊傳輸協議，做應用程序不懂中斷向量處理，這樣的技術人員，不管掌握了多少所謂的新語
言，永遠不會有質的提高。
善於總結，也是學習能力的一種體現，每次完成一個研發任務，完成一段代碼，都應當有目的的跟蹤該程序的應用狀和用戶反饋，隨時總結，找到自己的不足，這樣逐步提高，一個程序員才可能成長起來。一個不具備成長性的程序員，即便眼前看是個高手，建議也不要選用，因為他落伍的時候馬上就到了。具備以上全部素質的人，應當說是夠格的程序員了，請注意以上的各種素質都不是由IQ決定的，也不是大學某些課本里可以學習到的，需要的僅僅是程序員對自己工作的認識，是一種意識上的問題。
⑽ 如何提升程序員的代碼編寫能力
一、先列三個常見的開發場景：
1、拿到一個模塊詳細設計文檔，大部分程序員的通常做法就是開始搭建界面代碼，然後從第一個按鈕點擊事件或頁面Load事件開始寫第一行業務代碼。寫的差不多了，就運行一下，發現哪裡不是自己想的那樣，就改改，直到改到是自己預想的那樣。
2、做完了一個功能模塊或幾塊相關聯的功能模塊，輸入111asd，發現新建正常、保存正常，就提交給測試人員。測試員用測試用數據、測試場景用例來測試，發現有問題，就登記bug。對於嚴重的影響下一步測試的BUG，測試員就用內部IM通知這個開發人員。對於不影響繼續往下測試的BUG，測試員就登記下來，等程序員有空時處理。
3、程序員一般工作不希望大家打擾，所以開發起來就是開發。等手頭開發告一段落，就看看BUG庫。發現有與自己有關的BUG，就從第一個BUG開始看起。就開始通過IM和測試員掰扯起來（這不是個BUG啊、業務邏輯不是你想的那樣啊、我這里不能重現啊、你給的信息描述不清晰啊），於是IM幾來幾往，甚至跑過去當面交流一番，甚至會拉扯上產品經理一起討論，更甚者需要項目經理或產品經理發起一個會議來集體討論一下
這是不是很熟悉呢？這就是大部分程序員開發的三個步驟：寫代碼、自測、修復BUG。
二、說好的代碼設計、代碼測試呢？
代碼設計？那不是都有開發平台么，已經固化了啊。那不是維護舊功能做完善修改呢么，又不是寫新代碼，只能在現有代碼基礎上修改啊，你又不能大幅重構。
代碼測試？你丫需求討論期、產品設計期、設計評審期那麼長，都把研發項目時間佔光了，就留下2個星期讓我們寫代碼，我們哪裡有時間搞那麼深的測試。還想讓我們搞結對編程？還想讓我們搞測試驅動開發？
而且你看測試，什麼功能測試、集成測試、性能測試、安全測試、安裝部署測試、升級測試、遷移測試、UAT測試，一大堆測試，測試也需要很多時間。
一個項目，需求討論、產品范圍規劃與評審、產品設計與設計評審佔了一個半月，開發+自測就一個月，測試佔了一個半月，這就4個月了啊。
三、為啥程序員寫代碼總是寫寫測測？
剛才大家也都看到了，大部分程序員都是從界面代碼開始寫起，而且寫一寫，就運行一下看看。為什麼會是這種開發方式？
那是因為大部分程序員缺乏在腦子中的整體建模能力。只能做出來一點，真實的感覺一下，然後再往下。
有些是產品經理的上游就有問題，沒給出業務流程圖（因為產品經理也沒做過業務），也沒畫清楚產品功能操作流程圖。
為啥沒給出業務流程圖？因為產品經理不熟悉業務，另外，產品經理也沒有流程建模能力啊。為啥沒畫清楚產品功能操作流程圖啊？因為不會清晰表達流程啊。
很多產品經理、程序員，都缺乏分類、分層、相關、先後能力，更別說總結、洞察能力。
這是基本訓練，是一個做事頭腦清醒的人必備的技能，這不是一個程序員或產品經理或測試員的特定技能要求。
我經常看書就梳理書的脈絡，每看一本就寫一篇總結。我過去閑扯淡還梳理過水滸傳、紅樓夢的人物關系圖呢，其實就在事事上訓練自己的關聯性、層次性、洞察性。
我經常面試一個人時，我會問這樣的問題：「你把我剛才說的話復述一遍，另外你再回答一下我為什麼會這樣？」，其實，我就在看一個人的細心記憶、完整梳理、重現能力，我也在看一個人的梳理、總結、洞察能力。
我個人寫代碼就喜歡先理解業務流，然後理解數據表關系，然後理解產品功能操作流，大致對功能為何這樣設計、功能這樣操作會取什麼表、插入或更新哪些表，哪些表的狀態欄位是關鍵。
然後我寫代碼的時候，就根據我所理解的業務流、功能操作流、數據輸入輸出流，定義函數，定義函數的輸入與輸出。
然後，我會給函數的輸入值，賦上一些固定值，跑下來看看能否跑通這幾個關聯函數，看看還需要怎樣的新增函數，或者看看函數的輸入輸出參數是否滿足跑通。
剩下的事，就是我填肉寫詳細邏輯代碼了。
當然，大部分人沒我這樣的邏輯建模能力。怎麼閱讀理解也想像不出來，也沒法定義函數。畢竟有邏輯建模能力的程序員都很少，100個人里有10個，已經是求爺爺告奶奶好幸運了。
那怎麼辦呢？
我建議是分離分工配合，這就是現實中沒辦法的辦法。讓有邏輯建模能力的人來設計函數框架、來設計工具來設計代碼模板，然後讓沒有邏輯建模能力的人來填肉寫詳細邏輯代碼。
我們可以先從最緊要的模塊開始這么做。不緊要的模塊，還讓它放任自流，讓熟練手程序員繼續塗抹。
我曾經還讓有頭腦的程序員做榜樣，給大家分享他是怎麼規劃函數的，怎麼做維護性代碼的代碼結構改善的。但是發現效果並不佳，其他人並沒有因此能做代碼設計。可能邏輯建模能力是個人的基本素質，是從小到大訓練成型的，不是你一個大學已經幾年的人能夠短時間內可以訓練的。
所以啊，還是讓能走的人先走，讓從最緊要的模塊開始這么做。
不必擔心這樣做後，因為過去一件事被分工（一個做代碼框架一個填肉）成兩個人做了會降低工作效率。我們很多的工作效率低就是因為半瓶子醋搞出來的，來回反復修改。
真是應了劉德華在電影里說的那句話：說你又不聽，聽又聽不懂，聽懂了又不做，做又做不好，做不好還不服氣。
四、為什麼大部分程序員不做代碼測試或白盒測試或單元測試呢？
還是因為沒有代碼設計。因為沒有函數啊。所以，一個按鈕功能有多復雜，代碼就有多長。我見過2000行的函數，我也見過1000多行的存儲過程和視圖SQL。怎麼做白盒測試啊，這些代碼都粘在一起呢，要測，就得從頭到尾都得測。
所以啊，先學會設計函數，先寫好函數，這就求爺爺告奶奶了。很多開發了5年的熟練手程序員，可能都未必會寫函數。
函數的輸入輸出值就很有講究。很多人都寫死了，隨著版本迭代，發現過去定義的函數參數不夠用了，於是就新增了一個參數。然後，相關性異常就爆發了，其他關聯的地方忘改了，到底哪些有關聯，怎麼查啊，本系統沒有，沒准其他系統就調用你了，你根本不知道哪個神經人曾經COPY過你的代碼修吧修吧就改成了他的功能呢，而且裡面的很多代碼他看不懂也不敢刪，只要他實現的功能正常了他也不管了。於是，你改了你這個函數，他的系統就莫名出錯了。
所以，我一般會定義幾個對象來做參數。另外，我也很注重函數的日誌、函數的異常保護、異常拋出、異常返回。另外，我也很注重參數輸入值的合法性校驗。
所以啊，應該開發Leader們先制定函數編寫規范最佳實踐，輸入輸出參數怎麼定義比較好，函數的返回值如何定義比較好，函數的日誌記錄應該怎麼寫比較好，函數的異常保護、異常拋出、異常返回如何寫比較好。先教會一般程序員，先從會寫函數開始啊。
當然，你光有一份規范，程序員們還是不理解、不實際應用啊。所以，還得Leader們做好典型的代碼模板，裡面是符合函數規范的代碼框架，只有這樣，一般程序員們才會照貓畫虎適應了函數設計的編程習慣。
所以啊，我專門重新定義了leader的明確職責，其中第一個重要職責就是：負責工具/框架/模板/規范的制定，並且負責推廣且普及應用落地。
你不明確定義Leader的這個重要職責，你不對這個職責做明確的KPI考核，誰尿你啊。你以為好的工具/框架/模板/規范是靠人們的熱情、自發產生的么？我們還沒有那麼自覺高尚啊。
五、為什麼大部分程序員不寫注釋啊？
我經常說一句話，千萬別多寫注釋。為啥？
因為我們經常遇到的問題不是沒有注釋，而是更糟的是，注釋和事實代碼邏輯是不相符的。這就出現常見問題了：殘存下來的設計文檔是一個邏輯、注釋是一個邏輯說明、真實代碼邏輯又是一個，鍾表多了，你也不知道正確時間了。
所以啊，產品文檔、注釋、真實代碼，三者總是很難一致同步。我為了幾百人研發團隊能做到這個同步花了大量心血和辦法，但我最終也沒解決了這個問題，還把Leader們、總監們、我都搞的精疲力盡。
索性回歸到一切一切的本源，代碼，就是程序員的唯一產出，是最有效的產出。那麼，讓代碼寫的不用注釋也能看懂，咱得奔著這個目的走啊。
為啥看不懂，不就是義大利面條式代碼么，又長又互相交雜。
OK，我就規定了，每個函數不能超過50行。用這一個簡單規定和靜態代碼檢查插件，來逼迫大家嘗試著寫函數。有的函數屬於流程函數，是串起其他函數的，有的函數就是詳細實現函數，實現一個且唯一一個明確作用的。
有了流程函數和功能函數，而且每個函數不超過50行，這就比過去容易看懂了。
六、為什麼大部分程序員不抽象公共函數啊？
我經常說一句話：千萬別抽象公共函數啊。為啥？
因為大部分程序員缺乏抽象洞察能力。特別是有些積極熱情有餘、愛學習愛看書、半瓶子醋晃悠的二桿子，看了幾本UML、重構、設計模式、整潔代碼之道，就躍躍欲試了，還真敢給你抽象公共函數了。
一開始，他覺得80%相似，20%不相似，於是在公共函數裡面簡單寫幾個if..else做個區隔就可以。沒想到，越隨著版本迭代，這些功能漸漸越變越不一樣了，但是這個代碼已經幾經人手了，而且這是一個公共函數，誰也不知道牽扯多少，所以誰也不敢大改，發現問題了就加一個if..else判斷。
沒想到啊沒想到，這個本來當初公共的函數，現在變成了系統最大的毒瘤，最復雜的地方，誰也不敢動，除非實在萬不得已，手起刀落。
所以，我平時告誡程序員，純技術的、純通用的，你們可以嘗試搞搞抽象公共函數，對於業務的，你們還是簡單粗暴的根據Leader們做的代碼模板代碼框架，乖乖的復制、修改、填肉吧。
你們啊，先從做模板做代碼片段開始吧，咱們放到咱們內部代碼片段開源庫里，看誰的代碼片段被別人復制的多，說明你的代碼抽象設計能力越好了。那時候，我就大膽放心讓你撒丫子跑了。在沒有學會跑之前，給老子乖乖的復制、修改、填肉吧。