Re: [情報] 十條不錯的編程觀點

看板Soft_Job作者 (幸福治安：破案數/十萬人)時間13年前 (2012/04/18 14:30), 編輯推噓9(9推 0噓 67→)
留言76則, 11人參與, 最新討論串2/5 (看更多)
※ 引述《Lordaeron (Terry)》之銘言： : Link : http://coolshell.cn/articles/2424.html : 基本上都寫得不錯, 特別是: : 1） The only 「best practice」 you should be using all the time is : 「Use Your Brain」. : 唯一的「Best Practice」並不是使用各種各樣被前人總結過的各種設計方法、 : 模式，框架，那些著名的方法、模式、框架只代碼贊同他們的人多，並不代表他 : 們適合你，你應該更多的去使用你的大腦，獨立地思考那些方法、模式、框架出 : 現的原因和其背後的想法和思想，那才是「best practice」。 : 事實上來說，那些所謂的「Best Practice」只不過是限制那些糟糕的 : 程序員們的破壞力。 : 而第三點, 則, 要講why, 哪就說: 老闆要我寫. 絕對是最好的註解. 我個人的看法，並不認同第四點： 4) XML可能被高估了（XML is highly overrated） 一、若要更改格式，資料以 XML 儲存，可以比較容易地轉換格式。 比方說，可以使用 XSLT 。 雖然 XSLT 也算是一種語言，但相對地比實作一個剖析器簡單許多。 二、若要更改資料格式，XML 也比較容易處理過渡時期。 假設有一個軟體會讀取設定檔，而這個軟體有舊有的版本，亦有新的版本。 而新版本的軟體可能對格式要求有所更動。 一個很簡單地方式就是在同一個 XML 裡包含兩份標籤， （也就是同樣的設定分別以新、舊格式同時存在 XML 裡） 三、 假設軟體要實作新功能，而且要求資料需要新欄位。 而資料很大，可能無法一時間就 使用 XML 時，可以添加新欄位（譬如新的屬性、新的標籤）而不會影響會有的剖析器 當所有資料都添加完新欄位，就可以更改剖析器 當然，使用 XML 也有一些複雜，雖然已經有現成函式庫，但要學習 我個人的看法是，程式初期可以不用使用 XML ，這樣在實作剖析器比較簡單 而且，在變更格式時，修改剖析器及轉換資料也很方便 但如果程式的功能愈來愈多，資料愈來愈複雜，就可以考慮 XML -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.30.46
→
04/18 14:52, , 1F
XML 最少哇哇叫了十二三年了, 結果到現在, 有什麼大用?
04/18 14:52, 1F
→
04/18 14:53, , 2F
再說parsing XML 的overhead 相當重.
04/18 14:53, 2F
推
04/18 15:17, , 3F
我還是最喜歡CSV格式，雖然結構性好像很差
04/18 15:17, 3F
→
04/18 15:17, , 4F
不過在一些低階平台寫程式很好用...
04/18 15:17, 4F
→
04/18 15:20, , 5F
XML的肥,讓人難忘, CSV的簡單,同樣讓人難忘
04/18 15:20, 5F
推
04/18 15:23, , 6F
這幾點其他表示法 JSON, Protocol Buffers, YAML 都可以
04/18 15:23, 6F
推
04/18 15:23, , 7F
之前有幫x51設計configure介面(手機+藍牙)，fixed格式
04/18 15:23, 7F
→
04/18 15:24, , 8F
會遇到修改的問題，所以還是選擇CSV...
04/18 15:24, 8F
→
04/18 15:39, , 9F
html/html5 這用途還不夠大嗎？ 這個不夠大的話，chart 也有
04/18 15:39, 9F
→
04/18 15:39, , 10F
很多相關應用。 Parsing 固然有 overhead，但是碰上真正複雜
04/18 15:39, 10F
→
04/18 15:39, , 11F
的東西，你用其他的根本是做不到，舉例，用 csv 管理多層
04/18 15:39, 11F
→
04/18 15:40, , 12F
巢狀資訊不是找自己麻煩嗎
04/18 15:40, 12F
→
04/18 15:41, , 13F
當然如果你的東西是可以一個二維表格就表示完了的，那就不用
04/18 15:41, 13F
→
04/18 15:41, , 14F
動大刀，用csv就好。如果你的資料只有基本型態，像是array/
04/18 15:41, 14F
→
04/18 15:44, , 15F
map/string/int 加點巢狀，那可以簡單的用個 json 就好 。
04/18 15:44, 15F
→
04/18 15:45, , 16F
當然另一個問題是要考慮平台相容性，舉例，web 上 json 就比
04/18 15:45, 16F
→
04/18 15:45, , 17F
csv 適合拿來作資料處理，如果你今天是作 html 操作，那就更
04/18 15:45, 17F
→
04/18 15:45, , 18F
不如把資料轉成 html 形式來傳遞。
04/18 15:45, 18F
→
04/18 15:45, , 19F
XML 的目標是作為meta data, 用作儲存用. 所以還得具有
04/18 15:45, 19F
→
04/18 15:46, , 20F
validate 的功能, 而html 則是作為presentation 用
04/18 15:46, 20F
→
04/18 15:46, , 21F
可以不用validate, 兩者差異在這. 加上validate
04/18 15:46, 21F
→
04/18 15:46, , 22F
另外對於那種只會爬一次的 config file ，基本上不用太重視
04/18 15:46, 22F
→
04/18 15:47, , 23F
overhead xml 就比html 來得大了.
04/18 15:47, 23F
→
04/18 15:47, , 24F
overhead，因為頂多就是啟動時慢一點，跑起來都在memory了。
04/18 15:47, 24F
→
04/18 15:47, , 25F
不然, 你無聊時, 拿oracle 來開刀, 用它的xml 功能
04/18 15:47, 25F
→
04/18 15:47, , 26F
來玩玩, 看你query會慢多少.
04/18 15:47, 26F
→
04/18 15:48, , 27F
我並不這麼覺得，html 是因為他容錯性作得比較好，但不代表
04/18 15:48, 27F
→
04/18 15:48, , 28F
不用 validate 。
04/18 15:48, 28F
→
04/18 15:48, , 29F
當你每筆資料都有parsing 跟validating 的overhead
04/18 15:48, 29F
→
04/18 15:49, , 30F
xml殼+csv內容 皆大歡喜
04/18 15:49, 30F
→
04/18 15:49, , 31F
你就可以講, 機器買大台一點這句話了.
04/18 15:49, 31F
→
04/18 15:49, , 32F
meta data 跟 data storage 不是同一個層次的事情吧，不然我
04/18 15:49, 32F
→
04/18 15:49, , 33F
purpose 不同, 當然對錯誤的容認度不同
04/18 15:49, 33F
→
04/18 15:50, , 34F
乾脆拿 compass 跟 oracle db 比 search 速度，這樣可以證明
04/18 15:50, 34F
→
04/18 15:51, , 35F
db 的 overhead 比較大？ 不是這樣比的啊。:P
04/18 15:51, 35F
→
04/18 15:51, , 36F
你到底有沒有用過oracle?
04/18 15:51, 36F
→
04/18 15:51, , 37F
xml 你假設一個每筆資料都有 parsing 跟 validating 的前提
04/18 15:51, 37F
→
04/18 15:51, , 38F
沒用過, 去照我講的用一下, 看一下用xml 當作meta
04/18 15:51, 38F
→
04/18 15:52, , 39F
問題是就不是這樣的啊，你看 soap 、看 data api 看 kml
04/18 15:52, 39F
→
04/18 15:52, , 40F
的table 和用一般的方式的table, 誰比較慢.
04/18 15:52, 40F
→
04/18 15:52, , 41F
你不用跟我你看, FIX Protocol N 年前就有XML 的版本了
04/18 15:52, 41F
→
04/18 15:52, , 42F
這些使用上誰會去作 xsd 或其他的 validate 。:P
04/18 15:52, 42F
→
04/18 15:52, , 43F
再補個 RSS 。
04/18 15:52, 43F
→
04/18 15:52, , 44F
但始終不是哪麼多人用.
04/18 15:52, 44F
→
04/18 15:53, , 45F
RSS 還能再延伸出RSS2 等不同規格，這些都是 XML 應用案例，
04/18 15:53, 45F
→
04/18 15:53, , 46F
說 RSS 不多人用就是笑話了。
04/18 15:53, 46F
→
04/18 15:53, , 47F
XML 要是哪麼神勇, 早十年就該勇了.
04/18 15:53, 47F
→
04/18 15:54, , 48F
它不是設計來解決所有問題的，但是他的確有解決一些問題。
04/18 15:54, 48F
→
04/18 15:55, , 49F
沒說他不好, 但他就是不適合在大量資料的情況下使用.
04/18 15:55, 49F
→
04/18 15:55, , 50F
XML 慢慢有人用, 也是始於-->設定檔
04/18 15:55, 50F
→
04/18 15:56, , 51F
討論幾g等級以上大量資料的狀況下，基本上考慮壓縮議題，
04/18 15:56, 51F
→
04/18 15:56, , 52F
xml 是一定不合用的，這我也同意。
04/18 15:56, 52F
→
04/18 15:57, , 53F
不過 xml 在 RSS/Html 這種內容服務上，還是很有優勢。
04/18 15:57, 53F
→
04/18 15:58, , 54F
設定檔的部份他雖然有優點，但是現在設定檔也很難說好不好用
04/18 15:58, 54F
→
04/18 15:59, , 55F
只能說有很多選擇，不同平台支援不同parser程度不一，挑好用
04/18 15:59, 55F
→
04/18 15:59, , 56F
的用。像 yml , 像 json , 像 php 會用 php檔作config
04/18 15:59, 56F
→
04/18 16:00, , 57F
不用G為單位, 就MB 為單位的資料, 用XML來處理, 就慢
04/18 16:00, 57F
→
04/18 16:00, , 58F
到爆掉了. 要是用回以前的哪個又tree 又node 的.
04/18 16:00, 58F
→
04/18 16:00, , 59F
就更爆炸了.
04/18 16:00, 59F
→
04/18 16:00, , 60F
xml 在於設定檔的方面優勢主要是可以用 xsd ，但是 xsd 超難
04/18 16:00, 60F
推
04/18 16:01, , 61F
在x51 parse xml也有偷吃步的寫法，就當成fixed的格式
04/18 16:01, 61F
→
04/18 16:01, , 62F
寫，所以這部份是真的沒啥好說的。:P
04/18 16:01, 62F
→
04/18 16:01, , 63F
是說以「文字資料」來講， MB 算很多了。 :P
04/18 16:01, 63F
→
04/18 16:02, , 64F
fixed 格式, 還XML 會不會有點脫褲子放屁
04/18 16:02, 64F
推
04/18 16:07, , 65F
不會啊，可以丟到RSS，又可以給低階裝置使用
04/18 16:07, 65F
→
04/18 16:08, , 66F
雖然這樣的意義不大...
04/18 16:08, 66F
推
04/18 19:20, , 67F
巢狀結構用JSON個人覺得比用XML方便太多了
04/18 19:20, 67F
推
04/18 20:21, , 68F
Push Joan type
04/18 20:21, 68F
→
04/18 20:47, , 69F
你一定沒用過 JSON 或 YAML
04/18 20:47, 69F
→
04/18 20:48, , 70F
XML 真的被高估了
04/18 20:48, 70F
→
04/18 21:07, , 71F
用手機把Json打錯
04/18 21:07, 71F
推
04/19 00:00, , 72F
XML與Database作比較，張飛打岳飛？
04/19 00:00, 72F
→
04/19 00:02, , 73F
XML應該是跟json, yaml, messagepack等交換格式作比較吧
04/19 00:02, 73F
→
04/19 00:02, , 74F
怎麼會跟儲存方法作比較呢...
04/19 00:02, 74F
→
04/19 07:25, , 75F
很多人, 張飛跟岳飛是誰都不知道,還敢跳出來張飛打岳飛
04/19 07:25, 75F
推
04/21 11:30, , 76F
我現在都直接用LinQ存取自定的XML, 只能說比DB還輕鬆..
04/21 11:30, 76F
‣ 更多 oaz 的文章
文章代碼(AID): #1FZb-AZ4 (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 5 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 oaz 的文章
文章代碼(AID): #1FZb-AZ4 (Soft_Job)