上個星期真的很煩人，這也許是每一個程序員都要經歷的。我覺得不是因為我不夠好，實際情況和它的複雜性讓人很無助，比如服務器環境不同，增加了測試難度。不止一次罵愚蠢的客戶提出了不合理的要求，公司方面有老闆的衝動，感覺壓力山大，甚至有辭職的衝動。
但是你有沒有想過，一切都不能歸咎於別人，原因仍然是我們自己的。這是每個程序員都必須經歷的道路。如果沒有風雨吹打，怎麼會有豐碩的果實呢？如果你遇到同樣的麻煩，你需要及時調整你的心態。我也經歷過這些磨難，雖然很困難，但我還是一步一步地來，在這裡分享自己的一些經驗：
1 如果你想把它做好，你必須自己親手做。
這裡我引用一句話"當我還是個孩子的時候，我爸爸對我說，如果你想把工作做好，你必須自己去做！"我們做同樣的程序，遇到問題自己解決，在學校裡，當你可以問老師，問同學；去公司，也許一個好運氣會讓你身邊有一位大師。但最終還是要看你自己了。我在公司遇到了很多棘手的問題，有時我根本沒有任何想法，所以我想問老闆該怎麼辦？"老闆也是無奈的，時間過了一分鐘，但bug還在那裡，也許你會想，連老闆都做不到，我又能做什麼？別這麼想，更別這麼做！這個任務是你的，不管老闆能做什麼，它不會是老闆的問題，無論如何。我們要學會自己解決它。回想起來，有多少bug一開始嚇我一條，但最終我們解決了他，這是一個小小的成就。
2 換一種思維方式，也許一切都很簡單。
所有的程序員都可能有這種情況，遇到問題，總是堅持一種方法。其實，我們有時稍微改變點方式，你會為突然解決掉的問題感到高興。這個星期做了一個報告項目，一切都做好了。不幸的是，客戶建議將Description列更改為行顯示。將數據從數據庫中取出後，生成XML文件，然後使用XSLT格式化XML，生成報表樣式。"最初我認為這很簡單，我決定使用XSLT中的自定義函數來處理文本，來刪除html標記。"最初在演示中處理得很成功。然後，到項目中確編譯失敗了。我又測試了C、VB、XPath自定義函數和XPath函數。在嘗試了所有的方法之後，我投降了。我真的忍不住了。我不知道這個環節怎麼了。今天星期五，這個任務還沒完成，週末又沒了嗎？我怎能不著急呢？但真的到了無能為力的程度嗎？
為什麼要在XSLT中替換它？如果XSLT不支持它，我們可以讓他在進入XSLT之前去掉標記。我們可以在SQL查詢時替換html代碼，只需替換換行符，儘管我們不能在SQL中使用規則，但我們只需要替換主標記。
改變主意後，處理起來也太簡單了。雖然我花了整整一天時間安裝XSLT自定義函數，雖然這也是一項收穫，雖然讓我對XSLT瞭解得更多。但我們還是應該在面對bug的時候，不停地轉變思維。
3 沒有什麼問題是無法解決的。
方法總是比問題更重要！"沒有什麼是你不能想到的，沒有什麼是你不能做的！"在編程的路上也是如此，那裡沒有無法解決的錯誤。使用XSLT刪除html標記的問題也是如此，昨天我花了整整一天的時間研究XSLT函數，考慮使用哪種函數，用自定義函數實現，但在asp中不支持。我在尋找XPath函數。四點鐘後，對老闆說："我已經試過了所有的方法，我的技能都用完了！"老闆只是輕輕地回答說："繼續找吧！"。當時我還能說什麼呢？只能回答到："好吧！我再找找看！"(當時，心裡想把平生所學的所有咒罵給獻給老闆)。
"現在回想一下昨天的尷尬和歡笑吧！回首我們走過的路，多少次我覺得我們解決不了，堅持到最後，我們一定能找到了一條通往羅馬的路。如果我們沒找到，也只能證明我們沒有傾盡所有的努力。"同樣的事情，昨天的一個js簡單bug。因為那個js文件只能在文件提交時執行一次，並且不能設置斷點調試，只知道有錯誤，但不知道錯誤在哪裡？"同樣在週末的壓力下，我決定加班來修復錯誤，所以我使用了最原始的斷點模式，一步一步地查看所有步驟，最後非常高興地發現js中的一個function調用導致值被覆蓋。"我也鬆了一口氣。
4 客戶總是對的。
如果你一直抱怨"他是個白痴！"他又用不同的技能來禍害我！我做的事情是正確的！但其實我們的想法錯了，"客戶總是對的"，這很重要。我們只是從開發的角度出發，而用戶是用戶，如果我們開發客戶不能使用的東西，那又有什麼意義呢？無論客戶的要求多麼不合理，他都是對的。這是毫無疑問的。如果你認為他錯了，你能說服他嗎？如果你不能改變，你必須學會適應。
最後，請記住，我們的命運取決於我們自己。
閱讀更多 人人都可以是程序員 的文章
