40 個可以改變寫程式技巧的秘訣

 前言

這篇文章是取自 Medium kesk-*-,文章的拍手數非常多,仔細讀完發現,這篇文章有很多點會讓人產生共鳴,有一些觀點是需要有專案的實作經驗才會懂,有些則是需要有人願意提出來說,協助你了解程式碼還有什麼樣的缺陷,怎麼改會比較好.但以下的 40 點不是準則,算是學習路程的經驗整理.

由於全文都是使用英文撰寫,所以用自身理解把文章的內容稍微做翻譯,如果想看比較原汁原味的內容,可點選連結查看.

1. 將整個段落的程式碼,分拆成多個 fuction.比較能夠掌握各段程式碼的功能,看起來也不會過於冗長.

2. 如果下班時,已經離開公司跟電腦,但問題還沒有解決.那麼請不要再繼續思考問題,放到第二天再來解決.(重要 - 工作不是生活的全部)

3. 當程式碼中不會用到這個功能,就不要再額外加入,不用先預想未來可能會用到,程式碼僅需要完成當前所需的功能.


4. 你不需要了解所有程式相關知識,但是需要有相關的基礎,當研究新知識時,請先深入了解該語言及一些基本的規則.

5. 程式設計時,以簡單的方式來呈現,不用設計的過於複雜,執行的效率就會高很多.但通常不容易實現.

6. 不要想太多.
(不是說沒有規劃就直接油門催到底開始寫,是思考時不用把程式架構思考的太複雜)

7. 被問題卡住時,站起來走走.倒杯咖啡, 散個步, 上個廁所,等等再回過頭來思考,先把自己暫時抽離.

8. TDD (=_+)


9. 先解析問題再寫程式碼,否則你會不知道究竟在寫什麼.

10. 程式碼不需要靠死記硬背.

11. 當從 Stack Overflow 複製或貼上任何程式碼時,請確認了解它的功用.

12. 如果想要學習,動手寫程式碼是最快的路徑,比起透過書本來了解,實際上場比較重要.

13. 研究別人的程式碼,也讓人來閱讀你寫的程式碼.互相幫助,是一個很好的學習方式.

14. 當有人已經寫好的不錯的第三方或已經有更好的解決方式時,就不要再自己動手重做一遍.

15. 讓程式碼變成最好的使用說明書,讓需要使用的人可以了解.

16. 懂得如何用 Google 去搜尋問題,但這需要有一定的經驗.

17. 寫程式碼需要考慮未來維護的問題,因此在寫的時候需要換位思考,讀的人是否看得懂,讓程式碼化變成一本故事書,可以輕易簡單的閱讀,而不是寫成天書,只有自己看得懂.

18. 最好的解決問題方式是 Google,複製貼上你的問題.

19. 不要放棄解決問題,問題終究會解決.日子不好過,但總會過去.(不是離職...)

20. 休息是為了走更長遠的路.最好的解決問題方式是充分的休息.

21. 學習不同的設計模式.

22. 使用整合好的工具,並盡量讓工具配合你來完成.

23. kata (=_+)


24. SOLID principles (=_+)


25. 優化程式碼,不修改架構的原則下.(這點可能需要用比較大的角度來看,畢竟如果是龐大的專案,修改並優化時會牽扯到非常多問題)

26. 如果遇到問題,請及時找人討論或尋求幫助.(不要閉門造車)

27. 勤加練習

28. 不要過於關注網路上問題下方的留言,相關的問題,有些時間已經很久遠不符合現在使用.

29. 了解程式的開發環境

30. 重複的程式碼,可以抽離出來共用,就不會到處都有相同的程式碼.

31. 在開發時,要考慮移動端(手機)這部分有什麼限制.

32. 不用太早對程式碼做優化,要先確保程式的基本功能可以執行.

33. 不要為了節省時間,寫了一些不是那麼好的程式碼.最後要修正時,會需要花費更多的時間來做調整.

34. 遵循文件的做法來寫程式.

35. UI 在設計時不要用工程的角度來看,要以一般使用者的角度來做設計.

36. 使用版本控制工具,並確保可以少量的修改且頻繁的 commit 更新.

37. 重要的部分可以使用 Log 紀錄,方便查看問題.會比遇到問題時再去 Debug 好. 

38. 寫程式碼時,請使用固定的風格.在團隊開發時,也使用跟團隊相同的風格.

39. 不要停止學習新知識.

40. 對你的工作跟正在做的事情,持續保持熱情.

後記
這篇文章如果對你有幫助,可以幫忙分享.內容有錯誤的的部分,也請留言讓我知道.

END

留言

熱門文章

雲端硬碟比較,哪種硬碟最推薦? (Google 雲端硬碟, OneDrive, DropBox, iCloud)

如何創造出難以維護的程式碼