談編程 · php筆記

## 談編程我們來思考一下編程這件事情，哦，我說是編程，而不是打字。 * * * * * 最近突然覺得編程就像是玩游戲，只要遵循游戲的規則就會順利通過調試。代碼本質就是字符，寫代碼本質上和打字沒有區別，只不過兩者遵循的規則不同而已。php 代碼要遵循php語言的規則，php執行時要遵循操作系統的規則，操作系統要遵循更底層的硬件運作規則，硬件運作則遵循真實世界的科學規則。游戲里你去不了地圖邊界之外的地方，你的所有動作都是游戲提供的，你不可能打出游戲中沒有的技能。編程的規則也是如此，應用層無法突破語言層的限制，語言層也無法突破操作系統的限制（漏洞除外），打開文件，申請內存，所有的一切都是操作系統提供的，上層的一切在操作系統層都是透明的，只要老實的遵循系統設定的規則就能玩下去。無論在哪一層，都有相應的規則，遵守規則，某種意義上就是遵循現實世界中的事物的運作規律。 ps: 程序能繞開操作系統的規則嗎？能，沒有規則限制可能更靈活，但那樣也喪失了很多便利性，操作系統提供的便捷調用可能就無法使用了，開發工作量會增加，畢竟操作系統的本意是做到讓你簡單可依賴。 ---- ### 何為編程 **什么是code?** code就就是一種語言，一種計算機能讀懂的語言。計算機是一個傻逼，他理解不了默認兩可的任何東西。比如，你讓你老公去買個西瓜，你老公會自己決定去哪里買，買幾個，找個搞活動打折的買，總之，你給他錢，他就給你買回來讓你吃到爽的西瓜。但是，你想讓計算機買一個西瓜？你要告訴他：去門口的鮮豐水果店買，買沙瓤無子西瓜，若旁邊的店打折，就去旁邊的店買。總之，你不能讓計算機做任何決定，你要清楚的告訴他所有情況下的所有的行為。而code，就是你和計算機交流的語言，或者說是對計算機的命令。我們就把計算機理解為一個人，這個人很死板，只能按照你給他的詳細命令進行工作。而這個人工作速度特別特別快，并且保證工作結果都是正確的。編程語言其實不重要，重要的是要明白如何和計算機交流，明白了這個也就能看懂代碼了。 > 編程 = 算法 + 數據結構 by: [如何教老婆學Python](http://mp.weixin.qq.com/s/FitYuiA9b0xxo8URubg-jw) ---- 計算機是多學科交叉的結果，計算機技術很多時候也是這樣的，如果掌握的技術多，學習和解決問題時都有直接的好處。甚至有的知識就是依賴的，如果你想學A知識，就一定要先學B知識才行，所以多涉及一些領域，多掌握一些知識總是有好處的。數據結構即數據的存儲結構，說清楚了，但還是跟沒說一樣，那再說的更直白一些：數據結構是指在對一組數據進行展示或存儲時的結構定義，這個結構定義包含數據的順序、層級、規則、之間的關系和其他語義等等。而算法一般是對數據處理的一系列可描述的過程。計算機技術是科學和藝術的結合，所以我認為程序員是計算機科學家和藝術家。程序員完成一項軟件作品和雕塑藝術家完成一項雕塑品是一樣的創作過程，雕塑家用刀精心雕琢藝術品，程序員用代碼實現創意，所以他們本質上都是一樣的。所以如果不尊重程序員就是不尊重科學、褻瀆藝術，禁錮創意和想象力。 * * * * * ### 代碼本身的意義代碼本身并不重要，它能干什么，怎么干，干得好不好才重要。換句話說，代碼的意義不在于它本身，而是在于怎么寫，在于它所表達的思想。作者只是借助代碼來表達他想要表達的思想。相當于你說話，你表達的觀點才有意義，而不是在于你說話所用的單詞。代碼怎么寫對我人來說才重要，至于它會被編譯成什么，我們無需關心。比如我們寫ES6代碼，經過Babel編譯成瀏覽器能執行的代碼，我們只需要關心我們寫的代碼就好了，至于這個編譯過程，編譯后的代碼，對我們來說猶如亂碼，是不重要的。再次強調，代碼怎么寫才重要。任何事情，你都要看到事物的本質什么，coding也是一樣，我們需要看到編程的本質，而不只是在電腦前打字。代碼是抽象的思維表達方式，比如編程語言設計者設計的語法，判斷，循環等等，這些只是為了幫助我們描述思想。當代碼在CPU層面執行時，就被分解成一個一個的執行單元、指令，宏觀上CPU根本就不知道它在干嘛，并不清楚自己在做什么，它只知道傻傻的執行它自己的指令，上游的程序對它來說是不存在的，它只知道它的指令集，而上游也是如此，程序也并不關心CPU做了什么，是怎么完成這個功能的，而我們寫的代碼就在上層，這中間的抽象，差異化就是編程語言，編譯器所要做的事情，所以我們各自做好自己的事情就好了。當然這中間還有操作系統，操作系統也在中間一層，不過操作系統和編程語言這一層還是有不同。 * * * * * [神回復：編程到底難在哪里？看懂才是個合格的程序員](https://mp.weixin.qq.com/s/z9p18Bs8bebBjiWPYLmvNw) 而是以買蘋果為例說明程序員如何解決問題。程序員需要對問題進行透徹的分析，理清其涉及的所有細節，預測可能發生的所有意外與非意外的情況，列出解決方案的所有步驟，以及對解決方案進行盡量全面的測試。而這些正是編程難的地方。任何一點遺漏都會成為bug，輕則導致挨罵，重則導致經濟損失甚至危害安全。還有要確保代碼邏輯的執行符合預期，這樣程序才是正確的。 > 寫代碼的目的是為了不寫代碼，代碼不是越多越好，因為代碼是負債，需要持續的維護，代碼越多，維護成本越高這世界上很多事，不是存在即合理的，因為很多人根本不會自己思考，而是盲從麻木的最好的設計是直接告訴用戶是什么，而不是為什么。跳出語言的枷鎖，看到問題本質，找出關鍵點，深入底層簡單的東西是最好的，因為只有簡單才會優美。如果遇到問題，要么是不細心，要么是即將要掌握一個新的重要的知識點好代碼必須包含以下幾點：清晰，簡潔，易讀，優雅（實現與使用上），容錯性，魯棒性 ***** ### 編程的原則沒錯編程也是有原則的。只有當我們統一，遵循一致的原則，世界才會更加美好。 ```javascript // 獨立性是模塊的重要特點，模塊內部最好不與程序的其他部分直接交互。 // 為了在模塊內部調用全局變量，必須顯式地將其他變量輸入模塊。 var module1 = (function ($, YAHOO) { //... })(jQuery, YAHOO); ``` 這種代碼見得多吧，試想一下為什么這個自調用結構需要傳兩個全局變量進去呢？既然是全局變量在匿名函數里面直接使用不就可以了嗎？還要傳進去不是多此一舉嗎？真的多此一舉嗎，從代碼功能上來說的確是多此一舉，不過其實這是有意義的，代碼終究是人編寫的，所以在長期編寫總結中就會有一些實踐規律，這就是設計，最佳實踐，為了使代碼便于理解，維護，所以必須要準守一些設計模式，上面這種形式就是在遵循一種設計模式。世界上本沒有規則和規律，但是總有人去總結實踐，這樣就有了規律，當所有人都遵循相同的規則，那么溝通的成本就會小很多，世界秩序就會好很多。試想一下，如果不遵循這種設計模式，**那么這個匿名結構里面隨便使用了外部變量，做了什么操作，對全局環境進行了哪些改變或者污染**，我們知道嗎，我們根本就不知道，鬼才知道它葫蘆里面裝的什么藥呢，這樣我們心里沒譜，不放心，**不確定它會不會給我們帶來什么未知的傷害**，不信任它。但是這樣通過傳參了，它就向我們傳達了一種信號，那就是，**我內部是不會隨便使用什么的，你盡管放心好了**，你不用管我，看，我就是使用了你傳進來的參數啊，這就一目了然了，我對它就放心多了，瞬間就變得親切了。如果所有代碼都遵循這種設計，都循規蹈矩的，那么管理、維護就會很輕松，因為我們知道，**我所想象的就是我所想象的樣子**，沒有任何多余的必要的擔心了。同理，將使用到的變量提前聲明也是這個作用和意義。 **從功能上沒有意義，但是意義體現在設計上。** 這就是編程的原則。補充：編程原則不針對于特定的語言，而是對所有編程語言適用，雖然有些語言有一些奇淫巧技，但是在團隊協作時還是要規范，因為團隊中的每個人的技術水平都不一樣，并且每個人的習慣都不一樣，要想融為一體工作效率最大，就必須遵守制定的規范來工作。（比如PHP里面的抽象類，接口類其實也是這樣道理，強制你是用統一的實現，這樣保證了代碼的規范性） [函數式編程，真香](https://mp.weixin.qq.com/s/HDOXCMRk_nd59cY9rWXsOQ) [JavaScript 的 API 設計原則](http://mp.weixin.qq.com/s/8-0O2jQf5pm7XQWjysJKKQ) > 命名這點事：既要短，又要自描述，最重要的是保持一致性 “在計算機科學界只有兩件頭疼的事：緩存失效和命名問題” — Phil Karlton 選擇一個你喜歡的措辭，然后持續使用。選擇一種風格，然后保持這種風格。 [如何寫出小而清晰的函數？（JS 版）](https://mp.weixin.qq.com/s/BxH5C_4Dnay7s4e_cwDC6Q) [如何讓你的代碼整潔漂亮？](http://mp.weixin.qq.com/s/5fFVtdGUFc7Fo7oKHyejjw) > “程序員必須為了讓人能閱讀代碼而書寫代碼，而機器執行只是順便的。” [在 css 中什么是好的注釋？](https://mp.weixin.qq.com/s/963TnTMNAXstdIPYCTsrqQ) > 釋應該解釋“為什么”，而不是“是什么”，即說明原因而不是說明作用（Why, not what）。 [命名規范 · php筆記 · 看云](http://www.hmoore.net/xiak/php-node/317538) [蘋果 MacPaint 和 QuickDraw 的源代碼（2010）](http://mp.weixin.qq.com/s/RFw7JVXWBHmj55BbwaKuWw) > 在編寫 MacPaint 時，Bill 很關注代碼的可讀性，他說道「這也是一種藝術，和其他藝術形式一樣，我花很多時間重構代碼，使它們更簡潔、更清晰。我堅信， **防止錯誤最好的方法就是讓代碼變得更清楚，一眼就知道怎么回事。** 在蘋果工作后，我有了這樣的轉變。如果你想讓它變得通順，必須從頭開始重構至少五次」。 [什么是好代碼？](http://mp.weixin.qq.com/s/uHcZA_0wvGrRQ3crS90vdw) [nw.js作者Roger：找到正確方向比怎么做更重要](https://mp.weixin.qq.com/s/1twGepMZShSYBZhXE-_-gQ) [譯文丨為什么做程序員會讓我成為一個更好的醫生？](https://mp.weixin.qq.com/s/XuKY3RTe-BEqasuuD8WX_g) [慢公司豆瓣：只要不死，就讓我們這樣喪著吧](http://mp.weixin.qq.com/s/5-PmKrd-Mbn2DnDd7yYiqg) > 用優雅的方式去解決問題 [如何提高代碼的可維護性_慕課手記](http://www.imooc.com/article/27748) [3 個盲人程序員](https://mp.weixin.qq.com/s/SSat467sThJxSU7uOjO2rA) > 語音或盲文并不能描繪出窗口的顯示布局。信息以線性方式呈現給我。如果你把網頁復制粘貼進記事本，你就能明白我看到的網頁是什么樣子的。就是剝離大部分格式的多行文本。然而屏幕閱讀器可以獲取網頁上的 HTML 語法，所以我也能知道超鏈接、標題、表單等等。事實上，如果非復選框元素展示成復選框樣式，我并不能知道這是復選框。我之后將寫一篇文章詳細講述這些內容，記住我剛剛舉的是個“反人類”例子。（譯者注：突然感到自責和羞愧，深深明白了一個道理：不要用各種有含意義的傳統標簽 hack 布局和樣式，也不要因為 css 的強大而懶得使用各種有含義的傳統標簽。共勉） > > 我有眾多理由來強烈建議使用整潔統一的代碼風格，其中之一就是不要讓我的生活變得更加艱難了，好嗎。 [中國的盲道上為什么看不見盲人 - 故事FM - 電臺節目 - 網易云音樂](https://music.163.com/#/program?id=1370394407&userid=1668400836) > 每個人都有使用產品的權利，無障礙使用在一開始開發時就要考慮到。 [原來這就是四兩撥千斤，這下漲見識了](https://www.365yg.com/a6525240799402131981#mid=5881423966) > 巨大bug是怎么來的 [Linus 又開懟：有時候標準就是一坨屎！](https://mp.weixin.qq.com/s/je2aNl_S778FEnihudxC2Q) > 如果標準沒有解決實際問題，或者使問題更復雜了，那標準就是一坨屎。永遠沒有完美的代碼，只有保持更新、保持進步，才能趨于完美。 > 代碼的魯棒性：魯棒是Robust的音譯，也就是健壯和強壯的意思。它也是在異常和危險情況下系統生存的能力。比如說，計算機[軟件](https://baike.baidu.com/item/%E8%BD%AF%E4%BB%B6)在輸入錯誤、磁盤故障、網絡過載或有意攻擊情況下，能否不死機、不崩潰，就是該軟件的魯棒性。所謂“魯棒性”，也是指控制系統在一定（結構，大小）的參數[攝動](https://baike.baidu.com/item/%E6%91%84%E5%8A%A8/4777855)下，維持其它某些性能的特性。根據對性能的不同定義，可分為穩定魯棒性和性能魯棒性。以[閉環系統](https://baike.baidu.com/item/%E9%97%AD%E7%8E%AF%E7%B3%BB%E7%BB%9F/5993157)的魯棒性作為目標設計得到的固定控制器稱為[魯棒控制](https://baike.baidu.com/item/%E9%B2%81%E6%A3%92%E6%8E%A7%E5%88%B6)器。 [左耳朵耗子：編程的本質是什么？](https://mp.weixin.qq.com/s/3WKImtdg_rEd_R9eCjs6WA) [為什么高級程序員總寫傻瓜代碼以及怎么在一里外識別一個菜雞程序員](https://mp.weixin.qq.com/s/-bUubfXbU8xYOsQ7L0EkAg) > 編寫傻瓜式代碼實際上非常困難，但一旦實現則會帶來遠超預期的回報。 [程序的腐化](https://mp.weixin.qq.com/s/pa4P4wQvf93l7FGMMKcZPg) [魯棒性_百度百科](https://baike.baidu.com/item/%E9%B2%81%E6%A3%92%E6%80%A7/832302?fromtitle=%E9%B2%81%E6%A3%92&fromid=4869534&fr=aladdin) [程序員的敵人](https://mp.weixin.qq.com/s/QUJ2CMx0VAWJRlDbXOLM9w) > 軟件的不幸在于它創造出來的麻煩多過于它解決的麻煩。真實的情況是，軟件只解決了一部分它創造出來的麻煩…… > 「需求」是如此殘酷，每天讓我和團隊盡折腰。你不能回頭，你只能向前走，持續探索，不斷迭代，找到邊界，并突破邊界。我想，這也正是做產品的樂趣吧。 [每周分享第 5 期 - 阮一峰的網絡日志](http://www.ruanyifeng.com/blog/2018/05/weekly-issue-5.html) [自下而上的編程](http://www.paulgraham.com/progbot.html)，by Paul Graham > 傳統的方法是，一個大型的程序必須分成幾塊，程序越大，它就越需要分割。你如何劃分一個程序？傳統的方法稱為自上而下的設計：程序的目的是做這七件事，那么我把它分成七個主要的子程序，第一個子程序必須做這四件事，所以它又有四個子程序等等。這個過程一直持續到整個程序具有合適的粒度級別 - 每個部分都足夠大，可以做一些實質性的事情，但又足夠小，可以被理解為一個單元。 > > 有經驗的Lisp程序員對他們的程序進行不同的劃分。除了自上而下的設計之外，他們遵循可稱為自下而上設計的原則 - 改變語言以適應問題。在Lisp中，你不僅要將程序寫入語言，還要將語言建立在程序上。當你正在編寫一個程序時，你可能會想"我希望Lisp有這樣一個操作符。" 所以你就去寫了。 > > 當你自下而上工作時，你通常會得到一個不同的程序。你得到的不是一個單一的，整體的程序，而是一個更大的語言、更多的抽象運算符，以及一個更小的程序。程序的功能單位不宜過大，太大的函數容易掩蓋錯誤，就像一個大城市隱藏著逃犯一樣。這樣的軟件很難閱讀，很難測試，也很難調試。（《[自下而上的編程](http://www.paulgraham.com/progbot.html)》，by Paul Graham） [yii2開發中19條推薦實踐（阿北總結）](https://juejin.im/post/5b124627f265da6e16371d42) > **勿寫死，用常量或配置。** 訂單狀態也可以用這樣的方式，不然寫成數字ID沒有可讀性（一些好的開發習慣經驗對其它程序也同樣有益。） [程序員的35個壞習慣，你有幾條？](https://mp.weixin.qq.com/s/OyYSg5RCRImZujuhpINkEw) [淺析DDD(領域驅動設計) - 簡書](https://www.jianshu.com/p/b6ec06d6b594) [Redis是如何寫代碼注釋的？（文末有福利）](https://mp.weixin.qq.com/s/vH1QU4JC2D3dUI_OtKQjpw) [日志消息的5個級別](https://mp.weixin.qq.com/s/GRAvoCLJN6wAolhydB5b3w) [什么是元編程？](https://mp.weixin.qq.com/s/mXINFf5KkqQGePKywYRpTg) [談程序的正確性](http://www.yinwang.org/blog-cn/2015/07/02/program-correctness) > 符合編碼人員預期的就是正確的。 [我發現，我一直是站在巔峰啊！](https://mp.weixin.qq.com/s/HNcIgOD81UkQjbO2pG0dWA) > 你站得越高，越容易出現難以解決的**抽象泄露**的問題。 > Stack Overflow的創始人Joel Spolsky提出來的一個理論：所有重大的抽象機制在某種程度上都是有泄露的！ [用函數式的方式思考——遞歸](https://mp.weixin.qq.com/s/6VSxQ0kOnJt9p3ujvxf4mA) [為什么工程師要了解業務？](https://mp.weixin.qq.com/s/OAJS209R4Aeld4DgEUSnxQ) [入行 15 年，我還是覺得編程很難](https://mp.weixin.qq.com/s/B7Z0ROkiBqqxVKkLNR9BxQ) ~~~ 避開代碼完美主義陷阱在代碼質量上精益求精是好事，但也要注意別掉進完美主義的陷阱。因為編程不是藝術創作，不鼓勵人們無限度地追求極致。作家大可花上數年打磨一本傳世之作，但程序員在代碼上鉆牛角尖就很有問題。世間沒有完美的代碼。大多數時候，你的代碼只要能滿足當前需求，又為未來擴展留了一些空間就夠了。有那么幾次，我在簡歷上看到候選人給自己打著“代碼強迫癥”標簽。隔著屏幕，我雖能感受到 TA 對代碼質量的那份重視，但在我心底，其實更期望 TA 早已將完美主義陷阱遠遠甩在了后頭。不穩定的需求不是程序員的敵人。并且，能否寫出易于修改、適配變化的代碼，是區分普通程序員和優秀程序員的重要標準之一。軟件開發的核心問題是管理復雜度。失控的復雜度就是程序員最大的敵人。 ~~~ [你編寫的Java代碼是咋跑起來的？](https://mp.weixin.qq.com/s/0Xb-avSLr6QUxxWuhhjbhA) [千萬別用設計模式？](https://mp.weixin.qq.com/s/BfODAn1PUkk1pozKmSA0oA) [如果現在只能用匯編和Goto編程......](https://mp.weixin.qq.com/s/W6WzTszmiSo9vdglj7TsOw) [為什么我們不會用簡單的方式寫代碼？](https://mp.weixin.qq.com/s/R0zhhndbvFg8eB2PKSBeJg) > 正如英國計算機專家 Hoare 所言：軟件設計構建有兩種方法，一是使其盡可能簡單，從而一目了然確定其中不存在缺陷；另一種方法則是使其極為復雜，以至于看不出什么明顯的缺陷。 > > 遺憾的是，他還補充道：第一種方法其實要困難得多。如果問題很復雜，沒有突破口，很可能是因為你沒有真正理解所面臨的問題是什么。怎么做首先要知道做什么，換句話說，做什么比怎么做更重要。 [當15年的老司機遇到爛項目、爛代碼時，他會做這5件事！](https://mp.weixin.qq.com/s/WLWTWxSEnrS_GJI-hDoFdw) [有這么一個軟件大神，他很少談論操作系統、網絡、高并發、海量用戶......](https://mp.weixin.qq.com/s/oQ2JcyP_AU_ck_1TquFLng) > Martin Fowler給我們的啟示就是：實現業務邏輯并不比底層的系統級開發低級，只要善于總結，善于思考，這一領域也大有可為。 ~~~ 寫業務代碼是低級編程嗎？計算機本身就是基于科學真理的，并在上面定制了規則，其實按照特有的方式工作。而編程語言本質上也是基于硬件，計算機規則，和科學真理定制的規則，使用語言編程就需要遵守這些規則，并基于科學真理，有時規則可能本身就是錯的，此時還是需要以科學真理為準，因為語言編譯器本身可能并不完全可靠，或者說語言本身的局限性，所以編程總是游走于規則和科學真理之間。這么來看的話，編寫業務代碼一點也不低級，因為業務就是規則，我們需要理解這些規則，并結合底層規則，還有科學真理來實現最終的功能，本質上這種編程和系統編程沒有任何區別，只是工作在不同的層和處理不同的規則而已，大家都是遵從科學真理和各自的規則，本質上沒有任何區別，所以不要再說寫業務層代碼是低級的編程了。產品是技術和業務相結合的。相反有些時候我認為業務代碼比其它編程更加復雜，因為我們需要利用最合適的技術來滿足業務，找到最優解并不容易，這需要一些經驗和對底層的深度理解，只有這樣才能做出一流的產品。 ~~~ > 可以看到，數據結構變了之后，實現方法一下子就簡單了很多。所以數據結構的重要性是要大于算法的。可以說是數據結構決定了算法。 [“軟件教父”又開始整理模式了！](https://mp.weixin.qq.com/s/ILiaR_VKGU8epfkf-eqgcg) ---- [為什么HikariCP是性能最好的數據庫連接池？](https://mp.weixin.qq.com/s/1icGvKXfIoygEwD3PreoCw) > 正是這樣一點點微小的優化，凝聚溪流，匯集成河，讓HikariCP獲得了“光速的”性能，讓人佩服，我估計后來者很難超越了吧。事情做到極致 [為什么說 Java 程序員到了必須掌握 Spring Boot 的時候？](https://mp.weixin.qq.com/s/jwgsJnj0V21xAJnBsj_VvA) > 在此引用 Python 的經典設計格言，格言來源于 Python 但不限于 Python。 > > 美麗優于丑陋。 > 清楚優于含糊。 > **簡單優于復雜。** > 復雜優于繁瑣。 > 平坦優于曲折。 > 寬松優于密集。 > 重要的是可讀性。 > **特殊的案例不足以特殊到破壞規則。** > **盡管實踐可以打破真理。** > **錯誤卻不可置之不理。** > **除非另有明確要求。** > **面對模棱兩可，拒絕猜測。** > **總會有一個 —— 最好是只有一個 —— 顯而易見的方式來明辨。** > 哪怕這種方式在開始的時候可能并不明顯。 > 現在有比沒有好。 > 盡管沒有經常好于現在。 > 如果如何實現很難被解釋清楚，那么這個想法就是一個壞想法。 > 如果如何實現可以被很好的解釋，那么這是一個好想法。 [《黑客英雄》書摘 - 前方的路 - 阮一峰的個人網站](http://www.ruanyifeng.com/road/2010/2010-12-07-hacker.html) * * * * * ### 編程是一種真正的技術嗎 Hacker News 上面，有人問："新人進入軟件行業，應該學什么？" 很多熱心人提供建議。有人說： "你應該好好學習一門語言。精通一門計算機語言，可以讓年輕工程師脫穎而出。這不僅對日常工作很有幫助，也有利于以后學習其他語言。學習的東西包括：設計模式、調試、性能、生態系統、標準庫等等。" 立刻有人提出相反的建議。 "我建議學習幾種彼此非常不同的語言。例如 Java，Go 和 JavaScript。你要學到精通其中每一種語言，能夠獨立地從頭搭建一個新項目，在該語言的生態系統中完成所有開發工作。" 有人舉出幾種必須掌握的工具。學習 SQL，你將能夠使用任何與數據庫相關的軟件。學習 HTML，你將能夠創建一個通用的用戶界面。學習 GIT，你將能夠與他人分享您的工作。學習 Unix shell，你將能夠部署所有的東西。不少人贊同這種說法。 "大多數職業（從醫生到電工），多年的經驗等同于多年的專業知識。但是在軟件開發中，技術變化如此之快，你花費了大量時間學習技術和工具，**一旦這些技術被取代，你的知識將變得毫無價值，因為它們大部分都是實施的細節。** 最終，所有這些年，你確實積累了一些一般性的經驗，但與具體實施相關的知識，你都不再掌握了。唯一留下的是那些基本的東西，你應該專注于軟件開發的核心知識和數學知識，您的這些技能會不斷增長，而不是隨著技術潮流的變化而消失。" 我最喜歡的是下面這個建議。 "不要讓自己太忙碌。不過，說起來容易做起來難。我們雇用新畢業的工程師時，會派給他們很多瑣碎的工作，使他們飽和。他們會逐漸忘記大學里學到的課程，全部注意力都集中在手頭的工作。很多人傾向于通過忙碌程度來評價自己，我相信這是一個死亡陷阱。" http://www.ruanyifeng.com/blog/2018/09/weekly-issue-24.html >[danger] 一些項目的大部分代碼確實很多部分都是一些實施的細節，算不算真正的技術，因為體現不出任何創造力，沒有什么價值。但也有很多有創造性的代碼設計，而那些富有創造性的設計就是真正的技術部分。**因為是它具有思想的，而不只是一些簡單的實施細節。** [為什么有些“業余”的能贏。](https://mp.weixin.qq.com/s/8mNPCpvtVdjf94qUkXuiTg) （什么是專業） > 專業是技術，也是熱愛。 ***** ### 模塊化是走向成功的第一步任何大規模的東西都是模塊化的，手機就是個例子，手機的功能沒有局限性是因為可以安裝各種軟件，這些軟件就相當于手機的一個模塊。 ***** ### 做出真心實意的東西來才是王道標準有時候就是笑話，過分迷信權威是無知和無能的表現，能做出東西來才是王道，比如css層級關系不要超過幾級等，遇到特殊情況要變通，打破常規，這并不是說我們不遵守規范了，而是以另一種方式來解讀規范，我們尊崇規范，將它作為指導方向，但我們也不盲目死守規范，不被規范禁錮思維。世界是變幻無窮的，我們也要以“變”來應對。 * * * * * ### 生活中的規則紅路燈就是規則，只有我們每個人都嚴格遵守交通，才能擁有安全的出行。要是每個人都橫沖直撞，以為馬路是自己家的，想怎么開就怎么開，雖說也能通行，但是后果是什么？所以代碼也是一樣，隨著項目代碼量越大，復雜程度也會越來越大，要是大家都隨便亂寫，雖說也能運行，但是這樣面對這樣的代碼，誰敢動手，大家沒有統一的規范，想怎么寫就怎么寫，一旦發生錯誤，對整個系統來說都是災難。所以在代碼的世界里也需要社會中的秩序。社會中每個人都不是單獨的個體，都是協作的。人是群居的。只有有秩序，才能協作。代碼也是一樣。只有大家嚴格遵守標準、統一的規則，才能勁往一處使，一起愉快的玩耍。 * * * * * ### 編碼規范代碼的規范，命名規范，書寫規范，語法縮進，語法格式化，是否美觀工整，在交給計算機執行時，它并不在乎這些，這對執行性能沒有影響，但是一些編碼技巧，算法優化可能會對性能有影響，代碼給人看時，這些規范才重要。但是對于一個長期支持的項目，大部分時間需要人維護的，那么規范就很重要了，尤其是團隊多人合作的項目，規范更加重要，讓規范來約束個人，遵循統一的編碼規范，項目的維護才能輕松。 * * * * * ### 協作編程需要協作，靠一個人是建造不了摩天大樓的。比如，淘寶基于Java PHP等語言，運行環境基于服務器，操作系統基于Linux，硬件基于別的廠家的，IMB的，電力基于國家電網。而國家電網有基于每一個電網員工，……。這個社會是一個協作的社會。編程也是這樣。如果沒有協作，根本就不會有計算機。協作就需要溝通，接口，規范，所以其實世界上所有的程序員都影響者彼此，只有大家一起努力，才能提高軟件開發的質量，才能共建美好的世界。 [談開源 · 產品設計 · 看云](http://www.hmoore.net/xiak/product/482731) * * * * * ### 編程感悟編程體會，心得，感悟。 * * * * * **程序就是數據的流動** 數據總是從一段流向另一端，從一種形態轉變另一種形態。（參考瀏覽器的：Request 和 Response） * * * * * **不能忽視代碼的健壯性** 體現代碼的健壯性的重要的一個點是，程序是否考慮到了所有的可能情況，是否做好了錯誤處理。比如判斷AB兩個整數的關系，如果你只判斷了大于和小于那就有問題了，因為還會有它們相等的一種情況不能漏掉了，如果你沒有考慮全所有的情況，那么這個代碼就不健壯，測試時你可能測試不出來這些問題，看起來不會有問題，可是在運行過程中可能由此產生一些不可預料的后果，甚至難以排查的bug。 >[danger] **凡事有可能失敗的地方，就一定會發生失敗，所以檢測、容錯性要做好，不能偷懶！** [圖解冒泡排序](http://mp.weixin.qq.com/s/3eW3RMka1dlniLRQp7Sa2w) > **算法的穩定性：** 那這個算法穩不穩定呢？（擴展閱讀：**邊界檢查**） * * * * * **事物運行的本質** ![](http://cdn.aipin100.cn/17-12-25/90418249.jpg) 計算機并不是百分百和我們的預期一致，你得明白計算機的工作方式，比如循環，每隔一秒鐘休眠一下，你以為每隔一秒鐘運行一次，但實際情況可能是一秒多一點，至于這個誤差多大也說不定，要看當前計算的負載，進程的調度。所以我們的代碼通常只是理論上按照我們寫的那樣運行，我們的預期其實只是理論上的，你還要了解本質才行。 * * * * * ### 項目開發的一般流程 1. 應用場景 2. 分析問題 3. 整理需求 4. 編寫原型 5. 測試 6. 投入生產使用 7. 不斷修復問題，完善功能，迭代需求 8. 穩定運行 9. 形成通用、靈活、成熟的解決方案 10. 維護、升級、更新、社區、開源…… ***** ### 擴展文中代碼部分引自 [阮老師](http://www.ruanyifeng.com/blog)的文章：[Javascript模塊化編程（一）：模塊的寫法](http://www.ruanyifeng.com/blog/2012/10/javascript_module.html) [好程序員：中國程序員最厲害的是什么水平](https://www.toutiao.com/a6480371150525301262/?tt_from=weixin&utm_campaign=client_share&timestamp=1515662955&app=news_article&utm_source=weixin&iid=22069500288&utm_medium=toutiao_android&wxshare_count=1) > 求伯君自己認為：程序之間，沒有什么好比的，殊途同歸，各種功能最后大家都能實現。成者為王。“程序有兩種風格，**一種寫得規范，大家都看得懂**；**一種不規范，短小精悍**，幾條指令就能完成一個應用，講究速度。”求伯君認為自己屬于后一種。 > > “現在程序都很龐大，以光盤為單位。沒有合作精神，一個人做不出什么好軟件。我們當時單槍匹馬可以成英雄，現在已經不行了。（**而團隊合作就需要規范，所以求伯君的單槍匹馬已經不適應這個時代了**） [Swoole · php筆記 · 看云](http://www.hmoore.net/xiak/php-node/346847) [yangweijie/clean-code-php: Clean Code concepts adapted for PHP](https://github.com/yangweijie/clean-code-php) [為什么 Web 前端開發不拋棄 HTML 和 CSS，用純 JavaScript 開發？ - 知乎](https://www.zhihu.com/question/21445727) > HTML/CSS 都是聲明式的（聲明式、定義式編程） [命令式編程 vs 聲明式編程](https://mp.weixin.qq.com/s/UbF__kil0nhiFrhWevMV-A) > 命令式編程就是對硬件操作的抽象，程序員需要通過指令，精確的告訴計算機干什么事情。 > 聲明性是函數式編程的一個重要特點 ---- last update：2018-1-19 03:09:08