作為測試，被開發同事挑釁看不懂代碼，是怎樣一種體驗？
八月底，產品發布了一個新的版本。今天（九月上旬末），老闆發現有個莫名的commit，後來查清楚是一個開發同事發現是他自己在八月份發行的版本里寫錯了一個判斷條件，導致產品在升級過程中出現異常，他偷摸兒的修改代碼後，偷摸兒的提交到已經發布了的版本的branch上。對於完全不知情的其他人，我只是其中一個。現如今我們老闆決定打一個hotfix來解決這個問題，所以故事就開始了。
作為測試，我需要重現這個bug來驗證這個bug是不是真的fix了。然而從頭到尾默默發生的一切都只有這位開發知道，於是我像往常跟其他開發交流一樣，跟他溝通，討論怎麼重現。討論過程中他跟我解釋返回某個object為null，修改後某個field為null。我問為什麼要做這樣的修改，使用場景是什麼。他就開始發毛，然後說了一句絕對「驚點」的話，你又不懂代碼，跟你沒法說清楚，你大學寫過java，c++代碼嗎？我瞬間覺得整個人蒙蔽了，一個開發對測試說這樣的話，是想打一架嘛？我抑制住憤怒，冷靜跟他說，我大學寫過代碼。但是現在在團隊里工作，即使我看不懂代碼，你做開發的也要用通俗的語言表達清楚你的代碼邏輯。於是，他不說話了。事後，我想問問測試同僚們，遇到這樣的情況，是怎樣一種體驗？你們是怎麼解決的？對於這樣的開發，要如何再跟他相處工作？
開始我和你一樣，甚至被開發鄙視，後來每天晚上回去學java ，學了半年，後來，能和開發對業務代碼談笑風生，一年半後，來了一批新開發，我可以告訴他們新需求用那個方式實現最快，如何設計更好的業務邏輯，從那個地方找工具類，資料庫取那個表那個值等等
總之
你不提高自己，換一家公司還會遇到這樣的問題，想要徹底解決，就要提高自己，學會了，別人看你的眼光都不一樣，會不會代碼對測試人員來說完全是兩種結果，別想著改變別人，多提高自己瀉藥。
最近實在太忙了，隔了好幾天才來回答這個問題。這個問題在日常生活中再普遍不過了。我先來說個真實的故事吧。
故事一：曾經有一個團隊的測試很想了解產品的代碼設計和結構，經過討論之後他們給開發提出了需求，讓開發抽1個小時來給測試團隊講解下，也可以讓測試團隊更好的進行測試用例的設計。結果開發從頭到尾就一句話「我覺得這個沒有意義，反正說了你們也不懂」
故事二：同樣這個團隊，測試要求在每次開發commit的時候能夠寫清楚commit info，同時能夠發郵件告訴測試改了什麼。其實在gitlab中是可以設置的。結果開發就說「我可以配置，但我覺得沒有意義，反正配置了你們也看不懂」
是不是都很熟悉？其實就是題主說的這個問題。這個問題要解釋起來必須從正反兩個角度來說。縣來關注題主說的問題吧
事後，我想問問測試同僚們，遇到這樣的情況，是怎樣一種體驗？你們是怎麼解決的？
Monkey：首先我要稱讚下題主的做事方式，的確不管測試懂不懂，開發應該有自己的職業操守，作為一個團隊，目的就是做好產品，而不是去鄙視來鄙視去。所以題主給開發的回答我還是很贊同的。
是個什麼樣的體驗，可以見我那兩個故事。從心底進行鄙視。
對於這樣的開發，要如何再跟他相處工作？
Monkey：事情總有兩面性
從正面角度出發，測試的確應該好好的告訴開發我們是一個團隊，大家要合作，所以還是請好好的和測試進行合作，好好用通俗的語言進行交流。
但從反面角度出發，大家有沒有想過開發為什麼會有這樣的態度？我看到其他評論里也有說「開發就是這樣的」，那麼問題就在於開發肯定不是天生就是如此的吧。原因無非就是幾個：- 他道聽途說覺得測試都是渣渣
- 他曾經合作過的測試都是渣渣
- 他在日常交流的時候碰見的測試都是渣渣
- 題主就是個技術渣渣
所以綜上所述，造成這個的根本原因就是大部分測試就是不懂技術，技術渣渣，導致開發不想進行溝通。原因也很簡單，這是一個很現實的社會，如果你是開發，你肯定願意和自己同等level或者是大牛進行溝通，既順暢也能夠讓自己成長。在開發看來，和一個技術渣渣去溝通，哪怕用通俗的語言溝通也是效率低下的一件事情，我為什麼要做呢？
最後我再說個真實的故事吧
某一天我團隊的測試和開發吵起來了，開發一怒之下就說「有本事我們換，明天你來開發，我來測試」，結果測試團隊全部沉默。
所以，不要老想別人怎麼樣做的不對，別人哪裡做的不好。首先第一優先順序的就是提升自己，將自己武裝起來，強大起來，否則你永遠是開發眼中的異類。如果等到那時還有開發是這樣的態度，那麼他就是所有技術人員眼中的異類了。
再次感謝有這樣一個問題出來，希望題主不要玻璃心，客觀的對待事實，加油要不斷的提升自己。當年我剛畢業的時候誤打誤撞選了測試，代碼就放棄了，做黑盒測試。
過了一段時間發現一隻在重複一些事情，為什麼不去自動化呢，就開始看一個代碼相關的東西，python，ruby啊，慢慢的自己去寫一些代碼，代替一些手工的工作，慢慢的開始接觸開發的代碼，試著去分析代碼，不懂的地方就向開發請教，慢慢的越來越熟悉了，現在還能幫著開發改簡單bug。
後來代碼接觸多了，開始搞服務端測試。公司用的都是centos，就開始學習shell，寫一堆的shell腳本用來輔助搭建環境，這樣就慢慢的熟悉了shell，但是很多東西仍然記不住，到用的時候就直接搜索一下，看兩眼就可以開始寫腳本了。前一段公司讓抓一批數據，開發都太忙，就找到了我這個測試，現在正在happy的給公司抓數據呢。技多不壓身才是正道，安身立命之本。活到老，學到老。謝邀
－－－－－－－－－知恥而後勇被挑戰不怕，怕的是自己真不會還不去學習。自我自己的職業生涯中，我被挑釁過無數次，我自己真懂的我自然會平和的講道理，不懂得，我會記下來，然後業餘時間學明白。被挑戰挺好的，能促使自己學習更多的知識。
希望題主能樂觀積極的看待這個問題，人生漫長，快樂的面對問題並提升自己，雖然看似雞湯，但也是挺好的，不是么？碰到這種Java開發我會立刻擼一段無比動態的Python代碼讓他去讀讀看是不是很爽
很逗。
心態放平和些吧，擺正每個角色的位置。做測試的，永遠的出發點不是為了證明開發人員的代碼有bug的，做開發的，永遠也不要以為測試就是給你找bug的，好在我認識的開發工程師，都是在業餘時間的玩笑里拿看不懂代碼的事摧殘我，我也會把累計的bug數和修復bug未成功回滾代碼的歷史翻出來揶揄他們。
真有這種人說這種話，該幹嘛幹嘛，自己在上進自己在做自己應該做的事情就好了。歸根結底是你自己腰桿不硬啊，我一直強調在IT行業，技術為贏。前段時間強哥剛整理髮表了一篇 軟體開發和軟體測試，我該如何選擇 在此就搬用過來回答你這個問題，雖然題目看起來不著邊際，指東打西，但是我要表達的東西很對題，不信請繼續往下看。我一直認為，在開發領域，強哥的測試技術非常紮實，在測試領域，強哥的開發能力實在牛逼。如果我天天糾結到底是開發好還是測試好，還活不活了？
我們先來談談技術追求這個事情，就像強哥學堂的LOGO一樣，「工匠精神」這個詞，自從被羅胖（強哥為數不多的幾個比較認可的偶像，當然，強哥現在也使用鎚子手機，很不錯，軟體應用細節處理得很好）提出來以後，現在全民都在提，這不是什麼壞事。至少，讓浮躁的人們知道了，「工匠」其實是最受人尊敬的，也是最有尊嚴的一個群體，就像現在丈母娘都越來越喜歡IT宅男一樣的道理（錢多，事兒少，脾氣好，俗稱「經濟適用男」）。所以，如果你還在糾結做開發還是做測試，證明你其實是沒有技術追求的，這一點你不一定會承認，但是身體是誠實的。
為什麼這麼說，其實道理很簡單，我們來設想這樣一個場景：如果你是一個爺們兒，突然在你的生命中出現了一個美麗的姑娘，你會怎麼辦？你會糾結嗎？你糾結什麼？假設正常情況下，你不糾結，為什麼呢？因為你內心很篤定，就是她了，你一定不會跑來問強哥的。我們選擇職業，道理也是差不多的，人為什麼會糾結，只是因為不夠堅定而已。就像到底學Java好還是學Python好這樣的問題，每天充斥著QQ群或者交流論壇中。現實的情況是，測試也好，開發也罷，如果你不去執著於對技術的追求，你相信我，你一樣都干不好，建議你也別干這行了。就像很多人之所有選擇測試，是因為害怕編程，基本上來說，不懂編程，要想在測試技術領域有所作為，很難，30歲以後轉行的不少，中年危機更甚。
人性就是這樣，這山望著那山高，老婆總是別人的好，那個優秀的孩子總是別人家的，或者經常聽到一些自我催眠的話，哥的人生哥作主，等等言論。我們不談對錯，只談現象。強哥接觸的人，特別是學生，各種風格，各種性格，形形色色，當然也有各種奇葩，基本上，我在很多人身上，都能夠感受到一點：很多人總是把希望寄托在一些不切實際的未來，而不是把握當時當下確定的現在。得不到的永遠是最好的。這些都是人之常情。
強哥也是熱愛技術，大學一直自學編程，但是，當第一家公司安排我去做測試工作時，我想都沒有想，我要做程序員，還是接受公司的安排，做軟體測試。因為原因很簡單，我只想搞技術，我必須要進入IT這個行業，特別是當年我還是一個小菜鳥的時候，尤其又是一個統計學的學生。至於IT這個行業未來會怎樣，管它呢，我又掌控不了，我唯一能確定的是，我喜歡這個行業。再退一步，無論我做什麼工作，誰都阻擋不了老子寫代碼的熱情。所以，強哥現在仍然保持足夠的代碼量，所以我能寫書，出視頻，寫教材，所以我能在公司裡面保持技術的領先地位，即使現在我是一個CEO，很多朋友都勸我作為一個CEO，要做好三件事情：「找人，搞錢，定戰略」，去他媽的三件事，老子就想做好一件事：「用技術去征服世界」。讓技術，成為蝸牛學院的定海神針，建立培訓機構的技術壁壘。為什麼強哥要去找人，要去搞錢？為什麼我們不能強大到讓人來找我？讓錢主動送上門，這才是格調！
回到本話題的出發點，作為測試，被開發同事挑釁看不懂代碼，是怎樣一種體驗？
發到這來你只會被同行們再嘲笑一次。開頭我說了，真正的要點在於你本身就腰桿不夠硬（技術菜），可憐你，安慰你的話我就不說了。強哥給你的建議就是兩句話。第一句：「做任何你周邊的朋友不敢做的事」。第二句：「做你認為你自己最想做的那件事」，強哥怎麼建議你，不重要，朋友怎麼建議你，不重要，老師怎麼建議你，不重要。當然，如果你仍然無法抉擇，那麼你就跟隨強哥吧，把測試和開發，前端和後端，管理和技術，通吃。走向人生巔峰，指日可待。
這個世界上，為什麼成功的人總是少數？
可能只有1%，強哥來告訴你，因為那99%的人都選擇走大路，走一條容易走的路，只有1%的極少數人，走的人別人從未走過的路，是一條難走的路，他們不成功，天理難容。
註：本文為資深IT屌絲，蝸牛學院CEO鄧強老師原創，首發自http://www.bossqiang.com/article/3，轉載請獲得授權並註明出處。希望繼續在IT行業突破提升自己的各位朋友，歡迎加群384053806，不管你自我感覺牛不牛B。
作為一個專職的測試人員，我大學雖然學過代碼，但是真的忘得差不多了到目前為止還沒有遇到過被挑釁的情況，但是也曾經想像過遇到這樣的情況如何面對個人認為就是，認清自己的職責，我做測試基於的是需求和產品說明加上客戶的要求功能為前提邏輯如何代碼是否我看的懂，是其次。主要是達到預期的結果。否則就算你的邏輯再好，代碼再深奧。客戶不滿意，照樣不結尾款。那樣損失的是所有人。其次，我會利用閑暇的時間自學點代碼和編程知識，為的是能編寫簡單的腳本以便性能測試和使用測試工具。總之，認清自己的職責豐富自己的技能。做好自己是最主要的
好好溝通，沒必要去跟他吵。如果還是不行那你可以找測試經理或負責人
單純論應對的話，有很多種辦法
第一種，像你這樣，表示對方沒團隊精神，不肯好好溝通。顯然，除了關係搞僵，並無實質好處
第二種，如果是妹子，撒嬌賣萌對方就老實告訴你了。或且平時就打好關係，也不會有挑釁的行為。這是比較高段位的應對，防患於未然第三種，自己有能力看代碼，自然也不會受挑釁第二跟第三都是平時功夫，而且在我看來對自己地比較好的應對。
視乎什麼情景了。
無論什麼崗位，基本素養到位，情商正常，不會隨便受人挑釁。除非踫到個別不開眼的。
總之厲害得人哪都受尊重。兄弟，憋著這口氣，變強了，就沒這麼多破事了。曾經測試一個java做得產品輔助工具。發現了多處問題，問題單提過去，開發直接拒回來，還回了個郵件，表示問題隻影響易用性，作為測試自己不了解編碼實現的難度就不要老是給開發找這種修改起來麻煩，而且使用時只要嚴格按格式輸入也不會出問題的單。收到郵件1個小時內，我默默的把這幾個問題的代碼拉下來，然後修改、驗證好，一封郵件甩回去：這就是你說的修改麻煩？？從此我的單基本不會再直接拒回來了
這種事我以前做測試的時候經常遇到。開發人員，尤其是情商不太高開發人員，特別喜歡鄙視還沒有建立起信任關係的新人測試（理所應當，畢竟「測試」+「新人」，前者是給他找事的，後者是沒事找事的）。當然，這其中也有部分問題是某些測試自己不求上進，什麼技術問題都不懂，讓開發覺得是他在幫你做本該你自己完成的工作內容，增加他的負擔，他當然會不耐煩。
最根本的解決辦法，就跟這個問題下面大部分答案一樣，就是你要提高自己能力，讓開發信任你。明白你並不是什麼都不懂，明白他並不是在雞同鴨講，明白不光是他幫你做事，你也在幫他做事。有了這樣的信任關係以後才不會再次出現這樣的對立事件。這樣的提高並不僅限於代碼能力，而可能是原始需求，需求分析，設計，構造，編譯，測試，集成，交付中的任何一環。總之要有一技之長，在某些時候能幫到開發，這樣需要的時候開發才會幫你。
其次除了長期思路之外，針對這個事情本身，問題核心在於他改了一句代碼，老闆讓你測試，而你並不知道測試場景是什麼，代碼可能影響的範圍有多大，需要測試的輸入值有什麼變化。也就是測試需求不完善，你需要首先完善這個需求，然後再測試。
然後問題就簡單了，你覺得需求應該開發去完善，因為是他提的代碼（確實也該他去完善），然而開發出於某種原因（覺得你浪費他時間+看不起你），並不想去「幫你」梳理這段代碼涉及到的業務場景。所以我建議你首先讓他搞清楚，這是他自己的事，自己拉的屎自己擦屁股，而不是他在「幫你」做事。如果他不認同這個結論那麼找領導解決。
其次稍微規範點的團隊都會要求開發提交之前要自測，（如果你們有這樣規矩的話）請他拿出來自測用例或者自測方法供你參考。
最後，別聽那些裝人生贏家的傢伙告訴你什麼自己懂代碼不求人，什麼自己改好甩他臉上打臉。這樣聽起來確實很爽，但是僅僅適用於小項目。如果你在一個複雜的體系里，沒有人全知全能，不是具體負責的人最多了解一下整體的架構，上層的體系，但是絕不會知道下層的細節。這就意味著就算你的代碼能力和普通開發一樣出色，你也要花很多不必要的時間去從頭開始熟悉一個你本來沒必要弄清楚的模塊。所以回到上面第一條，如果領導說這個測試場景你就自己去梳理清楚，那麼：
1. 說明情況自己對這塊代碼不熟悉，第一次做不敢保證沒有錯漏。所以最後拿出來的測試場景需要責任開發評審通過。如果有遺漏或者錯誤，拿他也別想置身事外。
2. 預估一下時間，想的全面一點，所有相關聯的業務模塊，函數，邏輯都要考慮到。並且這個時間肯定比那個開發哥們自己梳理要長很多（這很合理，以前我也遇到過這情況，核心開發人員忙著趕需求實在沒時間，一個他自己梳理最多1個小時能幹完的活我用了一周去從頭開始學）。如果經理覺得合理，那你就花一周時間去做好了，就當學點東西。
3. 如果對自己能力沒自信，可以對經理要求那個開發來協助，帶著你看一遍粗略的數據流，或者必須回答你的問題。這很合情合理。
4. 如果你既沒能力，又懶得下功夫，那麼直接撂挑子說自己不會，做不了，經理也拿你沒辦法。不過以後你可能就會混的比較困難就是了。
以上，長期思路和短期應對方法都有了，希望對你有所幫助。
--------來自一個8年測試，1年開發，5年測試管理經驗的不知道是開發還是測試的軟體狗。
PS：也有什麼代碼都不會的測試，照樣的混得好的。這種人情商超高，不管做什麼事都混得好，他們不是核心，但是是團隊的潤滑劑。他們不做IT去做公務員會更加風生水起。他們和每個領導玩笑打屁，他們和每個開發稱兄道弟，團建活動最活躍的永遠是他們，吃飯加班永遠有他們在講段子，你和客戶吵架的時候永遠都是他出來打圓場。但看你的帖子就知道你不是這號人，不然你下個矮樁給他幾記馬屁叫幾聲爺，估計也不會來知乎發帖尋求安慰了。
被鄙視的體驗，那就說說體驗吧，不是我自己，從外人的角度看的一個小姑娘，13年畢業，誤入測試行業，真的毛都不懂，幸運的是我的導師是他的老闆，導師和老闆不同，導師是公司安排幫助新人的，老闆是決定錢的，這老闆有耐心，會看人。姑娘，背景比較好，哈工大碩士，雖然經常被我們取笑為野雞大學。第一年不寫代碼沒啥事，因為可以使勁的做業務，老闆卻每天坐她身邊，讓她搭建qunit（公司封裝的junit）測試，簡直就是趕豬上樹，不懂單元測試本質是什麼，代碼裡面概念也一知半解，我看得直著急，真的覺得老闆太高估小姑娘的能力了，被我鄙視，被開發鄙視更狠，這樣寫沒問題的，巴拉巴拉。第二年，老闆升級了，把小姑娘給我帶著，說這孩子特聰明，一定能成為強有力的後盾，我內心那個著急啊，因為有業務壓力就任由她搞，沒啥高要求，能控制住風險就好了。過了半年我手頭沒人，頭上要背效率提升的kpi，自己干力量有限，溝通了三五次，說你必須要做完這個自動檢查功能，就是簡單的shell，照貓畫虎，按照我寫的繼續，只要會用判斷和循環可以，大約半個月過去了，艹，竟然真的做出來了，環境自動檢查和恢復，細看代碼笑得腸子都抽，但是真的做出來了，奔著目標去就能做好，後來再聊她說怕丟人，但是對目標挺認可的，也就做出來了。靠著她強大的執行力，第二年後期自己負責一個小業務，自己也開始背著效率的kpl對代碼認知有了改變，已經能用java寫工具了。第三年，她的團隊更大了，背的任務更重，自己設計工具，遇到慫人就裝模作樣的講道理，鄙視那些滿足於當前的同學，說他們半年不寫三行代碼，遇到太2的開發就直接拉出來當反面教材，業務比開發懂，代碼裡面有出現低端問題，開發也只能忍著。現在我一旦遇到難題就交給她，哈哈哈，牛逼的隊友真的是左臂右膀一樣強大有力。這是一個被鄙視和鄙視的過程，後來聊天問到是什麼的動力讓你這麼努力，答案竟然是，她知道同期入職會寫代碼的qa工資比自己高，太沒懸念了。
首先來說，你應對很好。第二，作為測試也是分級別的，黑盒總體來說級別比較低，而灰盒和白盒是級別高，沒有鄙視的意思，只說實際情況。第三，即使是測試也要會代碼，這個是基礎，不要只看眼前。第四，如果不喜歡編碼，可以掌握流程，也就是成為行業專家，不好的是，如果換單位，行業積累則無用。第五，學一點質量，軟工，項目管理，便於你應對這些。第六，代碼編程能力只是開發的一種能力，雖然重要，但你其他能力強，照樣可以碾壓之
我幾乎可以肯定提問者一定不在外企(迷之微笑)
好了不開玩笑了:
開發的世界就是弱肉強食，誰技術牛逼誰有理.測試對bug的態度千萬要按優先順序，重要程度，重現概率排序.記住你的目標不是發現儘可能多的bug，而是作為團隊一員儘可能使產品高質量按時不砍需求的發布(我相信你知道我在說什麼).關於開發鄙視測試的技術:
記得有次我報了個重要bug難重現，開發直接close as invalid issue還當著大夥噴我，我下去一行一行看他寫的那個報表.終於在一段存儲過程被我找出來當數據量大時一個被當成被除數的欄位value會超出被定義類型的最大值。我直接把要改的行數，語句寫到jira的comments里@他，從此以後只要我報bug他一定先到我座位上找我後才會加評論.再加一點:
從題主描述問題之清晰可以看出來，題主應該算一個對技術自信的測試了(至少在自己組織)，被開發鄙視，主要還是不爽及不認為自己比那位開發弱(這位開發估計不資深)，對於由於革命分工不同導致的鄙視，深深不服.題主能有這個覺悟，肯定也能化不爽為力量，日後噴回去.送給測試同行自勉:張華考上了北京大學；李萍進了中等技術學校；我在百貨公司當售貨員：我們都有光明的前途.工作嘛，只是生活的一部分，而且，難免受委屈。 測試和開發的關係本就很微妙，說的通俗點，測試就是找茬的，不被待見也是正常的，但工作還得開展，通常我遇到這樣的情況，會先自嘲一番，姿態放低，額，這個我不太明白，能幫忙再說一遍嗎？要是還不懂，就說，你們開發的就是腦子轉的快呀！就是我還有點跟不上（賣個萌），能幫忙詳細的說下嗎？基本問題也就解決了。當然本應該你知道的你要知道，這樣問的時候自己也要有這個底氣。 總之，用心去做，時間久了，讓產品經理產生依賴，讓他有這個版本某某測過才放心的心理。放低姿態等等只是溝通的手段，事情一絲不苟完成。到這個時候，自然而然就有自信，你的內心也會強大，誰誰說了什麼做了什麼，心裡完全沒波瀾。只有你自己先肯定了自己，才會無懼任何。
在程序員的圈子裡，你的能力決定了他們看你的眼神。如果他們發現你什麼技術都不懂，不吭你就算謝天謝地了。如果他們發現你懂他們，特別是在技術上能和他們交流，那絕對會和你深交。如果他們發現你比他們在技術上還行，他們絕對對你服服帖帖，甚至是崇拜。
不單是程序員，幾乎所有純技術類工作者都有這樣的特質。優點就是實在，你行我就俯首傾聽你的教誨。你不行，技術的事情就請你閉嘴。缺點就是容易得罪人。對圈子外的人在技術方面包容比較小。
造成程序員這個特性的的根源就是因為程序員被無知的圈外人黑的太多太過了。我現在已經不再走程序員這條道了，但是我是程序員出身的。我深有體會。
說一下我遇到的一個女程序員。我讀書的時候曾在一家中國大公司的德國子公司實習，工作是開發和維護VBA工具外加需求分析。那時小工具都是我自己開發維護，稍微大一點需求，我就寫需求分析報告發給國內總部的開發人員來開發。漸漸的我就認識了一個負責介面我們德國需求的一個女程序員。因為我也會開發，所以基本和她還聊得來。後來我實習快結束了，有一個我維護的工具因為非常重要，需要有人負責長期更總維護，因此她還被零時派到德國來和我交接這個工具的事項。那時我和她關係還不錯。
1，2年後我畢業，正式進入這家公司開始上班。工作重點不再是開發，而是工具需求分析和業務部門的IT支持。當然我又要和她合作了。當我上班後就接到一個爛尾的工具開發的小項目，需要和她聯繫，把工具順利開發完。我給她發郵件約電話會議，還特意提了一下我是當年和你交接工作的那個實習生。還本以為我們聯繫上後會先敘敘舊。沒想到電話一接通就感受到強大的氣場和怨念。各種「你倒地懂不懂XXXXX」，「你知不知道這樣該需求的後果BALABLA」。她知道是我，可是我在她眼裡和其他那些混子需求分析人員一樣。
最後工具順利交付，她對我的態度也像之前一樣了，我們倆又像以前一樣合作愉快了。之後和她多次的合作，她對我也逐漸信任，甚至有時還會向我請教一些職業規劃方面的問題。我記得有一次，一個工具需要處理幾百萬條的數據，逐條記錄的處理速度根本無法接受，最後我給他出了一個演算法，把複雜度從原先的指數級增長降到了線性增長。當我說完演算法後，她淡淡的來了一句「我塞，牛啊」。然後又問我：「這個。。。我沒別的意思啊，呵呵，我就想問問這個演算法你試驗過嗎？」我說這個是我大學論文里的演算法。然後她就特別高心，說程序交給她吧，2天後給我消息。
最後我離職前和她交接工作，她私下裡都說，如果我走了，她都不想接德國的需求了。因為又要像以前一樣，接那些描述不明，邏輯混亂，還經常改的開發需求了。
-------------------------------------------------------------------------------------
現在想想妹子的工作也真是的，這些年我從實習生到正式員工到最後離職去其他公司，工作內容從打雜到需求分析到帶小團隊，可她從頭到底還是個程序員。連Leader都不是。可就是這樣一個程序員，對於不懂他們技術的人還是不會有任何包容之心的。因為他們被傷被誤解的太深了。
所以我覺得和程序員交流的一個最基本的法則就是：如果你沒有比他們更牛的能力和經驗就請不要質疑他們的能力和經驗。
如果你不是和他們一個技術群體的，那麼就客客氣氣的請教他們，他們都是好為人師的。畢竟程序員都很簡單，都是一眼就能看穿他內心的。看完這個故事，我覺得題目可以修改一下【如何看待在產品發布後偷偷提交代碼的程序員】這種員工太危險了。做這個行業，出問題不要緊，誰還沒見過bug啊？但是出問題了不及時報告，負分！故事剩下的部分，已經不重要了。
不請自答。
剛畢業出來工作沒多久的時候遇到過類似情況，不過當時研發同學態度比這個好多了，只是他確實不懂怎麼把問題講清楚，然後在我要求他講的過程中他自己發現代碼邏輯有其他問題。所以一般一個研發不能給別人講清楚自己的代碼邏輯的時候，那說明他自己對需求的理解還不夠清楚，或者自己寫的代碼很亂，理不清楚。當然，想做好測試，還是要懂代碼的。平時測試的時候可以自己看看，剛開始看不懂不要緊，可以查資料，問開發同學。這樣不僅僅能夠改善跟開發的交流，也能減輕自己的工作量。新入職開發來回答一波，昨天自己的代碼剛出現了個線上bug，第二天剛上班就找QA和leader確定了影響範圍並且確定重新發布時間。雖然自己很難受，但是還是覺得應該這麼做
推薦閱讀：