今天筆者想來和大家討論一下，首先給大家介紹一下筆者的個人特點，筆者自詡並不是一個耐得住性子的人，做一件事情如果長時間得不到回報，那對筆者來說是一種打擊，筆者不是不能忍受十年磨一劍，但是在筆者看來十年磨一劍，我在磨的時候也應該能夠感受到，劍正在越來越鋒利，如果告訴我，十年磨一劍前9年364天都看不到效果，到最後一天會一下子爆發，這是筆者不能接受的。
打一個不恰當的比喻，有些男生追妹子追到一半放棄了，別人問他為什麼放棄了，很簡單，因為他看不到希望，如果他能感受到兩個人的感情越來越親密，哪怕很慢，我相信他是不會放棄的，而如果每天都是熱臉貼著冷屁股，誰的耐心都會被消磨乾淨。
因此，相信很多同學和筆者一樣，大家願不願意努力的前提，並不是這件事情容不容易做，而是大家是否能看到希望。
當然，人生的事情我們以後再談，筆者今天的重點是解決做專案遇到的困難，給大家介紹一下，用搭積木的思維去做專案
筆者在做專案的時候發現，拋開需求分析啥的這些不談，哪怕是筆者面對一個學校課設，需求已經給好了，從頭開始做的時候往往無從下手，筆者用僅有的專案經驗總結了一下
當我開啟整合式開發環境做的第一件事情是什麼，不用說，肯定是新建專案，但是往往新建專案這看似簡單的一件事情，有時候因為種種問題，有時候也要浪費掉一個小時，最後就為了輸出一句Hello，World。沒錯，這雖然是成功了，但是這才是萬里長征第一步，我花費了半天力氣才執行出一句Hello，World，一想到後面還有一堆事情等著我去做，這讓筆者實在是感到無力。
筆者之前也提到自學前端做了一個前端專案，後來筆者發現，在做專案的時候專案裡發現需要留一個頁面叫TestPage.vue，而且寫路由的時候也需要給一個路徑，這個頁面是幹什麼用的，沒錯就是遇到一個比較複雜的介面元件的時候，脫離專案單獨做看效果的。
配合上前面搭建環境輸出Hello，World，做專案其實就是一步一個腳印，最後成型出完美的專案。
這本來其實是一句廢話，我相信看部落格的同學們，每個人都懂，但是筆者在一開始就說了，筆者是一個需要正向反饋的人，做一個完整的專案並不等同於堆積功能數量，其中還包括模組劃分，介面設計，結構優化種種內容，這些和功能設計全部累加到一起，困難就太多了，等到做出來筆者已經沒有力氣再去做下一個了。
說句實話，做一個專案，大家千萬要搞清楚我們最終的目的是什麼，是比誰走的更遠，而不是比誰走的更辛苦，因此，有更平坦的道路和方法儘管去走，沒有必要整得像教科書上一樣爬雪山，過草地，最後好不容易做出來了各種宣傳自己有多不容易。翻過一座縱向距離很高，但是橫向距離跨度很短的山，最後你走的路可能和平路的同學一樣長，但是你還是得不到面試官的認可。
基於以上的指導思想，筆者必須要想辦法將困難拆分開，把翻山越嶺變成跨過小石頭，在整體工作量不變的情況下，把做事情的難度降低。
那麼比起做專案，只是做一個簡單的功能，我們的工作量就大大降低了，同學們只需要設計一些功能需求啥的，最後把這一個部分去做完善就可以了，筆者一開始就提到了，我們要用搭積木的思維來做專案，積木大家還記得怎麼玩的嗎？事實上，我們拿到積木從來不是直接把所有的積木拼起來，而是幹嘛，有時候是拿著積木在把玩
除了搭建一個複雜的工程，某種程度上我們玩積木最開心也是最有用的時刻是什麼，是對積木的熟練認知設計出來的創意，有的時候花幾分鐘把幾塊積木搭建起來做一把手槍這樣的小創意，帶來的樂趣往往不虛花一個禮拜搭建一個埃菲爾鐵塔。
那麼回到專案中也一樣，除了最後做出一個專案給出的完整的正向反饋，能夠帶來的正向反饋對各種小功能有非常熟練的認知，比方說我們要做一個導航app，那麼最短路徑問題就是我們必須要熟練認知的
同學們想想如果你現在完全不懂什麼是最短路徑問題，當你學會的那一刻是不是覺得很開心也很有用。
包括筆者在內，我相信大部分同學工作都很忙，很難有時間像在學校裡一樣抽出大量的時間和精力做個人專案，並且有些同學可能工作環境比較惡劣，有著上班如上墳的窘境，但是如果長期不改變，最後只有被優化的命，但是改變如果長時間沒有正向反饋，相信同學們也很難堅持下去
因此筆者一開始就提到的正向反饋的重要性，所以，如果同學們目前面臨著窘境，不如用搭積木的思維，先放棄全域性，看區域性，實現一小部分功能，把積木放在手裡把玩是不是會更加開心。
那麼這個時候積木數量足夠了，我們的對積木的瞭解也已經足夠透徹了，現在就到了搭積木的時候，該怎麼去做專案，筆者前面就提到，做一個完整的專案並不等同於堆積功能數量，其中還包括模組劃分，介面設計，結構優化種種內容，這個時候你要做的事情就大幅減弱了，你只需要考慮怎麼樣把專案結構做的更合理就可以了，那麼功能設計的部分怎麼辦呢。一句話，最簡單的Ctrl C+Ctrl V，做一些小幅度改動保證貼合專案就可以了，那麼肯定有同學要問了，我貼進去和專案不協調怎麼辦，筆者認為，這個概率不高，為什麼？大家還記不記得軟體開發的一大原則，高內聚，低耦合
高內聚和低耦合是軟體設計中的兩個重要原則，用於指導軟體系統的設計和開發。
高內聚（High Cohesion）是指一個模組或一個類應該具有高度的功能相關性，即一個模組或一個類應該只負責完成一個特定的功能或任務。高內聚的模組或類內部的各個元素之間關聯緊密，彼此依賴性強，共同完成一個明確的功能。高內聚的模組或類具有以下特點：
低耦合（Low Coupling）是指模組或類之間的依賴關係儘可能的弱化，即模組或類之間的相互影響和依賴性降到最低。低耦合的模組或類具有以下特點：
高內聚和低耦合是相輔相成的，它們共同促進了軟體系統的可維護性、可延伸性和可重用性。通過遵循高內聚和低耦合的原則，可以提高軟體系統的質量，降低開發和維護的成本。
沒錯，如果你在開發的時候功能堆積進去發現牽一髮動全身的現象，那麼大概率你的軟體設計並不夠合理，這個時候同學們要記住：軟體設計不合理，不能讓功能開發來給你擦屁股，要分清楚責任，否則那就會出現大家經常掛在嘴上的屎山程式碼。
那麼今天就和大家聊到這裡，希望筆者可以給大家帶來一些幫助，早日克服困難，做出屬於自己的獨家專案，筆者接下來會更加努力的工作，給大家帶來更多的經驗分享，希望同學們工作順利，早日升職加薪、當上總經理、出任CEO、迎娶白富美、走上人生巔峰，想想是不是還有點小激動呢