Commentary

簡評五

怪怪设计论: 抽象无处不在

文章主要帶出以下幾點：

  1. Abstraction 做得好唔好唔係睇同現實有幾相似，係睇有冇抽象到事物嘅必要本質，抽象出黎嘅object易唔易被處理，唔係為用理論而抽象。
  2. 設計必需由數據表現形式出發，而唔係一D OO 嘅design pattern。
  3. 設計時，要係現實世界同電腦系統嘅抽象中平衡
    總括而言，軟件設計時，必需深入了解現實嘅問題，再抽象必要嘅本質，以Data為設計嘅藍圖。Implementation果時，唔可以過度重視現實世界嘅抽象而忽略電腦系統嘅抽象，因為implementation果時係要做大量嘅計算，如果個model唔適合計算，就會做成更多嘅問題。係設計對外嘅interface時，可以多運用OO嘅思想，令到其他人可以更易運用。

15 May 2018

為解決問題而design，而唔係死守 pattern同rules。

  • High level api model from 現實世界
    • as we need to solve business problem, simplify it by abstract business logic
  • Low level api model from 電腦系統 (abstract the system logic)
    • as we need to solve technical problem, we need to simplify the implementation details

21 Oct 2018

睇最後果5個point就得

非言语沟通技巧

眼神，衣着，肢體語言，聲調，準時同笑容都係溝通嘅一種。

19 May 2018

D point冇咩特別，但係值得重讀，去提醒自己

以下無需重讀

勿在沙浮筑高台, 再论社区风格

过去有前辈跟我说, 学好数学就要学好数学史, 学好哲学就要学好哲学史. 为什么? 因为这反映的是人类思维的变化与进步.

相當同意，歷史可以令我地明白有咩問題要解決，同埋當時嘅問題點樣解決，後人點樣improve 個solution。單睇solution唔能夠理解解決問題嘅思路。透過了解思維嘅轉變，可以對問題有更深入嘅了解。

15 May 2018

係學webpack 同 React-redux嘅時間，UMD 同 MVC 嘅演變歷史對我有好大嘅幫助，易上手好多。篇文係俾作者用黎發洩對討論區風氣嘅不滿，冇必要重讀。

闲谈: 就那么回事

當中對ORM嘅批評，可以係了解後再思考一下。

15 May 2018

文中對ORM嘅分析唔多，重點如下，唔洗重讀：

  • 簡單將database logic 包做Object，由於太過generate，未必solve到OO真正想solve嘅問題
  • ORM嘅能力較弱，當中logic比較複雜時，往往唔可以用ORM黎解決，都係要自己寫query

零碎: 学习, 技术明星, 面向对象

文中討論左好多Design Pattern點拆，D logic要分到幾細，又有好多唔同嘅situation，又有唔同嘅做法。大家都想用logic同數學去建立一D規則。我覺得當中有一個盲點，就係忽略左「人」E樣野。所謂 spaghetti code 都難免係主觀嘅，個重點可能唔係D logic有幾複雜，而係「人」點樣去接收，點樣去理解D logic。每個requirement都係特別，每個 business 嘅變化都唔同，根本好難去建立一D廣乏應用嘅規則。反而用一D寫文章，communication嘅concept去寫code，似乎會更易maintain。

15 May 2018

  • 追technology可以係好花時間，作用又唔大，應該將時間放係：
    • 深入鑽研，理解出黎一D更精煉嘅principle
    • 強化學習能力
  • 寫code嘅原則
    • 唔應該諗太長遠嘅野，個problem 更易solve
      • 諗太多reusability同extensibility好易會over engineering
    • 當一D sub-problem己經完成，用sub-problem嘅solution嘅interface去solve個大problem
      • Train abstraction嘅能力
      • 寫spec同pseudocode咁去練好似仲更加有效
    • Encapsulate左唔變嘅野，剩返D野係成日會變嘅野，比起要直接封裝changes容易得多
    • 拆出黎嘅sub problem大小要適中
      • 更易identify patterns
      • 同architecture嘅layering 差唔多concept

回帖整理: 论团队中的设计工作

个人水平提高了, 带领的团队质量反而变差了. 但是很多人的认识方法是, 那是因为我还做的不够好. 其实不是这样的, 我觉得我们要反思过去快乐的日子的合理性, 并且承认它. 现在我体会到, 其实我现在做的这种框架式的, 创新型的工作, 如果想提高效率, 必须所有人都具有相当的水平, 并且愿意下力气. 任何一种过程方法, 都解决不了我的难题. 我觉得作为技术组织, 总有一天会进行更高层次的提升才能活, 而不被淘汰. 那时候, 你的团队, 如果都是人肉代码生成器的话, 他们跟的上吗?

團隊平均能力好重要。寫code同係工廠做product唔同，好難做QA。寫code冇得話跟住example copy，要經過思考，對人嘅 dependency 好大。如果條 team 能力跟唔上，無論個product design得幾好，個plan draft得幾好，都係execute唔到。

19 May 2018

唔洗重讀，但係cap出黎嘅金句值得一再反思

三问TDD: 单元测试总是好的吗？

最初的时候我总觉得TDD最核心的是T，Test。后来才开始明白，它最核心的其实是D，Drive（我非常认同，这就是我说的测试之外的东西）。你可以把测试写的 很弱，但你一定要在此影响下把代码重构的很好。

一語道破我個盲點，冇test唔緊要，最緊要D code structure靚，testable。Testable 嘅 code 多數條理分明，易讀易明，自然少bug，易maintain。重點係code structure，而唔係有冇test，為 test 而 test 係冇咩謂。

19 May 2018

最近行左一陣TDD，認同test唔係重點，個code structure先係最重要

  • 唔洗每一段code都要test
  • 就算有D位唔洗寫test，但係都一定要易set up test
  • 由於要寫到D code testable，會引起好多module同design上嘅反思，係一個好好嘅feedback
  • Code coverage唔係所有野

闲言碎语

原來.Net有樣野叫LINQ，D syntax同sql statement builder 有D似。我睇過js version嘅LINQ npm，但係好似唔係database layer，而係果好似underscore咁，process data嘅library。

19 May 2018

係粗略了解hexagonal architecture之後，發現LINQ 同 ORM 唔係同一個layer嘅野，唔可以直接比較。

  • LINQ 比較似一個syntax sugar，可以俾你更加易去寫query，唔洗下下hardcode query string
  • ORM 就係一個Database layer嘅 abstraction

我现在有一些工具类，我应该不应该做自己的框架？

如果有唔可以拋棄嘅assumption，咁就可以design做一個framework，否則應該design做一個library。

15 May 2018

  • Framework：易setup，生態圈多數會有多D tools，可以增加productivity
  • Library：彈性，易migrate同upgrade，如果design得好，component reusability仲大

编码,charset,乱码,unicode,utf-8与net简单释义 编码,charset,乱码,unicode,utf-8与net简单释义(续)

係variable length嘅string encoding，係用prefix決定之後讀幾多多個byte。
用一個no width space (0xFEFF) 去indicate big endian 定係 small endian

19 May 2018

唔洗重睇，What every JavaScript developer should know about Unicode 寫得更好。