Commentary

簡評六

當主管卻不懂交辦，當心「猴子」爬上身

文章將團隊成員分為五種不同層次，最低層次係要等人俾指示，最高就係可以獨立行動，間中做例行報告。要令員工可以獨立行動，需要時間累積信任。

文中仲提及一D指派工作嘅技巧:

  • 要清楚指出工作內容
  • 可運用數字明確指出目標，促進員工思考
  • 盡力說動部屬願意做不樂意的事
    • 最好當然係每個人都做樂意做嘅野。但萬一冇人肯做，都要靠員工去補位
  • 用正確既方法去指派工作，文中提出4種
    1. 直接告訴我你要我做什麼
    2. 我希望你先考慮我的意見，再決定我要做什麼
      • 員工可能想用新方法去解決問題
    3. 我想自己決定要做什麼
      • 員工唔需要監督，係開波之前要搞清楚目標同方向
    4. 大家共同討論、決定之後，我就很樂意去做

仲有三個指派工作嘅大忌

  1. 指派太多工作
  2. 有多過一個人落order
    • 會唔知做邊個task先，影響團隊信任
  3. 把最困難的事，交給最有能力的人
    • 最重要都係cost and benefit，做最有value嘅task

Choose design over architecture

  • Conventional wisdom often encourages engineers to start with a big architectural overview, but this will introduce technical debt
    • The overview make the service complex. The complexity in one service can take down the whole project
      • I guess it is because the service is an essential part of the whole system. All features will depends on the complex services
    • Architectural plans will push the team forward water fall model
      • I guess it is because the product can only be deployed after all infrastructure is ready
  • Focusing on user experience design and software design can help avoid technical debt.
    • Start from small user story
      • Even a small story can involve a lot of effort for the engineers, as there are no infrastructure can be reuse.
      • The set of stories will help engineers figure out what infrastructure is needed and the priorities.
    • After we have the requirements provided by user stories, we can break the features into modules and organize modules into services.
      • SOLID principle in OOP can help us design the system
  • Optimize for change
    • Optimized code lead to an increase in defects and reduced velocity.
      • Rule of 3, consider to reuse code if it appear three times

Summary

  • Get the infrastructure’s requirement using product designer’s mindset
  • Organize the feature and model using architect mindset

21 May 2018

After having 2 years of working experience, I can write a review with better structure:

This article suggest procedures for architectural planning

  1. Starting from user stories and user experience
    • Never plan infrastructure before collect user & feature requirements
  2. Organize features for architectural planning
    • Plan for quick deployment, try to release the feature as soon as possible
    • Design independence and flexibility modules for a group of related features
    • Always design for changes, not design for reusability
  3. Structure the code
    • SOLID
    • Don’t afraid to refactor the code

Why we should not have architectural planning before collecting user requirement?

  • Without requirements, the plan is easily over-engineered
  • If the modules are too complex, it takes a long time to build one module
    • The team is shifted to waterfall development

Optimize for change, but don’t optimize in advance

22 Dec 2018

係睇左「搞笑談軟工」，對Agile有多左了解之後，先至明白E篇文係想講咩

Avoid big architectural plans when start the project

係一開波果時，由於咩都冇，難免需要architectural plans，但係要控制住自己，唔好plan得太多。如果唔係，就會變成左waterfall。
例如個feature可以唔洗有async job，就唔好plan worker queue；可以唔洗cache，就唔好plan cache invalidation；可以唔洗scale，就好plan load balancer。記住係plan for feature，用最簡單嘅system去提供到個feature就得

如果係feature要求好複雜嘅architecture咁點算？無計，只可以照做，但係要問一個問題。究竟個feature係咪真係最重要，最優先做？應該先㨂minimum workable product必需嘅feature黎開波，咁做出黎嘅product就係最簡單，但係又最有value

以下無需重讀

小問題，大麻煩

做錯一D細嘅決定係短期內冇咩影響，但細嘅錯誤會慢慢累積成大嘅錯誤，最後做成technique debt。

例如之前我落左係<ul>同<ol>嘅CSS落左一個CSS reset, 搞到post content D list冇曬style。最後係post content D CSS 做左個patch。但係就有其他engineer，因為個patch override左D style，搞到個page爛左。一個簡單嘅錯誤係三日內係唔同嘅地方做成2個bug，最後變成大問題。

文中提出用pair programming 同 code review 去盡早fix左D小問題，但最終都係要有資深嘅engineer去identify到個問題。

