平常人都能掌握的Programming 原則
2019-01-29
大家會定時整理自己電腦中的文件嗎?大家看軟件工程師工作時,往往會發現他們的檔案總是井井有條,資料有條不紊地排列。難道學習軟件工程能使人變得 整齊?原因其實在於軟件工程師經常需要處理大量檔案及資料,因此發展出一套完整的工程原則(Engineering Practice),久而久之,就掌握了資料管理 的要訣。而如果平常人也掌握了這些工程原則,在日常電腦使用,其實也有不少好處。
軟件工程原則有許多,一些編程界奉若聖經的名作例如Pragmatic Programmer 或是Clean Coder 都舉了許多有用的例子,然而由於這些書籍以軟件工程師為讀者,對本身無編程根底的大眾,太抽象複雜。
因此,本文將會由以下四個工程原則開始,方便大家理解:
- 單一資訊來源 (Single Source of Truth)
- 緊跟慣例 (Stick to Convention)
- 分而治之 (Divide and Conquer)
- 簡潔為上 (Keep it simple stupid)
單一資訊來源
單一資訊來源(Single Source of Truth)乍聽好像很複雜,其實原理很簡單。也就是資料應該遵從以下原則:
所有資料,應以一個特定來源為準,目的在於避免重覆數據。其餘所有數值,都應由該單一資訊來源所計算或讀取。
舉一簡單例子,假設公司的產品A需要一份季度用戶報告,該季度用戶報告不應該需要額外儲存,而應該用每月數據、每週數據甚至乎每日數據所計算,使用Microsoft Excel的話,也就是每日數據應該存在一張Sheet之內,而季度數據則是利用每日數據,再用Formula計算而成。如此的話,縱然收集的數據不一定百分百準確,季度報戶與每日數據卻是始終一致。任何更改必然導致兩邊同時更改,大大減少錯誤的可能性。
另一個經典的單一資訊來源的例子,就是大家常用的Google Login或Facebook Login。此類Login可稱為Single Sign On(SSO)。在使用SSO之前,大家需要使用許多個不同的用戶名及密碼,變相需要同時管理大量的密碼,有時忘了密碼還要重置,使用了SSO之後,大家只要使用一個Google Account,就可以在很多不同的網站登入,省卻了麻煩的用戶管理。近來開始流行的密碼管理員(Password manager)也是同一原理,將所有密碼都存放到密碼管理員
之中,使用時只需要輸入密碼管理員本身的密碼,就能夠讀取不同的密碼了。LastPass
及Keepass
都是密碼管理員的例子。
單一資訊來源與另一原則不重覆累贅(Don't Repeat yourself)相類似,為了令本文亦符合此原則,不贅。
緊跟慣例
緊跟慣例算是另一個易學難精的工程原則。所謂緊跟慣例,其實就是以下的原理:
不論是資料的內容、格式、命名等,都需要制定一個慣例(Convention),以後的資料都要跟據慣例去儲存。
其中一個經常被忽略的慣例,就是檔案的命名。平常大家改名的時候,往往會使用一些很短的命字,例如report.doc
、upload file.img
等名字,此
類名字簡單是簡單,但是名字太短,太無代表性,當檔案一多,就變得無所適從。因此,檔案名除了解釋該檔案的用途之外,最好還有附加的資訊,例如時間
、部門、負責人等。試比較以下兩個命名,那一個比較有代表性,比較不易重覆呢?
Tecky_Academy_20190129_report.doc # vs report.doc
上面的名字較長,資訊也遠比下面的命名要多。而日期20190129
令檔案名變得唯一(unique),因此不可能出現重檔名的問題。
要更進一步,大家可以考慮製定一套編碼,編碼裏面就已經包含了大多數需要的資訊。例如以下的檔名,就包含了公司、日期、版本、用途等資訊。
Tecky_Academy_2019_01_29_v1_sales_report.doc
慣例當然不只檔名,所有行、列都應該有自己的命名原則,使後來者能輕易就能學會使用。
分而治之
分而治之概念上很簡單,實行卻不容易。分而治之的原理就如下:
嘗試解決大的問題,如果問題太大改變不了,就將問題拆小,再嘗試解決,還是解決不了,就再重覆拆細,直至問題足夠簡單,就能解決了。
Source:https://www.tutorialspoint.com/data_structures_algorithms/divide_and_conquer.htm
例子就是如果數據太多,就應該將數據拆小至數個部份,直至能夠解決為止。分而治之的好處,在於很多時候當數量多到了一個地步,就會出現了數量少 時不會撞見的問題,例如將一個程式放到高負載的情況,就可能出現競爭狀態(Race Condition),此類問題,都是量少時不會遇到,將數據拆小,自然就 減少了此類問題。
除了拆小數據,將一個複雜問題按步驟拆開也是分而治之的例子,例如要使用Google Cloud Vision API作圖像辨識好像很困難,將整個問題拆為以下數步驟,整個問題就非常清晰:
- 建立一個簡單用戶界面的網頁,讓用戶可以選擇上載檔案
- 到Google Cloud Platform申請帳戶,啟用Cloud Vision API
- 生成使用Cloud Vision API的Access key
- 在網頁的Javascript裏讀取上載之檔案,然後發出一個HTTP請求至Google
- 得到從Google的HTTP答覆,將結果顯示於網站之中
每一個步驟可以組成整個軟件,而每一個步驟要做的事都很明確,因此將整個問題拆小,就將難度降低了。
簡潔為上
簡潔的重要性,相信大家都能夠理解,目的在於將我們的資料以最簡單的方法表達,以避免徒增不必要的複雜 性。喬布斯曾有一名言
Simplicity is the ultimate sophistication
大家儲存資料、管理數據時,應時時追求將數據以簡單的方法表達。如果無須使用Microsoft Excel本身功能
的話,使用.csv
檔案(Comma Separated file)比使用.xls
要好,因為使用普通的檔案編輯器亦能閱讀,無需
試算表軟件。減低了不必要的依賴性(Dependency)。
後話
其實細心觀察,大概大家已經察覺到簡潔乃是大部份原則的基本信念,將事物搞得愈來愈複雜,絕不是軟件工程師 的目的。每一個工程原則出現,都是為了令事情變得更簡單、更易管理,如能夠時時活用此等原則,管理資料就無須煩惱 了。
留言
閱讀更多
好Programmer是怎樣煉成的?
2018-12-20
有一個大部份僱主都面對的難題,在芸芸履歷之中,如何萬中挑一,找到好programmer呢?聘請程式設計師很難,不像其他行業,打開 履歷就一目了然:有時履歷上滿滿証書的,其實連FizzBuzz也寫不了;有時看起來像個fresh graduate的,卻又有無限潛力。 如果你是一個要聘請程式設計師的僱主,你應該如何是好呢?
Online Course不能承受之輕
2019-01-20
Online course已成為學習的新潮流,尤其是學習科技類知識,大多數人都是上網於**大規模開放線上課堂(Massive Open Online Courses)** 選擇希望學習的課程。現時較熱門的平台有`Coursera`、 `Udemy`、 `Edx`等。 完全免費的例子例如`MIT Open courseware`亦是大行其道。 網上課程的普及,令不少人發出感嘆:「讀大學所為何?讀網上課程就好了。」然而,以網上課程學習,與真人教授課堂相比,有一道難以逾越的 圍牆:網上課程難以協助學習者建立編程所需的心智模型(Mental Model)。
如何對治思維籠統
2019-01-23
以下情況相信大家似曾相識: > A公司希望完成一個專案,將專案外判給一間軟件開發公司B開發,專案開始後,總發覺B公司不太理解要求,製成品也與要求相去甚遠,與B公司的 > 程式設計師多次開會亦結果不彰,最終專案「爛尾」收場,A公司不得已又將專案再外判給C公司,同一問題似乎又再上演... 探究原因,何解此類問題經常出現?原因往往在於A公司的相關負責人本身沒有編程背景,因此給出的要求相當籠統,B公 司的程式設計師亦不理解A公司期望,因此導致專案最終失敗。 讀到這裏,大家可能會嚷道:「A公司的負責人當然沒有編程背景啦,不然A公司自己做就好了」其實問題重點不在於A公司本身是否有編程的專才,而在於產品 負責人(Product Owner)與程式設計師溝通良好與否,即使A公司本身有編程Team,如果溝通不良,專案失敗是不會改變的。要討論溝通良好與否,先 要理解平常人的思維方式,與程式設計師的思維方式,往往差別甚大。
從「同朕check下」談中文科技詞彙
2019-03-03
本站文章以中文寫作,本來為方便香港讀者,在芸芸的英文文章之中,有一個另類選擇。出乎意料之外,我們近日發現多了不少台灣讀者閱讀本站文章,細想一下,大概是因為 筆者寫文好用中文科技詞𢑥,如型別推論(Type Inference)、機器學習(Machine Learning)、超文本傳輸協定(HTTP)等,台灣的軟件工程師搜尋相關的詞語,自然容易找尋到本站。然而,中文的科技詞𢑥,對不少香港軟件工程師而言,其實並不常用,那是甚麼驅使筆者會堅持使用這些中文科技詞𢑥呢?是愛?還是責任呢?
專家級新手
2019-03-19
今次要介紹的,是一個非常常見之現象,不論你是學寫程式、學做甜品、學寫文章,又或是練習球技、體能訓練等,都會經常窺見其身影。 想像一下:你的朋友問你:「你的駕駛技巧好嗎?比較起其他司機來說如何?」如果你本身有駕駛執照,但是不常常駕車,大概你會回答:「中規中矩吧,平均水平」;經常駕駛的人,因為經驗豐富,會覺得自己是中上甚至良好之水平。然而,這個想法人人都有,卻與現實完全相悖:因為任何羣體之中,必然有一半個體在中位數(Median)以下,而一項經典的調查發現,八成的司機都認為自己的駕駛水平在平均之上,這明顯代表在駕駛技術的世界上,大部份人都有自視過高的問題,也代表其實大多數司機,無法準確判斷駕駛技術之高下。