文章同步於blog
鐵人賽也來到最後一天了
今天就把整個系列完整的做個總結吧
其實不只是Coding Style可以讓程式碼更乾淨
還有包含邏輯上的梳理、換個方法,也可以幫助程式碼變得更乾淨
舉個例子:
假設今天使用者在註冊的時候
輸入密碼需要驗證
規則是不可以有連續 4碼升冪 或 降冪 的狀況
如果驗證成功,回傳True,反之False
密碼僅能為英文字母 + 數字,最長長度255
1234 -> False
1237 -> True
3210 -> False
5456 -> False
abcd -> False
Abcd -> False
abbc -> True
在這個情況下我們可以用最原始的方法來寫,遍歷所有的字串 + Ascii Code的方式來撰寫
def validate_password(password: str) -> bool:
"""驗證連續四碼是否有升降冪
"""
password = password.lower()
temp_char = password[0]
invalid_count = 0
for curr_char in password[1:]:
if abs(ord(curr_char) - ord(temp_char)) == 1:
invalid_count += 1
else:
invalid_count = 0
if invalid_count == 3:
return False
temp_char = curr_char
return True
看起來完成了,但if-else
的使用感覺可以載更精簡,然後temp_char
這個變數好像也不是必要的
所以我們可以想一下 if-else
的邏輯似乎可以改變為 != 1
來,然後讓 invalid_count 歸零之後繼續下一個迴圈
再來temp_char
的部分就可以改成使用索引的方式去做
最終會變成
def validate_password(password: str) -> bool:
"""驗證連續四碼是否有升降冪
"""
password = password.lower()
invalid_count = 0
for i in range(1, len(password)):
if abs(ord(password[i]) - ord(password[i-1])) != 1:
invalid_count = 0
continue
invalid_count += 1
if invalid_count == 3:
return False
return True
如此一來我們就又可以少用一點記憶體空間
單元測試這件事情,部分開發者經常仗著自己寫過很多次、並以沒有時間為由來拒絕寫單元測試
但實際上,撰寫單元測試,更是可以幫助自己開發更為順暢,即便自己寫過很多次,每次在寫單元測試時,其實都是在想各種狀況,畢竟使用者不會按照你所想的那樣操作系統
且系統交接給後人的時候,你總不會希望有人看不懂一直問吧,寫單元測試跑過一次就知道function大概在做什麼了
一開始在學寫程式的時候,一定都有一個狀況就是
先把function整個寫死
結果別人看到就說,那如果我丟你條件以外的東西你不就炸掉了
換到實際狀況,你根本不知道甚麼時候要多加什麼需求
我曾經遇過一個狀況,今天我們需要為每一件商品新增方案,至多8個
但這個功能非常之趕,一定要快速寫出來
此時有人提議,直接在所有商品上新增8個欄位阿,反正他以後不可能再新增了
別傻了,你哪知道他哪天又回心轉意了,他哪天想要100個方案你還讓他新增的時候,你也是來問開發者為什麼不行
還是思考一下未來吧,你不會知道哪天需要加上什麼新功能的
當下方便有時可以減輕開發者的負擔,但如此只是把技術債給債留子孫
明明可以做得更好,那就做好吧(除非你薪水領太少
這一個系列都在講述如何成為一個更好的開發者,專業的開發者不能只站在自己的角度想
也必須為了公司著想,公司的營運狀況是會影響到大家的,總不會奢求公司沒賺錢還要狂發一堆獎金給你吧
當把公司的利益放在前面的時候,公司就更有機會賺錢,也更有機會分享成功的果實給大家
這裡不是要大家當個奴性的程序猿,完全聽命於上級
而是要發揮自身專業的價值,還有技術以外的想法,這樣一來才可以讓自己的價值更為提升