21 May 2018

篇文冇必要重讀。
不過要經常提醒自己

如果原本的基礎專業知識不足，這些一連串的「弱品質自行判斷」將很可能導致技術債

咖啡館師傅的啟示，如何正確跟他人學東西？

好多野都係context dependent，要睇情況同時機。所以學野唔係要學人地嘅經驗，唔係要學硬性嘅規則，而係學背後的邏輯、方法。咁先可以因應唔同嘅情況調整。

21 May 2018

從其他人嘅經驗學習嘅時候，要思考人地點解作出E個決定，同埋solution所在嘅context。運用人地嘅做法時，要觀察自己嘅經驗，隨時調整同學習。

Read This Google Email About Time Management Strategy

The animation in video is impressive. It contains a few points:

  • Meeting can have fewer people
  • Remove unnecessary meeting
  • Don’t put all meeting on Friday, because the energy level is low

21 May 2018

Plan base on your energy level

  • Low energy level
    • Goal setting, organize, planning
    • Do open-end work
    • Relationship building
  • Middle energy level
    • Meeting for consensus
  • High energy level
    • Tackle difficult problem
    • Brainstorm
      • Write techical spec
    • Implement

知识漩涡

太多新technology，好難追，但好多時都係大同小異。重點係理解可以通用嘅重點。文中提及分為兩種，第一種係零碎嘅資料，第二種係幫助提升理解力。後者往往比前者重要，但係要用好多心力先可以吸收。

知識框架就係一種幫助理解資料嘅知識，而入邊specific 嘅 domain knowledge 就係資料。學野果時應嘅先廣後深，避免鑽得太深，明白整體之後，先揀得著最多嘅野，專心去學。如果只係不停去追新tech，冇深入了解，去到最後只係知左一堆好快outdate嘅資料，而唔係知識。

小結：

  • 冇可能學曬所有野
  • 要先了解成個知識體系，避免鑽得太深
  • 揀最有價值嘅野深入研究
  • 對於得意但同自己發展方向冇關嘅野放係低D嘅priority，要識得放棄

21 May 2018

Summary is good enough, don’t need to re-read
補充一個point

  • 要主動同深度閱讀經典

保持专注，保持简单。

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

如果有唔可以拋棄嘅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 寫得更好。

十年磨一剑—序

引入功能強勁嘅library都可以係問題。當一個library好多功能，咁D code一定唔會簡單得去邊。萬一個library出左問題，就要花大量時間去睇code同doc。如果大部份功能都係冇use case嘅話，倒不如用一個功能簡單嘅library，甚至自己寫好過。

金句一：

在面对这些问题时，人们更多的时候是在寻找一个框架，即使这个框架大到你只想要一个轮子而不得不接收它的整个车子，你依然不会怀疑为什么这样做，当你终于被这个车子的其它零部件影响到你这个小小的轮子行驶，而不得不到处google爬文或分析源码，在弄得焦头烂额，筋疲力尽之时，你心里又会不会发出：这个。。。 能不能简单点的抱怨？

金句二：

对于一个优秀的系统架构师来说，他除了要为应对变化而施展他的艺术创作才华，很多时候他也必须分清哪些是需要变化的，哪些是可以变化的，哪些是不会变化。而要认清这些不同的变化，首先就要理解问题域的本质，例如缓存处理，为什么要缓存处理，它有什么用，在系统中处于什么样的地位，和其它模块的接口在哪里？哪些是缓存可变的，哪些是缓存不会变的，当变化时在哪里处理这个变化，对系统的其它模块的影响在哪里？只有认清这些，才会在引入某个模块时做到心中有数，避开它的负面影响。

15 May 2018

An example of Library > Framework

  • Framework learning curve高
  • Framework同library都可以有bug，要解決唯有幫人地maintain，maintain library係易過framework
    Design for changes, domain knowledge taking a important role on identifying chanages

一个时代的终结

係科技嘅時代，E樣野經常發生，不過科技暫時唔可以完全取代所有工作。最重要identify左邊D係機械性嘅重覆工作，邊D係有價值嘅工作。

順帶一提，code generator好難去取代programmer。主要係maintenance嘅問題。

15 May 2018

文中有D point，不過我唔係完全認同，無必要重睇，重點如下

  • library功能幾完整都好，好難同business perfect match，再加上requirements always change，實需要programmer去做野。
  • 只識用library，唔知佢地點運作，唔係一個好嘅programmer
    • 好奇心係重要嘅特質