2023-06-01|閱讀時間 ‧ 約 3 分鐘

從 0 到 1 成為前端工程師應該養成的 3 個寫程式習慣

這是 30 天寫作挑戰的第 14 天。今天要跟大家分享的「從 0 到 1 成為前端工程師的……」主題是:
從 0 到 1 成為前端工程師應該養成的 3 個寫程式習慣
30 天寫作挑戰:連續 30 天,每天都會從 ChatGPT 、生活中的靈感或是網友提問中,選出一個可以用 200–500 字的文章來回答的題目。說明可以參考宣示文。如果讀者想要我回答你/妳的問題,可以問我一個跟工程師、技術產品經理、產品經理有關的問題。

寫之前:以終為始,程式要達到的目的是什麼?

比起手拿錘子看到盡是釘子,工程師更容易是手放鍵盤,看到程式碼,覺得滿地都是可以寫得更好的方法。因此在程式碼之中迷失,想要改善前人留下來的「祖產」。有這樣的心態其實對工程師來說是好的,代表心中有一股匠人精神,想要讓作品(產品/程式碼)變得更好。
不過在動手之前,也應該要記得,自己之所以開始某段程式碼,大多是因為任務所需,如果交付給自己的任務並不是專門將祖產更動,而是加上新的需求,那麼關注的要點應該是在滿足新需求的同時,還維持原本的程式碼可以正常運作,而不是優先思考怎麼樣將原本的程式碼改寫成自己心中理想的樣子。

開始動手寫:如果先寫測試要寫什麼?

承接前述,如果要讓新的商業邏輯可以如預期地運作,那先構思及實作對應的測試,可以有效地確保後人在修改相同段落的程式碼時,不會把你辛苦的成果給弄壞。確切要怎麼樣先寫測試再寫程式碼,可以參考 TDD

寫之後:有沒有優化的空間?

這裏指的就是思考重構的可能性。寫程式時(不管是在動手寫還是構思規劃時都是),先求有再求好的情況也是會發生的,因此在符合需求的程式碼實作之後,可以思考要怎麼樣讓程式碼更加簡潔、效能更好。此時,前一段落提到的測試,就可以在重構時發揮保護商業邏輯的功能,不至於在重構時把程式碼改壞。

今日寫作觀察

今天寫起來滿順暢的,一邊在構思內容,一邊也幫助我反思有哪些習慣是我希望在剛成為工程師時就能養成的。希望以上內容對想成為成為工程師的讀者能有幫助。
分享至
成為作者繼續創作的動力吧!
我是 Larry,《下班後的產品工程師》是我在下班之餘分享我對網路產業的工程師、產品經理相關職能的想法和心得,也會分享一些自己突發奇想的產品、商業問題。希望文章內容能帶給你/妳收穫。對了,如果很久沒有更新,一定不是因為我還沒下班。
© 2024 vocus All rights reserved.