作為乙個半路出家的程式設計師，沒有經過專業的課程，寫程式當然顯得業餘。「只有專業才有機會」，這句話不論是對企業還是個人都是正確的。想當初，憑藉一股程式設計的熱情投身於現在的公司，由於公司規模小，沒有專業的培訓，只能靠自己一點點的積累，當然身邊還有一位大牛可以討教討教，也算是幸運了。記得剛開始程式設計的時候，以為**才是最重要的，總是無比羨慕崇拜那些乙個幾萬行的程式的作者，夢想自己也能有如此成就。後來因為工作的需要也滿足了我大量寫**的心願，然而在乙個個程式寫出來以後，自己逐漸就陷入了乙個難以自拔的沼澤地，越陷越深。縱使我熬通宵，週末加班也不能讓我心理踏實下來，因為自己的程式到了崩潰的邊緣。
在茫然中，我開始反思現在這糟糕的一切。以前習慣性的把導致這一切的緣由歸於不斷變化的使用者需求，而現在看來其實不然。對於軟體來說，滿足不斷修改和增加的使用者需求本來就是其最重要的工作，如果使用者需求不變，那麼也就不會討論什麼**擴充套件性了。程式的維護成本就大大降低，因為維護程式設計了簡單的查詢已有bug。編寫程式在也不用遵守什麼耦合度低原則，kiss原則。。。，一切就變得非常簡單。工作變得簡單對於工作人員來說意味著門檻變低，門檻低意味著什麼，你懂得。
那個自己挖的沼澤地是這樣一步步形成的：程式需求不清楚--》程式沒有或者幾乎沒有設計文件--》著手編碼--》編碼過程中不遵守基本的原則（比如低耦合度，kiss，dry等）--》修改過程中為了方便，怎麼省事怎麼來--》沼澤地越挖越大，越挖越深
設計文件很重要，這是目前為止我血和淚的總結。當乙個人建房子連設計圖都不用畫，要麼是蓋豬圈，要麼是茅廁。程式也是這樣，如果寫個小的功能程式，設計重要性就會降低，只要程式上了一定規模，沒有前期良好的設計工作，那麼等著走進自己挖的沼澤地吧。設計文件中主要包括需求分析，程式設計流程。需求分析是設計流程的前提，對於乙個都不清楚程式到底要做成什麼樣子的程式設計師來說，寫到最後可能就是乙個杯具，被全盤推翻掉，費時費力。當前自己編寫和維護的乙個程式就是由於當初沒有重視需求分析，都是口口相傳，種下苦果啊。對於明確的需求我們當然要實現，對於潛在的需求這時候我們在設計流程的時候，就需要考慮擴充套件性了。這就好比菜鳥和大師下象棋，大師走一步看百步，菜鳥走一步看一步。當我們對於產品足夠熟悉後，就要盡最大的可能考慮潛在需求，所以這也要求我們對於產品在市場的應用場景有足夠的了解，對於行業也要多多關注（這點我是自己做的不夠好，以後要多關注監控行業）。
當我們對於需求有了透徹分析後，流程圖就是設計階段了。關於流程圖我有以下幾點個人領悟：
1.要知道流程圖是給誰看的？是給別人看的，是給乙個並不了解實現細節的人的看的，是給乙個完全不懂技術的人看的，是給任何乙個想看的人看的。如果我們的流程圖可以讓乙個不懂技術的人都能看的明白的話，那麼就畫的不錯了
2.流程圖和編碼實現的關係。個人覺得，如果乙個流程圖足夠好，那麼就完全可以用偽**實現了，然後由偽**轉化為任何你想用的語言。好的流程圖可以基本上就可以看做**了，也許是這樣大師把流程圖畫好，剩下的就交給coder了
3.好的流程圖到底有啥用？乙個清晰的思維不僅要展現在你優秀的大腦裡，更應該展現在紙上。好腦子比不上爛筆頭，只有在實體介質上體現出來，才能多角度論證，排查，以及交流。我當時寫程式的時候，就記腦子裡結果現在一腦子江湖，專案經理來確認個問題，我就必須翻**，效率極低。
4.繼續領悟中。。。
好了，這次就分享這麼多痛苦的教訓吧，謹以此文紀念我最近加班熬通宵的日子，希望早日能游刃有餘，不在是乙個半路出家的菜鳥。
我為什麼要轉到軟體工程專業
作為乙個轉專業的降級生，從計畫轉專業到現在，總是會聽到有人問，為什麼想要轉專業啊 而我每每只能尷尬一笑，然後搪塞過去 不是別的，只是覺得考慮實在太多了，很難一言以蔽之。所以在這個人技術部落格的第一篇，我想我有必要再好好梳理下我想要轉專業的理由，作為今後走在技術之路上前進的動力與方向。我一直覺得，在考...
我為什麼要選軟體工程專業
我為什麼要選軟體工程專業 我一直覺得，在考慮專業的選擇或人生的規劃問題時，興趣應 當是最重要的因素。我相信只有對一件事感興趣 有熱情，才 有把這件事做下去 做好的可能。但同時我還覺得，真正意義 上的興趣的發現是很難的事，在深入學習一門學科之前，我們 往往並不知道自己是真的對它有興趣，還是只是崇拜一些...
產品經理專業技能之BRD MRD PRD文件撰寫
1.excel 產品經理的神器 資料統計 資料包表 資料分析 資料圖列製作 進度控制 2.powerpoint 演示 3.word 文件 4.microsofo visio 2013 流程圖 資訊結構圖 5.axure6.5 原型圖 6.mockups 原型圖草圖 不干擾ui設計 7.mindjet...