The Pragmatic Programmer :From Journeyman to Master

TIPS
1.Care About Your Craft
2.Think About Your Work
3.Provide Options，Don't Make Lame Excuses
4.Don't Live with Broken Windows
5.Be A Catalyst of Change
6.Remember The Big Picture
7.Make Quality a Requirements Issue
8.Invest Regularly in Your Knowledge Portfolio
9.Critically Analyze What You Read and Hear
10.It's both What You Say and the Way you Say it
11.Don’t repeat yourself
12.MAKE It Easy To Reuse
13.Eliminate Effects Between Unrelated Things
14.There are No Final Decisions
15.Use Tracer Bullets to Find the Target
16.Prototype to Learn
17.Program To the Problem domain
18.Estimate to Avoid Surprises
19.Iterate the Schedule with the Code
20.Keep Knowledge in Plain Text
21.Use the Power of Command Shells
22.Use a Single Editor Well
23.Always Use Source Code Control
24.Fix the Problems, Not the Blame
25.Don't Panic
26."Select" Isn't Broken
27.Don't Assume it, Prove it
28.Learning a Text Manipulation Language
29.Write Code that Write Code
30.U can't Write Perfect Software
31.Design with Contracts
32.Crash Early
33.If It Can't Happen ，Use Assertions To Ensure That It Won't
34.Use Exceptions for Exceptional Problems
35.Finish What U Start
36.Minimize Coupling Between Modules
37.Configture ,Don’t Integrate
38.Put Abstractions in Code, Details in Metadata
39.Analyze Workflow to Improve Concurrency
40.Design Using Services
41.Always Design for Concurrency
42.Seperate Views from Models
43.Use Blackboards to Coordinate Workflow
44.Estimate the Order of Your Algorithms
45.Test Your Estimates
46.Refactor Early,Refactor Often
47.Design to Test
48.Test Your Software Or Your Users Will
49.Don't Use the Wizard Code You Don't Understand
50.Don't gather Requirement，Dig for Them
51.Work Like A User To Think like A User
52.Abstractions Live Longer than Details
53.Use a Project Glossary
54.Don't Think Outside the box，-Find the box
55.Listen to Nagging Doubts - Start When You're Ready
56.Something are better Done than Described
57.Don't be a Slave to Formal Methods
58.Costly Tools Don't Produce Better Design
59.Organize Teams Around Functionality
60.Orgnize Teams Around Functionality
61.Don't Use Manual Procedures
62.Test Early, Test often. Test Automatically.
63.Coding Ain't Done,Till All The Test Done.
64.Use Saboteurs To Test Your Testing.
65.Test State Coverage, Not Code Coverage.
66.Find Bugs Once
67.English Is Just A Programming Language.
68.Gently Exceed Your Users' Expectations
69.Build Document In, Don't Bolt It On.
70.Sign Your Work

Words
知识上的投资总能得到最好的回报
——本杰明 * 富兰克林
我相信被打量比被忽略要好
——Mae West
语言的界限就是一个人的世界的界限
——维特根斯坦
进步远非由变化组成，而是取决于好记性。不能记住过去的人，被判重复过去
——George Santayana
最容易欺骗的人事一个人自己
——Edward Bulwer-Lytton
每个人都确实要对你不利时，偏执就是一个好主意
——Woody Allen
没有什么比常识和坦率更让人感到惊讶
——拉尔夫*沃尔多*爱默生
我把你带进这个世界，我也可以把你赶出去，那没有我影响，我要再造另一个你
——Bill Cosby
好篱笆促成好邻居
——罗伯特*弗罗斯特
再多的天才也无法胜过对细节的专注
——Levy's English Law
不要假定，要证明
——佚名
按照合约设计
——佚名
完美，不是在没有什么需要增加、而是在没有什么需要去掉的时候达到的
——Antoine de St.Exupery

正交性
在计算机技术中，正交性表示某种不相依赖性或者是解耦性。如果两个或者更多事物中的一个发生变化，不会影响其它事物，这些事物就是正交的。在设计良好的系统中，数据库代码和用户界面是正交的：你可以改动界面，而不影响数据库；更换数据库，而不用改动界面。

重构
养成不断地批判的对待自己代码的习惯。寻找任何重新进行组织、以改善其结构和正交性的机会。这个过程叫做重构（Refactoring）

薛定谔的猫
假定在一个密封的盒子有一只猫和一个放射性的粒子。这个粒子正好有百分之五十的机会分裂。如果裂变了，猫就会被杀死，反之则不会。猫是死是活？按照理论，正确的答案是“都对”，每当有两种可能结果的亚核反应发生时，宇宙就会被克隆。只有当你打开盒子的时候才知道你处于哪个宇宙里。

事件
一旦你基于责任把程序划分为不同的模块，你就有了新的问题，在运行时，对象之间怎样相互交互，你怎样理解逻辑，怎样同步不同对象中的状态的变化，但是我们不想让它们相互知道的太多，要像TheBox一样，只听到它想听到的东西，事件EVENTS 就是一个特殊的消息，说明刚刚发生了什么有趣的事情，我们可以用事件把某个对象的状态变化通知发送给可能感兴趣的其他对象。事件发送者不需要对接受者有任何的了解，可以存在多个接收者，每个接受者都专注于自己的“议事日程“。

MVC
我们创建一个模型--数据本身，以及用于对其进行操纵的常用操作。然后我们创建不同的视图，以不同的方式显示数据：作为电子表格、作为图表、或是在总计框中。每个视图都有自己的控制器。这是位于Model-View-Controller（MVC）惯用手法之后的关键概念：既让模型与表示模型Gui分离，也让模型与管理视图的控件分离。这样做可有许多有趣的可能性。你可以支持同一数据模型的多个视图。你可以在许多不同的数据模型上使用公用的查看器。你甚至还可以支持多个控制器，以提供非传统的输入机制。

算法速率
可以有许多常识估算估算许多基本算法的阶：简单循环 O(n)，嵌套循环 O(m x n),分而治之 O(nln(n)) ,二分法O(ln(n)), 组合 时间可能会失去控制。

软件测试
一旦某个软件部署以后，你常常需要对其进行测试--在现实世界的数据正留过它的血脉时。我们可以提供模块的内部状态的各种视图，而不适用调试器。含有跟踪信息的日志文件就是这样一种机制。日志文件的格式应该正规、一致。你或许需要自动解析它们，以推断程序所用时间或逻辑路径。了解程序运行中的代码的内部状况的另外一种机制是“热键”序列。按下特定的键组合，就会弹出一个诊断控制窗口，显示状态消息等信息。对于更大更复杂的服务器代码，提供其内部操作的内部视图是一种漂亮技术是使用内建的Web服务器。任何人都可以让Web浏览器指向应用的HTTP端口，并看到内部状态、日志条目、甚至可能是某种调试控制面板。

需求
制作需求文档时的一大危险就是太过具体。好的需求文档会保持抽象。在涉及需求的地方，最简单、能够准确的反映商业需要的陈述是最好的。需求不是架构。需求不是设计。也不是用户界面。需求是需要。

反馈会训练你的下意识和反应能力

转载于:https://www.cnblogs.com/Nagisa-Saku/p/5706596.html