前言

這是一篇關於工作半年來的微小心得,發現在過去的日子裡自己曾經忽略的軟體工程部分,對於一份好的軟體有多麽重要,替自己記錄下這一份心得,並期許未來的自己可以更加進步,學習更多軟體工程實務,讓自己成為一位良好的軟體工程師。

學習程式設計的初期

回想起大學時期,當我提及未來想從事軟體開發(Web、App… 等等應用程式開發)相關的工作時,學校老師們總會跟我說軟體開發是一種容易被取代的工作,他的技術門檻相對比較低。(*註1)

這樣的想法一直存在於我的腦袋當中,但是我的大學專題依然做了Android App,而研究所時,也繼續於行雲者研發基地當中持續的開發Web 並學習軟體開發的框架與技術,或許,這一直都是我寫軟體的初衷吧!

回想起為何要寫程式,就是知道眼前一隻又一隻的軟體是從點點滴滴累計而成,直到有一天有能力寫出第一個GUI程式時,那份感動至今仍記憶猶新,對我來說,似乎是一個與使用者互動的軟體,才能讓我激起開發的熱情。

這些年,我一直誤會的軟體開發

過去的各個專案當中,我總是單純的把客戶需求轉換成功能性需求並實作,總是探索著如何使用框架,快速地撰寫符合需求的產品出來,能夠按時完成產品,是我以前對於軟體開發的粗淺想法。

開發網站時,我想著CodeIgniter 與Bootstrap 怎麼使用,Django 與 Rails 如何快速地替我打造一個網站,想著JQuery 如此方便是不是可以取代JavaScript,開發iOS時,我想著如何串API、使用TableView、使用Core Data…這些與「技術」相關的問題,是在行雲者時期,我最加以著墨的部分。

但是,我不禁反思,當我學會了足夠讓我可以完成需求的「技術」時,我還能學些什麼,難道就只有這樣嗎?這不就與老師們說的相同,只要有一位會寫程式的人,他就可以學會這些技術,做你能做的工作。

原來,軟體開發還有這些眉角

在我進入公司後,我第一個感到困惑的名詞是Sprint ,從而得知原來我們的開發方式叫做Scrum(*註2),進而得知原來有敏捷開發方法,深入瞭解後,才知道敏捷開發方法通常會搭配持續整合(Continuous integration,簡稱CI)、單元測試(Unit test)、自動化測試(Test automation)、重構(Refactoring)…等技巧,來維持在高產出的狀態下的產品品質。

在這半年來閱讀大量過去同事所產出的程式碼時,總是會看到一些在功能不斷增加的狀況下,程式碼開始出現重複的狀況,無論是複製貼上,或者是參考版本重新撰寫一份,就因為兩份程式碼(或以上)是類似的功能而不加以思索如何進行抽象化,或是套用設計模式來移除程式碼的重複性。

如此一來,程式碼在越來越龐大的狀態底下,將會越來越難以維護,於是我開始探索如何改善軟體品質達,讓程式碼光是看起來就更乾淨、容易維護,於是重構是我目前最多著墨的部分。

舉個簡單的例子,過去我們寫過多少條件判斷式呢?當我們看到條件式過多的if-else 或是switch-case 時,是否想過透過多型(Polymorphism) 來移除這些判斷式?

其實軟體開發還有更多得學

其實一開始會想學習重構,是為了想要導入單元測試,但因為程式碼當中,一個method 做的事情太過複雜時,將會考慮到要使用Extract method 方式來重構method,當重構完發現這個method 根本不適合存在於此類別時,則會考慮使用Extract class 方法來重構class,久而久之,清理完自己過去寫不好的code,幫忙團隊整理好疏於管理的老code,對於「乾淨的程式碼」這件事情也越來越有感覺,也越來越執著。

你心目中的軟體開發,還只是看Document 並做出一個「會動的軟體」這樣而已嗎?快點一起學習軟體工程,來增加自己做軟體的功力吧!

 

*註1:Maybe 是一種鼓勵念研究所的手段 (?)
*註2:在我了解Scrum後發現,公司使用的Scrum 並不是真正的Scrum,只是一個仿造其中角色名詞的開發方式。