❶ 為什麼有的程序員的代碼結構混亂
程序員都有一顆工程師的心，所以當他們到一片新的場地想做的第一件事就是，將舊的一切推倒重來。是的，他們決不會滿足於簡單的增量勞動。
或許這種微妙的心理定位可以解釋：為什麼程序員進入新項目組後寧願丟掉舊代碼重新寫，也不願意修修補補。他們認為舊代碼簡直一團糟。
但是，事實上真是這樣嗎？你之所以認為舊代碼一團糟，其實是由編程的一個基本定律決定的，那就是：寫代碼容易，讀代碼難。
為什麼你覺得舊代碼異常混亂？因為讀代碼更難。
這大概就是代碼Reuse難以實現的原因。 這就是你組里的每個人都喜歡用不同的功能將分割的字元串轉換成一個數組。比起猜測舊的功能是怎樣實現的，重新寫一個自己的功能要簡單和有趣多了。
作為這個公理的推論，你可以問問身邊的程序員他們正在奮戰的代碼怎麼樣？「簡直是一塌糊塗！」他們肯定會這樣說。「我簡直想推倒重來！」
為什麼認為代碼這么糟糕呢？「額，看看這個功能，竟然有兩頁長！完全不知道這些東西為什麼在這里！完全不知道這些API是干什麼的。」他們會這樣回答你。
漫畫：讀別人代碼是一種怎樣的體驗？
曾經，Borland的創始人 Philippe Kahn當初就是向記者們吹噓：Quattro Pro會比Microsoft Excel要好用得多，因為它是從頭開始編寫的，全部都是新的源代碼！
但是，認為新代碼比舊代碼好簡直就是荒謬。舊代碼是已經運行過的，測試過的。無數的bug在被發現前都上線運行過，發現之後程序員們可能在花了好些日子才修復了這些bug。這種修復可能是一行代碼，也可能是幾個字元，無數的時間和精力都花在了這些bug修復上。
當你決定拋棄這些舊代碼從零開始的時候，你也丟掉全部前任努力的結果。
新代碼一定比舊代買好？NO，重寫可能會帶來更大的風險。
對技術領導者來說，重寫項目的代碼也是一個異常艱難的決定。因為從公司層面說，重現代碼甚至會威脅產品的市場競爭力。一旦決定重寫代碼，那麼與競品相比，你可能落後了2~3年——在軟體行業，這時間可夠長的。
你理想中的新代碼會帶來產品功能的提升▼
但事實上，即便重寫的新代碼可以實現舊代碼的所有功能和需求，但是為產品帶來的市場競爭力只有邊際提升。因為重寫用的新技術、新語言、新框架並沒有給產品帶來質的飛躍。
更不用說在重寫的漫長過程中可能會遇到一些意外情況，比如：
1、缺錢：資金鏈的斷裂▼
2、缺人：核心程序員離職
最終導致效果不佳：達不到原產品應有的所有功能和需求，白白浪費了時間和金錢，也丟掉了市場競爭力。▼
所以重寫代碼意味著，你在把自己置身於非常危險的境地，可能幾年後你也寫不出比以前更好的代碼。你只是花了一大筆錢把已經存在的代碼又寫了一遍。
當你覺得眼前的舊代碼很爛時，該怎麼辦？
你覺得舊代碼寫的很爛，那又怎樣呢？它們已經上線，已經在實際運行中經受住了考驗。所以當你發現前任留下的代碼亂七八糟的時候，不妨冷靜下來，從以下三個方面入手理解代碼、改善代碼：
1、代碼的結構有問題
如果一段網路代碼突然彈出了自己的對話框，應該是UI代碼需要被處理。這些問題可以被解決掉，你要一次次小心地移動代碼，重構，改變介面。還需要一位細心的工程師立馬仔細地檢查這些改變是否有問題，從而不打擾到其他人。事實上，甚至比較大的結構變化也可以不扔掉代碼來完成。
大牛程序員Joel Spolsky回憶說，曾經在某個項目中，他和他的團隊花了好幾個月重新架構在一點上：把代碼動來動去、清理、創建有意義的基類，並創建了模塊之間的完美介面。但是他們始終非常小心翼翼，並沒有產生新的bug、也沒有丟掉任何舊代碼。
2、代碼的效率不高
曾經，Netscape的渲染代碼被傳非常緩慢。但事實上，這只會影響該項目的一小部分，這部分是你可以優化甚至重寫的。你完全不必重寫全部代碼。優化速度的1％工作量，會讓你獲得99％的爆炸性提高。
3、代碼寫得很醜
有些代碼真的寫的很醜，比如Joel曾參與一個項目，開始用下劃線做開始的成員變數約定，但後來改用更標準的「M_」。所以一半的功能用「_」開始，一半用「M」開始，這看起來真的很醜陋。但這個問題5分鍾就能解決，而不用從頭開始寫全部的代碼。
最後，你要記住，從頭開始再寫一遍並不意味著你會寫出比以前更好的代碼。因為你沒有參與到上一個版本的創建，所以你其實根本就不算有經驗。一旦你准備推倒重寫，你可能會再犯一遍版本一犯過的錯，甚至會產生更多的新問題。
一個總結：
面對糟糕的舊代碼，Keep Calm & Carry On !
在大型商業項目中，推倒重來是非常危險的行為。當然，如果你是在做實驗，想到新演算法可以隨時重寫。
❷ 軟體測試的方法有哪些
軟體測試分為功能測試、介面測試、自動化測試、性能測試幾大方向，每個方向用到的測試工具都不盡相同。功能測試會用到SVN、禪道、QC\ALM、Jira等軟體測試管理工具。介面測試則會用到Jmeter、Postman、Fiddler軟體，使用Jmeter可以執行測試用例，對頁面跳轉，參數傳遞等功能進驗證。
自動化測試則又分為Web自動化測試和移動自動化測試。Web自動化測試主要會用到Selenium軟體以及Firebug插件工具，使用Selenium可以對網站的核心功能進行自動化測試，包括元素定位、滑鼠鍵盤的模擬操作及自動化測試框架的使用等。Web自動化測試主要用到的是Appium以及Monkey軟體。Appium可以對APP核心功能進行測試驗證，包括ID、xpath、list元素定位，數據交互、模塊封裝以及自動化測試框架的使用，生成測試報告，對APP功能進行評估等。
性能測試則會用到Loadrunner軟體，它包含VuGen、Controller、Analysis 這些組件。VuGen用於協議、參數化、集合點、事務、檢查點、思考時間、關聯、文件下載、瀏覽器模擬設置。Controller用於手動場景設計、場景運行、IP Wizard應用、負載生成器、服務水平協議(SLA)、場景監控、伺服器硬體監測。Analysis則用於HTTP報文結構、吞吐量相關、事務相關、網頁細分圖、執行結果分析、圖表分析。
❸ 程序員遇到很難的技術問題是怎樣的感覺
昨天剛領一個線上P0級重大事故，持續時間1小時，影響范圍全站 ！准確的時間點是下午17點開始，具體問題定位且聽我下文細細道來。
先說感覺，那感覺真是太刺激了，本來下午五點，昏昏沉沉的，瞬間一個激靈就清醒了（想像一下高中課堂，你在打瞌睡，突然老師走到你面前給你一下子的感覺），原本准備再過一小時吃晚飯了，吃完晚飯再摸魚到21點就可以下班了呀，別問我為啥到21點，問你就不是程序員！
帶著無比緊張且顫抖的心情開始定位問題，先來個錯誤日誌嘗嘗鮮：
1、下午五點開始有少量的慢sql報警，沒有人當回事，因為這種事情總發生，雖然大家都知道在實際開發中如何避免慢sql，但是整個團隊要想完全避免慢sql卻很難；
2、五點十分左右，開始零星有用戶反饋指定功能不可用，SLB開始報警，技術開始介入排查；
3、十五分左右，客服部門電話開始爆炸，用戶密集反饋指定功能不可用，技術部開始重視；
4、二十分左右，所有服務大面積出現介面無法響應，整體服務不可用；
5、我們一開始定位覺得是MySQL的問題，因為前面有mycat的慢SQL報警，後來定位並不是MySQL，因為MySQL的內存、連接數、流量這些指標都很平穩；
6、最終在五點三十分的時候我們定位到是ES出問題了，因為所有的Java服務不可用最終都指向上面的錯誤日誌，bbo提供的服務線程池滿了，再有請求進來直接拒絕了，查看這個服務的代碼，最終查詢的是ES，此時的ES進程已經處於假死狀態。
那接下來大家說怎麼辦？如何快速的恢復線上服務？
重啟！
是的，只有重啟大法此時是最快的解決辦法，你不可能說保留ES事故現場，讓我用arthas之類的工具來現場分析jvm內存情況。
然而重啟之後服務依舊是不可用，介面還是無法響應， 大家知道這個時候是什麼原因嗎？為什麼重啟了ES服務還是不行？
後續繼續重啟報錯bbo日誌的相應服務，當這些服務全部重啟完畢後，我們的服務終於恢復訪問了，這個過程持續了十幾分鍾，確切的說，直到17點五十多分，我們的所有服務才恢復了訪問。
接下來就是事故總結、相關責任人、產生問題的原因、接下來的優化方案，全公司郵件通報！
你說這個難不難？本身並不難，難的是事情緊急且重要，這個時候你慌了啊，亂手亂腳的，大家你一言我一語的，如何冷靜提取有效信息然後盡可能快的解決生產的重大故障才是最難的！
最後，當一切都恢復平靜的時候，你會發現：「卧槽，好累啊！」。
虛脫的感覺！
最後祝大家程序員節日快樂，今年可是程序員的本命年哦
2020 = 1024 + 996 = 404 + 404 + 404 + 404
這種感覺能難受，很壓抑。
技術難題，對於程序員來說，是經常有的事，關鍵是如何面對吧。
說下我的事情，雖然也會寫點代碼，但並不是以此為正業，所以對於真正的程序員來說，可能說法會有點偏頗。
遇到難題時，一般都在網上搜索解決方法，一般來說，都有很優秀的程序員分享他的勞動成果，所以一般都能解決問題。但也真正碰到難的問題，一個就是循環的問題，無限極菜單問題，當時都是找了很久，看了很多遍才明白過來，當時自己是幾天都不太開心，也不太想說話，總是在測試著程序。挺煩也挺不開心的。只是最後做出來了，心情就好多了。
這是我的一些經歷，當然，如果全職程序員，可能壓力就更大了。
如何形容這種感覺呢？焦躁，緊張，失落，無助，亞歷山大...
再多詞可能都描述不清楚。本人在工作中經常遇到難題，有些問題一兩個月都搞不定。遇到這種問題，估計只有下面這張圖的表情能描述此時此刻的心態了。
程序員遇到的難題其實分為兩種，一種是沒有辦法定位清除的問題，另外一種是定位清除了，但是沒辦法，或者很難解決的問題。
難定位的問題所謂難定位的問題，其實就是你根本不知道這個問題是什麼。比如系統突然掛掉了，你從現有的信息根本不能確定問題在哪。這個時候你剩下的可能只有滿腦子的問號了。
如果系統只掛了一次，後面不再出問題，那就很難找出問題的根源了。不過這樣也有好處，那就是問題的影響的程度相對較輕，畢竟不容易出現。所以在軟體開發中通常不是什麼問題都解決的，因為不是所有問題都能搞清楚是什麼問題，談何解決呢！
難解決的問題難解決的問題是問題搞清楚了，但是基於現有架構很難，或者沒法搞定。遇到這種情況，通常先是很高興，興奮，然後就只剩下無奈了。
當然，從技術層面來說並不是完全解決不掉。只是如果要解決需要涉及架構調整或者其它方面的改動，修改調整的內容太多。這種情況下就要考慮利弊得失了。
如果改動太大，可能會引入很多新的問題，可能得不償失。因此，遇到此類問題可能會採取一些規避方案。
當然，在開發和運營當中遇到各種問題是很正常的，關鍵是遇到不同的問題採用不同的策略。首先保證的是業務的正常運行，然後是考慮是否需要徹底解決。這樣慢慢調整，心理壓力會小一些。
作為一個工作多年的老碼農，在工作也遇到過一些艱難的技術問題，就以切身體會談談對這個問題的看法。
首先需要明確一下，問題是否困難除了取決於問題本身之外，還在於解決問題的人的水平，也許對你很難的問題，在別人看來不過是小菜一碟。明白了這一點，那麼這些技術問題也就成了考察程序員水平的試金石，有些人可能會因此氣餒，甚至放棄；而有些人則通過解決問題學到了很多新的技術，也讓自己進一步成長。
記得多年前看工作中要用到一款開源庫，那時候剛學完C++不久，自以為對面向對象了解甚深，然而學習這個庫時卻是一頭霧水，最後在經過泡論壇，然後又認真的學習了面向對象設計模式，後來不但能使用那個庫，更重要的是對面向對象編程有了更深的認識！
後來還有很多類似的事情，剛開始時感覺無比困難，但是通過自己的努力，或求助他人、或查閱資料，當最終問題解決時，你會發現自己又牛逼了一些，然後再遇到一些新的問題，如此循環……
其實編程也是一個學習的過程，就如同爬山一樣，每一階段都會有一些山頭，只有當你爬上山頭才能欣賞美麗的風景，但是當你爬上一座山頭的時候，就會發現更高山峰！只有當你爬上最高峰，才能「一覽眾山小」，可是到那時，你可能會嚮往地球之外的天地！
很難解決一般就是遇到某些瓶頸了，不同瓶頸的感覺是不一樣的，但無非可以歸結為下面幾類。
成本原因
不讓馬兒吃草，還想讓馬跑。這個是有些不太理解互聯網的一些領導的錯誤觀念，他們會給你安排一個老舊台式機，想要讓你承載幾萬、幾十萬並發的秒殺系統，你當然很難解決。
外界的評論可能是，「這幫程序員是吃干飯的么？這系統也太垃圾了！」
老闆的評論是，「我這台式機也不少錢呢。」
程序員的評論是，「這摳門老闆不會是個傻子吧。哎，再優化優化吧。」
當然，有些情況也是能夠理解的，公司明白需要更好的設備，但是由於成本控制，不得不在某些方面節省。但換句話說，設備成本是占不了一個大頭的，可能有其他方面的成本更加需要收緊。
如果是因為成本原因，我們的心情可能是無奈，又有些不能施展拳腳的束縛感。
歷史 原因
舉個例子，系統用了5年了，迭代了N個版本，在面對新的需求的時候，就會出現需求限制於系統的情況，常常會有程序員說，這個實現不了，那個不符合現在系統規則。其中很大一部分是這些年的積累，欠下的技術債造成的。俗話說，大船難調頭。
這種情況更多的出現在剛創業之後的幾年，由於一開始的快速迭代，追求先把業務流程跑通，先生存再規范，會讓一開始的軟體開發流程並不那麼規范，如果在1-2年內沒有進行重構，那麼積攢的3-5年的技術債就會慢慢把你壓得喘不過氣來。
解決這種情況，一是需要時機，給出足夠的空間和時間讓技術團隊重構，二是需要魄力，你得有成功的把握，不能幹著干著說不行了，咱們還是回到原來吧。
如果是因為 歷史 原因，我們的心情可能是期待和渴望，又有些對現狀的無奈。
能力原因
雖然說專家很厲害，但說白了，大部分企業需要的研發人員，還到不了需要專家的級別。所以，一般而言，沒有什麼技術是攻克不了的。如果真的遇上了，那就說明你的公司已經到達了一個新的層次，從而需要那個層次的人員來解決，可以通過外聘或者顧問的方式，引進新的技術。
如果是因為能力原因，我們的心情雖然有些力不從心，但又為公司在新的台階而高興。
不管怎樣，程序員是一群追求美好的人，不管是外部限制還是內部限制，不能解決的難題對於技術人員來說總是很憋屈的。
不能著急，慢慢分析，找到問題點，沒有解決不了的問題
程序員的技術問題，排除架構師技術選型錯誤以外，都是程序員的功夫不到家所致。
1,面向網路的程序員會第一時間問度娘，各大社區求助大神。
2,面向源碼的程序員會第一時間查看源碼實現，查找api文檔，思考解決方案。
3,不管技術如何發展，架構如何延伸，不變的是基本功，再先進的組件都是由基礎語法書寫出來的 。
練武不練功，到老一場空，共勉！
首先說下這個很難的技術定義，個人認為在你知道之外的知識都是很難的，一旦你深入了解其使用方式，原理，甚至閱讀了他的源碼，你會覺得有的時候會恍然大悟。程序員是一個不斷要學習的崗位，就要面臨很多從未知到已知技術的時候，每當遇到這樣的情況時候，總有種不解決了這個問題，睡不著覺的感覺，心裡不踏實，總是想盡各種辦法去解決這個問題。甚至可以一直追查這個問題。也許這就是一種執拗吧
我老公最近就遇到一個大石頭需要敲碎，我作為一個旁觀者，都挺心疼他。
他還在讀博，最近遇到的問題是他一個項目上的問題，也跟他的畢業設計相關。他剛讀博的時候確定了一個方向，去年開題的時候他覺得這個方向沒有什麼前景，真的是考慮了好久要不要換，如果不換，就是安穩的畢業，換的話接下來的一年多時間他會很艱難，很多新的問題需要一一克服，最後他決定換了，他說他讀博就是為了提高自己，還是想挑戰一下。
年前，系統板設計好了，然後最近做好回來了，開始調試，說這個板子跟個石頭一樣，不工作。本來就是禮拜一到禮拜六待在學校不回來，周日是休息的。現在放假回來都是在啃變壓器的東西，早上起的很早，晚上又很晚。真的挺心疼的，他還安慰我說，他又要進步了。挺擔心他的身體的，我特別希望時間能快點過去，能順利畢業。他卻不希望，總覺得時間過的太快，沒有時間搞研究。
今年的生日願望，希望他科研順利，身體 健康 。
以我的從業經歷，說說遇到很難的技術問題是什麼感覺吧： 興奮、充滿挑戰性 。尤其是在開發中遇到了技術難題，很多情況下真有種可遇不可求的感覺。
我認為能遇到技術難題，至少證明這個工作是有價值的。 這種價值體現了兩個方面，一是你的工作在整個產品開發中占據重要地位，甚至是核心地位。二是你的認知和經驗，仍然有成長的空間。如果你的工作一直沒有遇到難題，輕而易舉地就解決了一切，那麼很可能是你沒有機會深入重要的核心部分，或者你的工作性質可替代性很高，簡單重復性很高。
分解法。 把技術難題拆分，盡量的單元化、模塊化，這樣有利於逐步攻破，逐步解決。主要是降低技術難度，尋找真正的難點所在。如果問題無法拆分，就是那麼一個點，那麼需要逆向思維，可以先把問題擴大，看看涉及面有哪些，然後再縮小范圍，鎖定關鍵之處。
刨根法。 把技術難題抽象化，理論化，從根本的源頭去解決。很多技術問題，從基礎理論的角度去看，其實真的不難，只要你能定位到相關的技術點，困難點，知識點，就很容易進行快速解決。解決的終極辦法就是從理論上徹底解決，做到知行統一。
討論法。 三人行，必有我師。很多情況下，所謂的技術難題，在別人的眼中，也許並不是難題。很多情況下，小組討論，交換意見，方案互補，就可以解決難題。有些情況下，還需要和供應商一起討論，主要是補充信息的錯漏。經常出現的晶元問題，很多情況下供應商都更加有經驗。因為供應商有更多的使用客戶，有很多解決問題的經驗。最主要的是，晶元是他們設計的，他們更加清楚緣由。
沒有絕對的技術難題，有的只是尚未解決的技術難題。