作者:sivagao
鏈接:https://github.com/sivagao/blog/issues/18


本文羅列的這些書籍封面其實是各種典型的反模式,不過它們真的是非常常見以至於大家都習以爲常了~

《從Stack Overflow上覆制粘貼編程方法精要》

你最需閱讀的一本編程書籍(其實編程書留下這本就夠了!)

搞笑的是,在 Gitbook 上真有這樣的小書,從 code licensing issues, code attribution, code selection 上來論述。

https://tra38.gitbooks.io/essential-copying-and-pasting-from-stack-overflow/content/code_licensing.html

啪啪啪,打臉程序員的9本指南!

《每六週重新你的過時前端代碼實戰篇》

唯一正確寫 JavaScript 的方式就是每週換個花樣重寫一遍! 事實上擁有一個不斷進化和自我革命的社區是一件很不錯的事情,但前提是要你要接受這樣的現實。不斷學習和充實自己,並且透過變動改變的這些抓住真正永恆和持久的東西。

關於JavaScript社區爲什麼這麼生機勃勃,折騰不止,請看文章永不停步(折騰死人)的JavaScript 生態

https://github.com/gaohailang/blog/issues/17

啪啪啪,打臉程序員的9本指南!

《精通爲不寫測試找藉口》

不寫單元測試你還有千般理由!!

單測其實有很多好處,譬如儘早發現問題,爲重構代碼和更新代碼邏輯提供保障,簡化集成(因爲單測從細節底層入手),可以起到文檔作用(詳細完善單測用例完全可以),導向設計(測試驅動的更容易讓你設計出優雅低耦合的代碼)

你要對如下的代碼準備好足夠的單元測試用例:

  • 那些經常要被修改的
  • 那些有很高複雜度的
  • 那些重要功能/常被查看的
啪啪啪,打臉程序員的9本指南!

《臨時代碼權威指南》

你說你下週會開始重構這坨意大利麪條似的噁心回調嵌回調代碼?! - 你TM在跟我開玩笑? 交付的確很重要,但是這絕不是讓你寫出爛代碼的接口。

以不符合設計原理 / 不易維護 / 不易調整 / 不夠健壯 / 不夠美觀的方式解決問題。

比如水管連接處生了鏽開始漏——

  • 把水管系統整個重新佈置成沒有接頭的管線,叫做 refactor
  • 按原樣把鏽掉的水管換新的,叫做 proper fix
  • 把水管拆下來用防滲膠帶纏住螺絲紋再裝回去,叫做 patch
  • 叫你女朋友先把漏水的地方捂住然後下面放個臉盆接漏水,叫做 monkey patch
  • 用電焊把接頭焊起來,叫做 hack
  • 用口香糖塞住漏縫然後用水泥把接頭澆築起來,結果因爲那一大坨太重,下面不得不放一根木棍撐着,叫做 dirty hack

Dirty hack 不一定總是壞事,如果你沒有臉盆、電焊、管鉗、女朋友、新水管和防滲膠帶,而這套水管系統反正就快整個報廢了的話。

啪啪啪,打臉程序員的9本指南!

《都怪用戶口袋書》

你還在花時間修復那些撓人的bug? 你是10X工程師,怎麼可能出錯,肯定是別人的問題。是他們的手機,瀏覽器的問題,一定是!!很多工程師的確是這樣解決問題,一些特殊case,一些在設計代碼沒有考慮的情況,就這樣被他忽悠過去了。

啪啪啪,打臉程序員的9本指南!

《從入門到精通:簡歷驅動式開發》

要做『溫趙輪』式程序員?那麼感覺拿起這本書開讀吧。

表現型選手就是這樣,他們常常需要挑活做,去做那些看起來很高大上的事情,卻不願撩開袖子去處理細節去幹髒活累活。

他們也經常在簡歷上寫着 XXX 項目的主要負責任(實際上很可能就是參與了一部分,做了邊緣系統的部分功能)。或者在簡歷毫不謙虛的寫着精通XX編程語言(實際上很可能就是用它寫過helloworld而已)。或者在簡歷大大方方的寫着熟練使用XX消息隊列(實際上可能也就僅僅是看了篇膚淺的博客而已)

啪啪啪,打臉程序員的9本指南!

《寫出沒人看懂代碼:權威指南》

如果連你自己都看不懂,那就更棒了!

他們對系統代碼的要求很低,『它不是能跑嗎,你管那麼多幹什麼』

這樣的態度,讓後來的同事很難推動後續的工作。譬如總是有莫名其妙的錯誤像是被它黑洞似的吞掉了,讓周邊模塊的開發者背黑鍋,一旦定位進去就像是在漆黑伸手不見五指的下水道走路,膽戰心驚瑟瑟冷風還有瀰漫空中的壞味道(代碼邏輯很繞,變量名稱很奇葩看不懂,幾乎沒有log日誌打印出等等)

啪啪啪,打臉程序員的9本指南!

《精通搜索錯誤消息》

在網上總能找到讓這些問題消失的方法!

啪啪啪,打臉程序員的9本指南!

《用上無用依賴的開發者指南》

如果你項目的依賴少於72個npm的包,那麼你的代碼是那麼的孤獨,趕快拿起這本書開始閱讀吧。那些網上陌生人寫的代碼總是打包票的好是吧?

這些人真是把不重新發明輪子的優良傳統發揮到極致,可能就是爲了用某個函數方法就把一個巨大的依賴庫加入到代碼倉庫中(後續花費在安裝依賴上的時間,很可能超過了那個簡單函數方法編寫上),更有甚至不把依賴下載類似於 packages.json,bundler,requirements.txt等中,居然讓後續協作人去生產機器上把依賴直接copy回來(orz...)PS:要用好類似於 pip freeze, npm shrinkwrap 等功能啊


啪啪啪,打臉程序員的9本指南!


相關文章