Fw: [心得] 幾本讓我成長很多的書

看板Soft_Job作者 (生活禪)時間11年前 (2014/09/20 14:27), 11年前編輯推噓9(9推 0噓 59→)
留言68則, 9人參與, 最新討論串1/2 (看更多)
※ [本文轉錄自 CompBook 看板 #1K75gpf4 ] 作者: Zephyr750 (紅蓮西風750) 看板: CompBook 標題: [心得] 幾本讓我成長很多的書 時間: Sat Sep 20 00:32:49 2014 我是用C++這種可怕語言開發的開發者。 從研究所畢業之後，我只會C和verilog 當時，我只唸了VerilogHDL學會了Verilog，但是完全只是熟語法... 而C只靠大學課程的印象 一路走來，到了軟體公司，才發現業界有些公司其實....說強不強。 我想跟大家分享我看的書以及得到的東西。 希望有興趣的朋友可以看看.... 1. K&R2 這本是很有名的書，一開始會看，完全是因為「C學會了再學C++」的誤解。 我看這本書方式，是從第一個字開始看到最後一個字。 因為這本書，讓我重新學習C語言，了解C語言的強項與技巧 enum、struct、pointer、funtion pointer.... 2. 螞蟻書 會買這本，有兩個原因，第一，這是我大學時使用的課本(雖然版本不同)， 第二，它比K&R2介紹了更多「前置處理器」的用法。 但是其實看完了，還是不太會活用，因為不會花太多心思在它身上。 這本書，我只看前置處理器的章節。 3. C到C++入門速成 這本是在義守大學圖書館找到的，其它大學的圖書館似乎不一定有。 這本很特別，是無意間翻到的，它比較了C和C++各個不同之處集結成書。 這本書，是從第一個字開始看，整本看完。 4. 世紀末軟體革命、從C到C++物件導向革命 為了了解「物件導向」特別去找了幾本，但是都沒看完，世紀本軟體革命， 我是買復刻版，還有找到其中一個作者簽名。(超幸運) 《從C到C++物件導向革命》是抄襲之作... 而物件導向是怎麼了解的呢？ 把C++當作verilog寫一次，就明白了。瞬間了解類別是什麼！ 5. C++ Primer 4/e 我看的是四版，建議看三版，不過五版已經出了。新功能看來都是人家的舊功能！ 似乎五版值得買。 這本是和C++爸爸書一起買的，是為了要找C++好書而開始狩獵，這兩本聖經本 當然不能放過，讓我對C++有了全新的體驗。 這本書看到一半，但是因為當時是一邊看，一邊學，一邊練習，所以很紮實。(應該) 學C++有四個階段 C++ without OO ->做一些C在做的事 C++ with OO C++ template C++ general 最精彩的，是OO的部份，const的介紹，return this, return *this的用法、 覆寫運算子.....等。 把整個記憶程式的方式，以心智圖的方式，物件導向的形式呈現 之後，就常常跟人家說，挑一本好的C++入門書，看它的hello world就知道了！ 看它的#include 是放stdio.h還是cstdio還是iostream。 看它是教你printf還是cout 看它的main回傳值是void還是int 看它有沒有return 0 不是這樣做不行，而是身為一本教學書，就要以標準寫法為範本。 另外，看別人會不會C++看它的set和get怎麼寫的就知道了。 雖然是coding style的問題，但是C++不把持一點，很容易寫成泥巴。 void SetValue(const Foo& Obj); const Foo GetValue() const; 把權限最小化，就是最好的寫法。也許你會問為什麼，我只能說，當你要把物件丟 STL到裡的演算法使用時，它就會卡這個。 6. 人月神話 這本很有趣，我也忘了當初是在哪看見推薦的了。寫了這麼久的程式，你真的了解 自己在做的是什麼樣工作嗎？寫程式有什麼性質？有什麼特性？什麼該做？什麼不該做？ 有哪些事是過去前人就說超難做的，會不會不知不覺走到了一個前人有說「要小心 不要往這方向去了」的路呢？ 這本是開讀書會看的書，從第一個字看，整本看完。 最棒的就是第二系統效應、預估(很難)、巴別塔、外科手術團隊 還有最後的「沒有銀彈」 這本影響我最大的，是它一直提的「整體概念性」是寫程式最重要的一件事。 不管是設計、coding還是重構時，其實都用得上這個概念。 7. 軟體建構之道2 這本可以說是我個人生涯看了最棒的一本書，也是因為它在Inside的排行榜裡排第一名 所以不看似乎對不起自己是程式設計師這件事。 它從設計開始介紹，講了很多寫程式時會遇到的疑惑 這樣寫也可以，那樣寫也沒錯，但是語言這樣設計的用意，應該是兩種寫法不同。 究境是哪裡不同呢？一連串在寫程式要決策的事情，就是設計師的用心之處 在第八章 防禦性程式設計裡有提到條件編譯的使用方式，還有如何讓自己的程式 更強壯或更正確，assert()的使用，最後提到自殺式程式設計來提升 交付程式前的強壯程度。 有看過這種命名的嗎？ int temp; string str; return rtn; void doSomething(); float tmpValue; void setValue(); int getValue(); 是不是讓程式碼與人的距離愈來愈遠了呢？ 最有趣的是連return的使用方式，它都有介紹！ 程式設計做到最後，就像是把中文翻譯成程式語言。 class包含物件，與class繼承class的差別是什麼？have和is的差別！(超酷的) 前半部，是教你用技術提升品質。 後半部，是教你用管理提升品質。 繁體中文版超貴。建議看簡中會順暢很多，而且還有潤句子和校"完"稿....(懂吧？) 當初看是開讀書會，同時看簡中、繁中、英文。 沒有整本看完，看了前半段就放著了。 強烈推薦要看，尤其是有在code review的公司。 這本書影響我最大的是人月神話提的「整體概念性」實作在class、function、變數命名 分析了「整體概念性」與「名字」之間的重要性，還有命名帶的隱喻，會影射出概念。 讓程式碼可讀性提高，就像是寫文章的譬喻法啦！ 8. Effective C++ 只能說，要把C++寫得像C++就看Effevtive C++。 翻過，跳著看。沒細讀。它是超棒的書。 很想全系列買下來 之後有看到Effective C#不過只有英文版.... 但是，簡中有部落格文章唷！ 9. 敏捷開發的逆襲 這本是台灣人寫的！對敏捷式開發的流派Scrum介紹得很深入，也因此對敏捷式開發流程 有了一個範本，在了解其它流派，會更加的知道這是什麼。 這本書，從頭看到尾，很精彩！內容很多。 另外，後面介紹了很多工具在「實作」敏捷開發有很大的幫助(至少有工具)，剩下的就是 建立工作流程與工作能力了(單元測試) 10. 大話設計模式 這本是C#的設計模式，是讀書會開的書。 從第一個字開始看，整本幾乎看完，但是看完還是不懂(這是Design Pattern書的特色？) 有些簡單易用的Pattern就可以快速的學下來。 有些難懂的，就先放著，有緣自然就懂了。 看C#的Design Pattern除了因為讀書會看之外， C++這一本實在是一本「Design Pattern DM」，看看具體實例先 而且，C#的寫法有些C++都要自己手動來。就會上網多找資料。 這本書並不是每個例子都很棒，但是它會從爛code重構給你看(大多數的例子) 所以，還可以看一下重構的過程，我覺得練習一次很有體會。 我是用C++練習的，所以很多地方不需要指標的，要自己看， 要delete指標的要自己判斷一下 以上。 我一直相信，C++之所以難用，是因為它重點在「設計」， 而不是一直使用它既有的語法與功能。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 115.43.209.187 ※ 文章網址: http://www.ptt.cc/bbs/CompBook/M.1411144371.A.A44.html ※ 發信站: 批踢踢實業坊(ptt.cc) ※ 轉錄者: ZenLife (1.170.72.248), 09/20/2014 14:27:00 ※ 編輯: ZenLife (1.170.72.248), 09/20/2014 14:30:27
推
09/20 14:46, , 1F
[OT]有人很很反對get,set的寫法
09/20 14:46, 1F
→
09/20 15:16, , 2F
因為命名嗎？
09/20 15:16, 2F
推
09/20 16:41, , 3F
這種文楨步錯
09/20 16:41, 3F
→
09/20 16:41, , 4F
真不錯
09/20 16:41, 4F
→
09/20 20:10, , 5F
Design pattern的特色就是 你程度不到就看不懂
09/20 20:10, 5F
→
09/20 20:53, , 6F
看來你已經走入了一個方法論的路徑
09/20 20:53, 6F
→
09/20 20:54, , 7F
99% 的方法論者為強迫症潛在病患
09/20 20:54, 7F
推
09/20 20:56, , 8F
design pattern看得懂不一定會運用，會運用也可能用過頭
09/20 20:56, 8F
→
09/20 20:56, , 9F
..
09/20 20:56, 9F
推
09/20 20:58, , 10F
理想很高，理論完美，但脫離實際
09/20 20:58, 10F
推
09/20 22:29, , 11F
自己用過在實際的專案上 書上的例子其實簡單到無法直接套
09/20 22:29, 11F
→
09/20 22:30, , 12F
DP 通常你還要加上一些自己專案依賴的實體或網路的
09/20 22:30, 12F
→
09/20 22:31, , 13F
Error Handling
09/20 22:31, 13F
→
09/20 22:32, , 14F
個人原則是除非你的case真的極度接近DP example 否則別用
09/20 22:32, 14F
→
09/21 10:00, , 15F
樓上別誤導好嗎? design pattern盡量不用我還是第一次聽到
09/21 10:00, 15F
→
09/21 10:02, , 16F
感覺是學生講出來的話 工作的人說出口蠻慘的
09/21 10:02, 16F
推
09/21 10:09, , 17F
應該是盡量不要"完全套用"，而是理解設計原理去根據需
09/21 10:09, 17F
→
09/21 10:10, , 18F
求作最適當的Design，五大設計原理加上經驗就很夠用了
09/21 10:10, 18F
推
09/21 10:12, , 19F
另外我覺得用過頭是必經之路 有 over-design過 再發現
09/21 10:12, 19F
→
09/21 10:13, , 20F
缺點在哪，才是真正進步的開始 比一開始就不用好多了
09/21 10:13, 20F
→
09/21 10:25, , 21F
我要表達是有時候你會誤以為你可以套 其實狀況又不太一樣
09/21 10:25, 21F
→
09/21 10:26, , 22F
在模組大框架會根據需求容易變動的時期 也盡量還不要使用
09/21 10:26, 22F
→
09/21 10:30, , 23F
通常一開始土法煉鋼 定下來後也改不動了 或是時間成本很高
09/21 10:30, 23F
→
09/21 10:31, , 24F
然後就開始惡性循環
09/21 10:31, 24F
→
09/21 10:32, , 25F
不然你以為那些優秀的open source一開始就沒定好架構嗎...
09/21 10:32, 25F
→
09/21 10:32, , 26F
他們也是一直持續變動阿...還不是寫的很彈性 都是看功力
09/21 10:32, 26F
→
09/21 10:35, , 27F
有時user連他們要什麼都不確定 那種變動會從適用到不適用
09/21 10:35, 27F
→
09/21 10:35, , 28F
一開始不用生一些莫須有的抽象類別和實作 但是架構要有
09/21 10:35, 28F
→
09/21 10:37, , 29F
這樣抽出來或修改的時候 時間成本才會壓低
09/21 10:37, 29F
→
09/21 10:42, , 30F
整支程式架構當然是有 但開發初期細部模組user都還在揣摩
09/21 10:42, 30F
→
09/21 10:43, , 31F
太早套下去 結果需求變動大到不適用DP的情況就會做白工
09/21 10:43, 31F
→
09/21 10:46, , 32F
就是因為會ㄧ直改才要用設定模式
09/21 10:46, 32F
→
09/21 10:48, , 33F
好吧~你高興就好
09/21 10:48, 33F
→
09/21 10:49, , 34F
但是也不是一開始土砲就沒救了 適當重構就可以幫助導入DP
09/21 10:49, 34F
→
09/21 10:54, , 35F
然後接手的就在想 這坨屎是什麼?
09/21 10:54, 35F
→
09/21 10:55, , 36F
台灣si工程師的悲劇由此開啟序幕
09/21 10:55, 36F
→
09/21 10:55, , 37F
你說得比較像是都不用DP 跟有節奏的重構再導入DP不一樣
09/21 10:55, 37F
推
09/21 11:44, , 38F
架構想法因人而異沒什麼對錯，pattern用了肯定會讓程式
09/21 11:44, 38F
→
09/21 11:44, , 39F
碼更難懂，對神級人物來說可能不會，但接手的人呢?寫給
09/21 11:44, 39F
→
09/21 11:44, , 40F
人家用的需要考慮更多，總不可我邏輯改了，別人使用的ap
09/21 11:44, 40F
→
09/21 11:44, , 41F
i故障一堆。但自己寫的時候完全懂來龍去脈，所以問題不
09/21 11:44, 41F
→
09/21 11:44, , 42F
大，但pattern應該是讓你程式碼更彈性，在不影響現有功
09/21 11:44, 42F
→
09/21 11:44, , 43F
能下擴充新功能，或者是原有功能改了，但我只需要改一
09/21 11:44, 43F
→
09/21 11:44, , 44F
個地方就能異動所有地方，怎麼會是用了就定型架構更難
09/21 11:44, 44F
→
09/21 11:44, , 45F
改??你可能要更深入去認識dp的理念...但沒有銀彈，正常
09/21 11:44, 45F
→
09/21 11:44, , 46F
狀態下不要過度設計，但影響過大的時候，該用還是得用
09/21 11:44, 46F
推
09/21 11:47, , 47F
而且其實有在使用物件思考寫程式的，無形中就會用很多pa
09/21 11:47, 47F
→
09/21 11:47, , 48F
ttern了，即使你去讀的時候，你可能還看不出來這些patte
09/21 11:47, 48F
→
09/21 11:47, , 49F
rn你早就用類似方式去做過了...
09/21 11:47, 49F
→
09/21 19:10, , 50F
Pattern只是單純的讓code變得更好維護。變動範圍變小
09/21 19:10, 50F
→
09/21 19:10, , 51F
否則，用Pattern就只是惹麻煩而已。
09/21 19:10, 51F
→
09/21 19:11, , 52F
另外，在使用Pattern上難免會誤用(過度設計或硬要用)，
09/21 19:11, 52F
→
09/21 19:12, , 53F
這種情況就是對Pattern的熟悉度不夠或者誤解。
09/21 19:12, 53F
→
09/21 19:13, , 54F
csfgsj版友提到「方法論」>>「強迫症潛在病患」我認為
09/21 19:13, 54F
→
09/21 19:14, , 55F
是一種工匠的偏見...
09/21 19:14, 55F
→
09/21 19:15, , 56F
工匠有匠氣，設計師就是你說的強迫症病患...吧？
09/21 19:15, 56F
→
09/21 19:16, , 57F
「有系統的把想法串起來，透過理性的佈局創作作品」
09/21 19:16, 57F
→
09/21 19:17, , 58F
如果說依靠設計方法會成為強迫症患者，那麼正常人應該
09/21 19:17, 58F
→
09/21 19:18, , 59F
也不適合我當吧！^^
09/21 19:18, 59F
→
09/21 19:19, , 60F
「DP就像是格鬥遊戲的大絕招，要背按鍵組合」這是別人
09/21 19:19, 60F
→
09/21 19:20, , 61F
但，千萬不可以有匠氣！'
09/21 19:20, 61F
→
09/21 20:59, , 62F
最後一句是在提醒我自己用的啦！^^"
09/21 20:59, 62F
→
09/22 04:06, , 63F
DP這種經驗的東西~就是心法~是讀來讓心裡有個觀念的~運用
09/22 04:06, 63F
→
09/22 04:08, , 64F
上就跟資料庫正規化一樣~因人、時、事而可能有所不同~也
09/22 04:08, 64F
→
09/22 04:11, , 65F
正因為如此~DP並不侷限在一種語言上~實際案例也往往比書
09/22 04:11, 65F
→
09/22 04:12, , 66F
上寫的更複雜~架構好不好接手其實在於兩人觀念和領域知識
09/22 04:12, 66F
→
09/22 04:14, , 67F
是否夠相近~落差一大~當然不懂對方在寫什麼~設計得對還是
09/22 04:14, 67F
→
09/22 04:15, , 68F
不對~往往要探討更多的因素...
09/22 04:15, 68F
‣ 更多 ZenLife 的文章
文章代碼(AID): #1K7HurtN (Soft_Job)
‣ 更多 ZenLife 的文章
文章代碼(AID): #1K7HurtN (Soft_Job)