Thursday, August 13, 2015

Effective Programming: More Than Writing Code - Book Notes



读书:《高效能程序员的修炼》
培养写作习惯
不断练习
果想要在某方面有所提高,最好的方法就是勤加练习。但是,如果你只骨折埋头写代码,练讨论、反思或者学习的时间都没有,将得不到真正的进步。必须在磨炼工艺与思考如何提高工艺之间找到一个适当的平衡点。

爱立信提出,重要的并不是经验本身,而是“努力的学习”,也就是要不断地挑战自身能力之外的东西。一些狂热的爱好者花费了大量的时间去下棋、打高尔夫球或者玩乐器,但他们可能始终停留在业余水平上,而一个训练有素的学生却可以在相对较短的时间里超越他们,原因就在这里。值得注意的是,在提高水平方面,花费在下棋上的大量时间(即使参加各种比赛)似乎还是比不过专门的训练来得更为有效。训练的主要价值在于发现弱点,并有针对性地进行提高。
所谓“努力的学习”,倒不如说是“略微吃力的学习”。我们需要不断挑战我们能力之外的东西,但是如果太难的话,往往会受挫。如果我们将自己的知识技能简单划分为“舒适区”(游刃有余)和“不适区”(寸步难行),那么我们需要练习的就是位于“舒适区”和“不适区”的地方,不断挑战自己的极限,不断扩大“舒适区”。但是最难的其实不是练习,而是远离“舒适区”。
一、永远都是你的错
你写的代码任何时候出了问题都是你的错。这不是一个绝对的论断,而是一个建议。当你的代码出问题的时候,希望你的脑海中第一时间能出现这句话。相信每个人都会有经验,就不细说了。
二、大道至简
“你永远都有简化的空间”。不管是写作还是写代码的时候都请记住这句话。对一个代码进行评价,作者提出了如下几个方面:1.代码简洁度;2.功能完整性;3.执行速度;4.编码花费时间;5.健壮性;6.灵活性。简洁一直是很多人奉行的原则,最有名的是乔布斯提出的“至繁归于至简”,国内很多人可能也是这个原因开始标称这是自己的原则。但是大部分也只是标称罢了。
三、避免写注释
不得不承认每个程序员都讨厌写注释,但是很多人又在告诫我们写注释的好处,不写注释的坏处,比如代码可读性什么的。但是你有没有想过这个问题:代码可读性究竟是有代码自己决定的,还是由注释决定的呢?不要试图用战术的勤劳掩盖战略上的懒惰。你应该总是专注于编写代码,而忘了还有注释这种东西的存在。这会迫使你竭尽全力使用最简单、最直白、最能进行自我说明的方式把代码写出业。将注释融化到函数名和变量名中。Steve Yegge指出初级开发者与高级之间的关键区别:初级开发者依靠注释来讲故事,而实际上他们应该依靠代码本身。
四、学会读源代码
在沟通这个复杂的领域里,写出能让人类领会并理解的连贯段落比敲出几行不至于让解释器或者编译器“呕吐”的软件代码要难得多。不管文档上怎么说,源代码才是最终的事实,是你所有找到的最好的、最确定的、最新的文档。
真正的骇客世界只有一个简单的事实:如果一个软件在我的机器上运行,那它就是我的软件。我必须把它弄明白。从源代码开始构建是一条必须遵循的原则。
五、像橡皮鸭求助
相信很多人都听说过橡皮鸭调试方法。开发人员发现代码出现问题,将问题描述给橡皮鸭。就在描述的过程中,你可能会发现问题的所在。这个和我前一篇说的很像。比如stackoverflow为什么要重视提问题?因为就在你提问题的时候,你需要将问题的脉络说清楚给别人听,这个过程你不仅仅是在向别人描述,也是说给自己听。
六、创新以人为本
这个已经被国内人说烂了。你可能不以为然。那么我们换一种说法:执行力比创新更重要。但是我觉得创新也是很重要的,任何时候。只是创新落地的时候需要强大的执行力。现在在国内一种更搞笑的是被一群连创意都提不出来的人拿来YY,甚至挖苦别人,真是哭笑不得。
七、你的团队能通过电梯测试吗
电梯测试是说在乘坐电梯的短暂时间向旁边的人解释介绍你自己或者解释清楚你的问题。时间很短,这就需要我们将焦点集中在重要的地方。对于程序员,不能为了编码而编码。对于所有人,不能为了学习而学习,你需要有明确的目标,不然学习也不过是另一种浪费时间罢了。
八、性能致胜

Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts