? 學Java好多年，也參與一次完整項目，覺得讓自己寫項目寫不出來，總覺得缺了一部分。
? 在這方面愚笨，不知道缺在哪里。以前覺得是知識不夠牢固，于是重復去學，發現就那些東西。如果沒有業務來熟悉的話，不會明白那些內容為什么要那樣做。
? 周圍的人，在我看來都是按規矩辦事的人，不會有太多思考。讓做什么就去做了，沒有多少人想這樣做是否合適。像使用框架，都在背框架有哪些好處，怎么去使用。到工作中也是直接就可以拿來用，并沒有人思考為什么會產生這個框架，為什么會產生那種需求和這種解決方案。明明很龐大和繁瑣，思維不夠緊密，還是那么多人在用著，不厭其頭痛。
? 框架是個很大的迷宮，在迷宮中勉強湊合出功能。卻沒想過一開始就自己找路線，不去用那迷宮。
? 這些事說不清。對框架我也沒有多深入的理解，覺得那些作用都很別扭。當然有一部分核心功能是很好用的，讓人一看就明白為什么要那樣做。可是一些拓展功能，就把框架本身弄得復雜而龐大。
? 想起，像玩魔獸時候用插件。國內用個大腳，把所有插件都打包，用到的、用不到的。可是其實可能想要的就一兩個而已。如果說多了也不要緊，不傷大雅，我就沒話說了。
? 不過框架的復雜不是做不成項目的直接原因。總覺得在這些類似的復雜背后，有什么是自己不懂的。于是不好承擔項目這份責任。
? 其實寫項目沒有多大興趣，不是對編程解決問題沒興趣，是對那些劣質的需求沒興趣。都是重復做的事，這件事很多公司已經做了，還要復制過來繼續做。說著解決新問題，其實是在解決舊問題。別人做了百八十遍了，你再做出來有什么意思。有人說掙錢，這確實，可如果大部分人做的都是這種工作，那就不對勁了。
? 有種觀點是環境是這樣。以前需求過來，國外給設計，國內再編程。現在成APP了，好像直接自己就可以做出來。需求水平其實沒什么變化，APP論實現路線要比電腦版簡單的多，只是互動性增強。所以按照以前電腦版的解體水平，可以自行處理APP。只是程序設計水平還是沒有變，需求水平沒變以至于使用框架就可以解決所有問題，沒聽說哪個項目需要自行研發脫離框架。業務模式是從別人那里復制的，公司做的軟件就是別人走過的路，使用框架就很容易滿足需求。再臃腫也不要緊，有情愿受苦受累的搬運工。拿著高新其實不知道能成長多少。
? 覺得編程可能變成一件繁瑣的事。如果說新功能，是有的；可是說實現套路，是沒什么變化的。
? 這些事情是這樣，可還是不明白自己缺少的那一部分是什么。總覺得自己獨自寫不出來項目。
? 第一份工作是在別人項目的基礎上打打補丁，當時也覺得寫不出來項目，可從數據庫建表到后臺，再到前臺頁面更改，都涉及到了。要說做項目還是做不出來。除了現有的公司軟件編程方式和我的不一樣以外，還有是自己知識不夠全。并且不知道缺少了什么。
? 對軟件思考那么多年，想來早應該做到游刃有余。不知道哪里困惑了自己，卻覺得困惑是存在的，包下整個項目會沒有底氣。
? 想起PN結來，模擬電路課上遇到的，自己思考了很多遍，把思路一遍遍走通，可是走通之后，還是覺得不會。大體意思明白，大體思路知道，可是中間是迷霧的。這條路走了這么多變，按理說應該很容易走過來。可是自己知道走過之后就忘了，如果再走一遍需要重新做那些思考，一步一步核對著走通過來。熱度在那里的時候還記得，熱度過了之后又忘了。然后就到了晶體管，稍復雜一些的PN結，就不好走通了。知道結果，忘記了為什么會是這結果，久了結果也一并忘了。費那么大勁研究好幾遍的思路，到頭來什么都沒了。給個電路不能理所當然就知道結果，這讓人覺得好憋。
? 知識運用久了，或者理解透徹了，是可以有感覺的。下次再使用這份知識，用的就不是大腦，不用思考就自然知道結果，這才算是真的會。
? 編程久了，看一遍就知道運行結果是什么。運行一下只是確認沒有疏漏。腦袋也是有容量的，像是胳膊上的肌肉。經常鍛煉的話，承受的代碼量就多，這里邊的邏輯就很容易做到無誤。代碼量再多，更龐大起來，這里邊就容易出現失誤。個個環節搭連在一起，整個項目受到牽動。這時候先做框架設計，再寫每一個小模塊，先畫樹干再畫葉，或許是不錯的選擇。容量夠承受整個程序，應該就可以做項目設計。可是這里邊的道道實現起來，并沒有那么隨心。
? 框架是個很大的阻礙。使用框架寫程序使得事情要按固定的模式發展。而且框架有陰暗的地方，自己不被告知，沒有去鉆研底層的地方，這樣用起來就不知道整體是怎么流通的，程序設計起來就頭大了。可是，又不能不去用框架，因為別人都在用，不用框架的話要自行承擔項目逾期的風險，用了框架的話即使逾期了也不要緊，因為都是使用框架后，同樣的項目給別人做照樣會逾期，這和自己沒有主動關系。
? 程序設計的繁瑣在使用別人的框架，是個很大的累贅。程序做不好不要緊，使用現在流行的框架了，你能很隨便地打補丁。打到不行了，就找高人來解決，就打高級一點的補丁。這就是框架的好處，只要程序沒有高級到一定程度，在框架承受的范圍內就好。可是使用框架的話，就不要談程序設計了，該怎么做別人已經給固定好了。也不要提軟件的整體性，注定從一開始就是個補丁。
? 可真要脫離框架了，那些涉及底層或者熟練的業務處理方式都要自己手動寫。這些都是非常棒的思考，作為一個學習著會很高興接觸到這部分。可是作為公司，很難有這么大的需求，如果流行框架給的業務處理就能滿足，為什么還要花錢自己寫？流行框架可是免費的。
? 即使是這樣。還是覺得自己缺少了一部分。對框架的掌握我確實沒有怎么熟練，也并不想去接觸太多。可是這和整個項目的走通并沒有太大關聯。不知道自己缺少的是什么。
? 軟件相關的計算機知識是一個很龐大的系統。即使在我而言不明白它龐大在哪里。照我的想法，理論的東西走通了明白了之后，不就什么都知道了嗎？可真當想去走通，卻發現并不那么容易。不是邏輯問題，自己覺得反倒是人情問題。猜測是這樣。一些解決辦法的產生，是在當時時代背景下醞釀的，可能解決方式還有很多種，相關的可能性還有很多種。只是在當時的資源環境下，就產生了那唯一的一種。以至于現在反過來都不怎么明白，為什么會那樣去做，覺得很繁瑣，不好背下來。這樣想著，于是問自己，如果想去了解CPU的運行，難道還要去和生產CPU的人工資在一起，去明白其中包含的情感？ 呵呵呵。大概是知識對我來說太龐大，超出了可以消化吸收的范圍，才產生了一些偏離的邏輯。
? 去研究底層遇到障礙，去弄明白需求市場覺得看不到更高層析的需求。而眼前的做項目，仍然一個人做不下來。
? 不懂框架，加上不懂業務需求，不敢肯定自己做出來的軟件是符合需求的。是一條不知道結果的路。我倒覺得，做軟件本身就應該是這個樣子，本身就是融合自己的思考，拋開那些累贅的框架，做適合當前需求的系統，為當前系統量身打造。所有的處理都去自己寫，每一步都有輕微的變動。這對程序員和公司來說，都可以得到良性的成長。
? 不用流行框架上的解決方案，自行設計思路，摸著石頭過河，不適用再改。有什么公司能有這種需求？
? 覺得我缺少的，或許是耐心，卻又不這樣認為......
 的認知)
