身為非技術人員的自卑情懷

在資訊領域做久，肯定會遇上「研發人瞧不起行銷，行銷看不上研發」的鳥事。舉個實際例子來講，以前合作過的工程師，請他做一個站內資料檢索的功能，可以依照輸入的關鍵字把站內相關內容拉出來，並且依照我們希望的介面呈現在眼前。大概需求提出到實現，差不多三天的時間。

後來，類似的狀況再次碰到，只是物換星移，人不同了。開了同樣需求，但這次卻聽到工程師說：「我們至少要兩個月的時間才行。」當下一時無法理解。記憶中同樣、相似、好像的功能，一個三天一個六十天。我不懂發生什麼事情，工程師也貌似懶得解釋，心中存有巨大疑惑，可是始終沒有解答。

幾年過後，陸陸續續自學程式，開始去研究Framework，瞭解資料庫結構，試著自己去摸IIS、ODBC等。雖說完全沒摸透，也沒實際寫出什麼程式，倒也解了心頭幾個疑惑。以前做三天的工程師，想起我在Php Admin裡面，我一張又一張資料表去檢查，發現我們將所有大部分的次要資料，跟主要資料全給存在一起。

再舉個例子，一般來說，會員資料包含了Primary Key、ID、Name、Gender、Date、Time，另外一張表會是密碼表，通常都會特別加密，這兩張資料表我稱作主要資料。次要資料則是會員可以用我們站上的系統發文，與留言，因此正常來說可能會有一張表叫做文章內容資料表，這張表上主要會留下Primary ID、Title、Content、time、Edit time、Comment ID等。

主要資料與次要資料會分開來，因為次要資料可能一張表上，對應一個使用者就會存上很多資料。但是，當時我透過Php Admin進去看卻發現所有的資料，全部寫張一張表上。所有我們想得到的資料全寫在一張表上，也因此，光是要開啟會員資料庫時，總是耗時許久。但，對工程師的好處是：「他只要查詢一張表，對該表下指令去要出他的資料，用程式把找到符合的資料透過API顯示再讓前端接即可。」

至於兩個月的又做了什麼？因為研究了Framework，發現工程師們為了不想做太多重複工作，透過一些架構式的開發，可以在日後修改同樣「功能（程式）」時，不用一個頁面一個頁面回頭去修理面的程式碼，而是從架構端下手。但這跟搜尋的關係又在哪裡？因為很多頁面都會放上搜尋功能，搜尋又有分一般搜尋跟進階搜尋，不同按鈕進入的情境不同，但要呈現的結果要一致，所以得先從架構面去思考好這功能在日後開發上怎麼維護會比較方便。

再者是，該工程師想得很多，他認為我們上千萬筆資料，一定會有些資料常常被搜尋、有些資料不常被搜尋，然後有些介於中間的資料會偶爾被搜尋，因此要設計一套方法來有效產出結果的方法。例如多設計一張常用資料檢索表，可以針對常被搜尋到的資料先額外放一曲，然後依照一定規則將到達某些條件的資料可以移進去。大致上他做了很多這類邏輯運算的工作，確保每筆資料都可以在0.3秒以內出現，而且又考量到同時大量搜尋，怎麼確保工作效能都符合原先預期。

三天跟六十天的架構與做法差了非常多，我從原本大外行，根本搞不清楚兩者之間的關係，靠著自學的方式，終於理解為什麼令我不可思議的反應，卻在執行上有著天差地遠的區別。如果我從未自己下去學習，從沒有自己親眼去看資料庫的結構，從不去了解設計資料架構與效能之間的關係，我可能一輩子都不會理解為什麼三天的工程師那麼優秀，而六十天的工程師可能只是想找理由偷懶。但，這就是不專業以及不入行的代價，不懂就會造成很多認知上的誤解與落差。

回到我想談的主題，空拍機。

教授、朋友、廠商都跟我說：「你可以不用自己做啊！你找別人幫你做就好了！有很多人可以幫你！」我一直想做IoT的題目，始終想嘗試軟硬整合並且透過自己雙手去驗證一些事情，同時，將腦海中有過的無數想法，藉由自己的技術與知識來實現，而不是永遠只當個局外人，用一個外人的觀點來看待我自身一知半解的的事物，尤其對我未來人生而言，還有很多想做的事情，不親自彎下腰來弄髒手、弄破皮，或許我還是那個看待三天與六十天工程師的外行爛行銷。

從上週組裝開始，遇到機板燒掉、電路焊壞、電池膨脹、馬達爆炸、驅動程式失效、軟體偵測不到等各式各樣問題，這才讓我慢慢理解製作過程中，應該要先想清楚的流程與順序，還有要備妥的環境跟相關器材與物料。前前後後至少反覆跑了電子材料行快十趟有，每次做到一半發現少了什麼，才又跑去買，買回來再做又發現出問題，就這樣一點一滴累積知識與經驗，感覺上，我從幾個禮拜前好像看著外星科技一樣的東西，到現在給我同樣的材料與零件，我有把握可以在半天內就組出一台空拍機，只不過就我自己的進度，應該本週末就可以順利讓空拍機飛起來，甚至多一點是開始拍照。

人生就是不斷累積，失敗了跌倒，站起來就是。

#空拍機製作日誌