背景
最近搭建個專案，折騰了許久。最後，卻是在別人幫忙下，輕而易舉解決了。總結下來，筆者的思路還可以，只是在這樣那樣的原因下，差那麼一點點。
之所以這邊想記錄一下，主要感覺最近思維有點混亂。沒有庖丁解牛的本事，又不想按部就班循序漸近。少了點耐心，多了點蠻幹的味道。
開發者，其實就是解決問題。解決問題的過程中遇到了新的問題，首先要明確解決問題會有更大的成長；其實要了解解決問題的步驟。
比如：是做事順序不對？還是沒有按照要求？
了解錯誤原因在哪一步？
解決了什麼問題，會對當前現有問題有幫助？
大概解決這個問題會花多長時間？
是否要尋求幫助？在**可以尋求幫助？
而且，這些步驟，在解決問題的過程中，私以為可以記錄下來。這樣，方可知道在哪個環節出錯了。還可以從哪些方面去嘗試。
確實，開發者憑藉慣性，往往可以很快找到原因。就像你現在檢查小孩子的作業，不用思索什麼。但是，當你半個小時以內沒找到原因，就需要系統記錄下你找錯誤的路徑了。有記錄，才會反思，才會更好的走下去。
堅持是世上最沒用的詞語。聰明人，找方法。懶人，只會以身體上的勤奮欺騙自己。
舉個小例子，你解決問題花了半天，然後沒解決出來，只能說明：你浪費了人生中的半天時間。而不要自我安慰努力了半天。
問題是 誰養魚？
1 在一條街上，有5座房子，噴了5種顏色。2 每個房裡住著不同國籍的人 3 每個人喝不同的飲料，抽不同品牌的香菸，養不同的寵物 問題是 誰養魚？1 英國人住紅色房子 2 瑞典人養狗 3 丹麥人喝茶 4 綠色房子在白色房子左面 5 綠色房子主人喝咖啡 6 抽pall mall 香菸的人養鳥 7 黃色房...
分析問題是解決問題的前提
用簡便演算法求下列式子的結果 1 1 6 1 12 1 20 1 30 1 42 1 2 3 1 3 4 1 4 5 1 5 6 1 6 7 1 2 1 3 1 3 1 4 1 4 1 5 1 5 1 6 1 6 1 7 中間很多項都抵消 so 原式 1 2 1 7 5 14 這個問題的解決方案，建...
需求的問題，是乙個簡單的問題
需求決定了軟體做什麼，要提供什麼功能。軟體工程初期的一般過程是，軟體開發的計畫，確定要實現的目標和進度等，然後就是需求規格說明書，該說明書要得到使用者的認可。使用者往往提供了乙份要求的說明，開發人員在這個基礎上進行了加工和整理。此後的開發過程，都是圍繞著需求規格說明書進行進一步地細化，直至開發出產品...