iT邦幫忙

2022 iThome 鐵人賽

DAY 30
0
自我挑戰組

C# 和 SQL 探索之路系列 第 30

Day 30: 讀書心得: 成為卓越程式設計師的 38 項必修法則 & 後記

  • 分享至 

  • xImage
  •  

嗨,今天是第 30 天囉,來到最後一天,用這本書的讀書心得作為收尾吧 ~
以下列出我認為書中很重要的部份:三個軟體設計的原則、三元運算子如何簡化程式碼,還有程式員的姿勢。

成為卓越程式設計師的 38 項必修法則

DRY 原則

Don't Repeat Yourself

不要重複自己做過的事。不要草率的剪下或貼上程式碼,如果有 Bug 的話,會需要修改所有的程式碼片段,維護起來較為不便。若有類似的程式碼,可以重構為共用函式,並透過參數傳遞處理不同的部分。

但如果將類似的程式碼重構為共用函式,會增加共用函式的耦合性,一旦修改函式,引用函式的部分都要修改,因此要小心重構。

也要注意是否重新發明車輪,如果前人已有撰寫同樣功能的程式碼,應該要盡可能拿來利用。檢查有沒有第三方程式可用─通常第三方的程式經過許多使用者的驗證,會比自己手刻的更穩定和易用。

YANGI 原則

You Aren't Gonna Need It

不寫非必要的程式。維護多餘的程式碼費時費力,也讓專案難以被理解。新進入專案的人員,需要花更多時間瞭解程式。

這些程式碼常來自未使用功能的相關程式、不再使用的成品或功能,永遠否定的條件或不成立的迴圈、回傳用不到的值等。通常是多次修改程式碼或沒有謹慎撰寫程式碼,導致這些狀況。

雖然有時會擔心某段程式碼可能會在未來用到,但在有版控的狀況下,還是可以放心地移除。

KISS 原則

Keep It Simple, Stupid

這個原則並不是指用最輕鬆的方式寫程式,而是使用者可以很輕易地使用程式,複雜的管理部分,則交由程式內部處理,例如 API。此外,也應減少中間層的加入,減少追蹤困難。

此外,也要撰寫平實近人的程式碼,讓他人和自己都能快速理解,並避免過早最佳化程式。過早最佳化程式,容易增加程式的複雜度,減少修改的彈性。

三元運算子

三元運算子 (?) 可簡化雜亂邏輯。

原本使用 if 指定變數數值的程式碼:

if(a > b)
{
    c = 1;
}
else
{
    c = 0;
}

可以簡化為以下描述:

c = (a > B) ? 1 : 0; 

程式員的姿勢

為了用舒服的姿勢工作,避免未來因為職業傷害而付出高額醫療費。以下是姿勢的建議:

1 調整椅子與螢幕位置,使眼睛與螢幕上緣齊高,距離約 50 ~ 60 公分。
2 手肘應呈 90 度,不必明顯的使用肩膀的力量。
3 臀部的角度應該是 90 度,或稍微多一點 (舒服地靠在椅背上)。
4 腳平放在地上;手腕在前方的桌子上,打字時要保持平直。保持一個舒適的姿勢。

除此之外,也應該常常看遠方來放鬆眼睛、多補充水分、維持充足睡眠 …。

延伸閱讀

書籍資訊

成為卓越程式設計師的38項必修法則
Becoming a Better Programmer
作者: Pete Goodliffe  
譯者: 賴屹民
出版社:歐萊禮  
出版日期:2015/05/05
ISBN:9789863475699

後記

首先恭喜自己完賽了! ヽ(●´∀`●)ノ

這次撰文時,可以感覺得出熟悉的題目可以流暢地寫完,不熟悉的題目就要花較久的時間整理、找資料、寫程式,才能發出一篇完整的文章。

而且在找資料的時候,發現其他網誌的作者很厲害,都能在撰文時將背景、程式邏輯、優缺點說得很清楚。

因此未來要更花心力寫程式和撰文,精進自己的技術和表達能力,讓讀者 (和自己) 都能從技術文章中受益。

那麼,再次謝謝大家 ~


上一篇
Day 29: 讀書心得: SQL 達人的工作現場攻略筆記
系列文
C# 和 SQL 探索之路30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言