分享

Python Taiwan讀書會_13_UML

頭腦很清楚的工程師,腦中當然會有架構,但每次的案子,不會只有一個人在做,所以需要把概念寫出來,也就是用UML當作軟體設計圖,大家才能一起做,傳統公司會用flow chart,也是努力釐清這千頭萬緒,不過,王大哥將UML視為軟體專案溝通的共同語言,他明言軟體業並沒有規定一定要用UML,但現在的主流語言都是物件導向的語言,適合用UML當作一個共同語言。
想也知道在上週六的讀書會之前,我並不知道世界上存在著UML這種東西,但冥冥之中我知道,工程師們一定有某些通關密語,拿來做共通的定義、層層分工。王大哥坦言,UML實作上常會有很大的困難,以其中一個常用的Use Case Diagram為例,列舉式的需求也還是得花時間寫,不如用UML寫,他曾推廣過但是失敗,頗感嘆台灣的問題在於什麼都趕著做,若是做國外或open source的project,比較能夠慢慢做,慢慢把UML寫好,一個3個月的案子,大家無法花2.5個月把UML理清楚(我看光老闆這關就頂不住啊,3個月的案子到2個月過了還交不出點東西來),在對coding很熟練的工程師看來,coding不是最困難的事,難的是把各個場景想週全,煩的是之前沒想清楚但日後絕不會少還、填不完的洞、難讀難改難維護的code。
多數公司無法接受,3個月的案子,其中要花2.5個月寫UML,但能做到這樣的話,後續的修改和維護可以變得很少。(UML也是一種情懷啊)
講義
UML 簡介
讀書會中講到台灣專門講UML的Teddy老師
UML Class Diagram小抄
會後補充
【UML】Class Diagram 類別圖 (下):Relationships 關係
*看來class的關係很重要!
計劃趕不上變化的日子仍在繼續,王大哥推薦了一個2010年Miško Hevery(應該是某個很厲害的人物)的影片給我們當課後補充,在Telegram討論起測試,補充了下方的影片聯結,王大哥在對話中有提到的觀念大致是這樣:
「寫code時同時要想到測試,才能寫出『可測試』的code,也就是說,如果 unit test 很難寫,就更容易有盲點,未來 bugs 就很多。程式好不好測、可不可測,跟用的語言、或用的 frameworks都有關,以舉例 web app ,用 React + Rudex 寫,它會讓你所有 web app 的操作,都對應到一個 function(pure functional programming,最容易測試)...」
How to Write Clean, Testable Code
我硬著頭皮看這段近十年前的講座影片,把聽起來可能重要的點記一下,怕的是豬嚼牡丹啊!
有關測試的譬喻:測試不是撒糖霜,而是在做蛋糕的過程中就需要放糖。
測試不應該最後才做,因為製造bug的人感覺不到有bug的痛苦;而嘗試自動化,以為買某些軟體來測試,但實際上也多半不能解決問題。
能夠測試的code,重點是這段code的架構,不是這段code的功能,即使不知道這段code是用來做什麼,但應該看架構就能知道如何寫測試。
開始寫測試前,第一件事是找keyword(state key),第二件是看constructor(藉著生成certificate)。問「會需要什麼」,而不是開始搜尋。
  • 要看起來輕鬆是一件非常不容易的事,身處許多老手之中的新手,許多不言而喻的東西(例如環境設定),有時候光是找到合適的工具就是一件很棘手的事。
  • 「假如我解決這個問題,一切都會順利」只是種錯覺,先跑三個月吧!
  • 設計與測試緊密相連,甚至在寫下第一行程式碼時就知道要如何寫測試。
  • 看似不一樣的問題,往往都是if語句和循環的問題,正是需要做單元測試的地方。
  • 裡面反覆提到Demeter Law。(查一下發現有句話一直重複出現:迪米特法則的一個英文解釋是:Only talk to your immediate friends.(只與直接朋友溝通。如果是陌生的朋友,就透過第三方來傳話。))
  • 自動化不是變魔術。
  • 看起來很像重點的兩張投影片—
  •  
  •  
  • 本週開始了另一個讀書會、參加了一個meetup的線上分享auto ML。目前有三個讀書會,Python Taiwan這一階段到11月結束,之後王大哥想講什麼我應該都還是會跟著聽,Python from Zero上週六邁入第10次讀書會,本週二開始了「從Python到Tensorflow」讀書會,表定要讀三本書,大概會讀到明年四月,書單發出來大家得認領報告章節,我也在雙十一的混亂中買了書,省了一個便當錢。(這是什麼歐巴桑的語氣)
  • 看著自己Google Calendar上多采多姿的夜生活(天黑了才進行的讀書會不就是某種夜生活嗎),我想這也是種報復性消費,回想起學生時代,我從來沒參加過讀書會或共讀團體,研究所推甄上了也沒經過那段水深火熱的備考期間,又愛嫌人家讀書會進度慢或是講不到重點,自己看還比較快,然後直接分享筆記給同學就完工了,而最近的讀書會中,在陌生的領域中,我成為接受幫助比較多的人,身段放下得很快,但怕的是腦筋轉不快,就燒掉了。
繼續燒腦寫Python from Zero的作業,這週作業內容難到只有兩個牛人同學交後大家一片靜默,我原想看著同學的答案跑看看,邊照著寫邊想自己的資料裡如何替換,要抄也要先看得懂吧,卻沒想到,連抄錯了,都看不出哪抄錯,跑出google不能解錯的錯誤訊息,只好變換策略,開始用各式各樣的問法問Google,後來我想Google也煩了,就吐出一組簡潔的解答,跑時雖然沒有錯誤訊息,卻一直給我落落長的訊息與聯結,意思大約是叫我用別的寫法來達到我想要的功能,我把這組解答和牛人同學的比較一下,的確是牛人同學用上課提過的函數比較有擴充性,學長教的是對的,只是我還不太會用。(面壁)
週四下午參加了一個線上分享auto ML,是TIBCO這家公司介紹auto ML。auto ML是我前兩週在幫公司找可接價格預測模型時,接觸這些公司的對話中提到的,某家公司提到他們是用auto ML來做,結果我的腦波傳到Google上,Google便向我推薦了Women Who Code Taipei辦的線上講座,請到TIBCO的資料科學家來介紹。我發現要使用AI領域中的演算法,可能已經不用會寫大把大把的程式了,但有寫程式的概念總還是好的,畢竟工具是一步一步地進化,無法瞬間與人類意念結合,而機器與人類也是朝著對方走去。
TIBCO的auto ML畫面看起來與前陣子接觸過的UiPath頗相似,從演示中看到有很多參數的調整介面與excel和UiPath都像,只是各自任務或有不同,在台灣人工智慧學校的課程結束後,近三個月的學習使我感到不用在當下糾結著要趕快學會什麼(看著像寫不出作業的藉口),或是趕快拿來用(寫作業就是在用了,現在還無法做到世界和平),而是充分利用時間地廣泛了解,我大致可以體認到有些東西是基礎觀念,可能在沒被外星人統治之前都會是電腦科學的基礎,而有些東西會隨著時間快速變化,只不過大家還是得再忍受我還會有一段時間持續這樣,遇到什麼說什麼的分享,就當成是這個系列獨特的魅力吧!
分類:學習

評論
上一篇
  • Python Taiwan讀書會_14__Design Patterns in Python
  • 下一篇
  • 更多文章
    載入中... 沒有更多了