分享一些獨到的編程見解

你也許會認同并開始改變
服務器君一共花費了64.041 ms進行了4次數據庫查詢,努力地為您提供了這個頁面。
試試閱讀模式?希望聽取您的建議
  1. The only “best practice” you should be using all the time is “Use Your Brain”.
  2. 唯一的“Best Practice”并不是使用各種各樣被前人總結過的各種設計方法、模式,框架,那些著名的方法、模式、框架只代碼贊同他們的人多,并不代表他們適合你,你應該更多的去使用你的大腦,獨立地思考那些方法、模式、框架出現的原因和其背后的想法和思想,那才是“best practice”。事實上來說,那些所謂的“Best Practice”只不過是限制那些糟糕的程序員們的破壞力。

  3. Programmers who don’t code in their spare time for fun will never become as good as those that do.
  4. 如果你對編程沒有感到一種快樂,沒有在你空閑的時候去以一種的娛樂方式去生活,無論是編程,還是運動,還是去旅游,那么你只不過是在應付你的工作,無時無刻不扎在程序堆中,這樣下來,就算是你是一個非常聰明,非常有才華的人,你也不會成為一個優秀的編程員,要么只會平平凡凡,要么只會整天扎在技術中成為書呆子。當然,這個觀點是有爭議,熱情和能力的差距也是很大的。不過我們可以從中汲取其正面的觀點。

  5. Most comments in code are in fact a pernicious form of code duplication.
  6. 注釋應該是注釋Why,而不是How和What,參看《惹惱程序員的十件事》,代碼告訴你How,而注釋應該告訴你Why。但大多數的程序并不知道什么是好的注釋,那些注釋其實和code是重復的,毫無意義。

  7. XML is highly overrated
  8. XML可能被高估了。XML對于Web上的應用是不錯的,但是我們把其用到了各種地方,好像沒有XML,我們都不會編程了。

  9. Not all programmers are created equal
  10. 這是那些junior經理或是流程愛犯的錯,他們總是認為,DeveloperA == DeveloperB,只要他們的title一樣,他們以為他們的能力、工作速度、解決問題的方法,掌握的技能等等都是一樣的。呵呵。更扯的是,在某些時候,就算是最差的程序員,他們也會認為其比別人強十倍,這就是現代的SB管理。

  11. "Googling it" is okay!
  12. Google只會給你知識,并不會教給你技能。那里只有“魚”,沒有“漁”,過度的使用Google,只會讓你越來越離不開他,你越來越去要去立馬告訴你答案,而你越來越不會自己去思考,自己去探索,去專研。如果KFC快餐是垃圾食品對我們的身體沒有好處,那么使用Google也一種快餐文化對我們的智力發展大大的沒有好處。

  13. If you only know one language, no matter how well you know it, you’re not a great programmer.
  14. 如果你只懂一種語言,準確的說,如果你只懂一類語類,如:Java和C#,PHP和Perl,那么,你將會被局限起來,只有了解了各種各樣的語言,了解了不同語言的不同方法 ,你才會有比較,只有了比較,你才會明白各種語言的長處和短處,才會讓你有更為成熟的觀點,而且不整天和別的程序在網上斗嘴爭論是Windows好還是Unix好,是C好還是C++好,有這點工夫能干好多事了。世界因為不同而精彩,只知道事物的一面是有害的。

  15. Your job is to put yourself out of work.
  16. 你的工作不是保守,那種教會徒弟,餓死師父的想法,不但是相當短淺的,而且還是相當腦殘的。因為,在計算機世界里,你掌握的老技術越多,你就越沒用,因為技術更新的太快。你對工作越保守,這個工作就越來越離不開你,你就越不越不能抽身去學新的東西,你也就越來越OUT了。記住:If you can’t be replaced then you can’t be promoted!

  17. Design patterns are hurting good design more than they’re helping it.
  18. 很多程序員把設計模式奉為天神,他們過度的追求設計模式以至都都忘了需求是什么,結果整個系統設計被設計模式搞得亂七八糟,我們叫這種編程為“設計模式驅動編程”,正如第一點所說,如果你不懂得用自己的大腦思考的話,知其然,不知所以然的話,那么你不但得不到其好處,反而受其所累。

  19. Unit Testing won’t help you write good code
  20. 準確地說,我們可以認為這是Test-Driven開發,其實,這種開發就是先寫unit test case,這樣的開發方式的主要目的是,為了防止你不會因為一個改動而引入Bug,但這并不會讓你能寫出更好的代碼。這只會讓你寫出不會出錯的代碼。同第一點,這樣的方法,只不過是防止糟糕的程序員,而并不是讓程序員或代碼質量更有長進。反而,通過Unit Test會為程序員的為自己代碼做辯解的一種托辭。

本文地址:http://www.snpmgr.live/librarys/veda/detail/629,歡迎訪問原出處。

不打個分嗎?

轉載隨意,但請帶上本文地址:

http://www.snpmgr.live/librarys/veda/detail/629

如果你認為這篇文章值得更多人閱讀,歡迎使用下面的分享功能。
小提示:您可以按快捷鍵 Ctrl + D,或點此 加入收藏

閱讀一百本計算機著作吧,少年

很多人覺得自己技術進步很慢,學習效率低,我覺得一個重要原因是看的書少了。多少是多呢?起碼得看3、4、5、6米吧。給個具體的數量,那就100本書吧。很多人知識結構不好而且不系統,因為在特定領域有一個足夠量的知識量+足夠良好的知識結構,系統化以后就足以應對大量未曾遇到過的問題。

奉勸自學者:構建特定領域的知識結構體系的路徑中再也沒有比學習該專業的專業課程更好的了。如果我的知識結構體系足以囊括面試官的大部分甚至吞并他的知識結構體系的話,讀到他言語中的一個詞我們就已經知道他要表達什么,我們可以讓他坐“上位”畢竟他是面試官,但是在知識結構體系以及心理上我們就居高臨下。

所以,閱讀一百本計算機著作吧,少年!

《C專家編程》 林登 (LinDen.P.V.D) (作者), 徐波 (譯者)

《C專家編程》展示了最優秀的C程序員所使用的編碼技巧,并專門開辟了一章對C++的基礎知識進行了介紹。書中C的歷史、語言特性、聲明、數組、指針、鏈接、運行時、內存以及如何進一步學習C++等問題進行了細致的講解和深入的分析。全書擷取幾十個實例進行講解,對C程序員具有非常高的實用價值。《C專家編程》可以幫助有一定經驗的C程序員成為C編程方面的專家,對于具備相當的C語言基礎的程序員,《C專家編程》可以幫助他們站在C的高度了解和學習C++。

更多計算機寶庫...

燃烧吧足球登陆