-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
508 lines (362 loc) · 35.8 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="zh-CN">
<title type="text">Wheegoo 的空间站</title>
<subtitle type="html">一个记录我的想法的地方</subtitle>
<updated>2021-12-03T20:42:05+08:00</updated>
<id>http://www.wheegoo.com/</id>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/" />
<link rel="self" type="application/atom+xml" href="http://www.wheegoo.com/atom.xml" />
<author>
<name>JinWei</name>
<uri>http://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights>
<generator uri="https://gohugo.io/" version="0.89.4">Hugo</generator>
<entry>
<title type="text">面向对象的设计模式（一）</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/" />
<id>http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/</id>
<updated>2021-11-29T20:30:50+08:00</updated>
<published>2021-11-29T20:30:50+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">软件设计的好坏评判标准之一是复用性。 变化与稳定 实际开发中最大的困难就是需求的多……
</summary>
<content type="html"><p><img src="http://www.wheegoo.com/image/design-pattern/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%AD%E6%96%87%E7%89%88%E5%B0%81%E9%9D%A2.jpg" alt="设计模式中文版封面.jpg"></p>
<p>软件设计的好坏评判标准之一是<strong>复用性</strong>。</p>
<h4 id="变化与稳定">变化与稳定</h4>
<p>实际开发中最大的困难就是需求的多变，而变化是软件复用的天敌。面向对象的设计最大的优势是“抵御变化”，注意不是“消灭变化”，<strong>而是把变化像小兔子一样锁在笼子里限制起来。</strong> 设计模式是软件设计中常见问题的典型解决方案。它们就像能根据需求进行调整的预制蓝图，可用于解决代码中反复出现的设计问题。<sup id="fnref:1"><a href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup> 设计模式与方法或库的使用方式不同，你很难直接在自己的程序中套用某个设计模式。 模式并不是一段特定的代码，而是解决特定问题的一般性理念。 你可以根据模式来实现符合自己程序实际所需的解决方案，所以最佳的实践设计模式的方法是重构到模式（Refactory to Patterns）。当然如果你非常熟悉各种模式的应用场景，也可以一上来就按照适当的设计模式去开发。</p>
<p>1994年，GoF在他们的书中总结了23种设计模式，此后人们又陆续发现了几十种面向对象的设计模式，“模式方法” 开始在其他程序开发领域中流行起来。 如今，在面向对象设计领域之外，人们也提出了许多其它的模式。设计模式是针对软件设计中常见问题的工具箱，其中的工具就是各种经过实践验证的解决方案。无疑这些设计模式提高了在团队中的沟通效率，我们只要说在这种情况下，你使用工厂模式就可以了，不需要过多的解释。 但是模式不是金科玉律，千万不要为了用模式而去套模式。在实际项目中应该实事求是的对项目进行调整。况且，模式也是会过时。以前广泛使用的模式可能在新一代的语言中内化为语言的设计理念。用设计模式的时候最重要的是分清工程里哪些是变化的，哪些是不变的。把变化的那部分用设计模式的方案来改造一下。试想两个极端：假如我们的工程里面所有模块都是变化的，那用什么设计模式都救不了你。再譬如，我们的工程里所有模块都是稳定的，那你也没有必要去用设计模式了，直接写代码就完事了。<sup id="fnref:2"><a href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup> 因此，分清变与不变最重要，设计模式主要着力点就是那些变化的地方。</p>
<h4 id="八大设计原则">八大设计原则</h4>
<p><strong>比模式更重要的是设计原则，下面介绍一下八大原则：</strong> <sup id="fnref:2"><a href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup></p>
<ol>
<li>依赖倒置原则（DIP）
<ul>
<li>高层模块（稳定）不应该依赖低层模块（变化），二者都应该依赖抽象（稳定）。</li>
<li>抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。</li>
</ul>
</li>
<li>开放封闭原则（OCP）
<ul>
<li>对扩展开放，对更改封闭。</li>
<li>类模块应该是可扩展的，但是不可修改。</li>
</ul>
</li>
<li>单一职责原则（SRP）
<ul>
<li>一个类应该仅有一个引起它变化的原因。</li>
<li>变化的方向隐含着类的责任。</li>
</ul>
</li>
<li>里氏替换原则（LSP）
<ul>
<li>子类必须能够替换它们的基类(IS-A)。</li>
<li>继承表达类型抽象。</li>
</ul>
</li>
<li>接口隔离原则（ISP）
<ul>
<li>不应该强迫客户程序依赖它们不用的方法。</li>
<li>接口应该小而完备。</li>
</ul>
</li>
<li>优先使用对象组合，而不是类继承
<ul>
<li>类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。</li>
<li>继承在某种程度上破坏了封装性，子类父类耦合度高，而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。</li>
</ul>
</li>
<li>封装变化点
<ul>
<li>使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。</li>
</ul>
</li>
<li>针对接口编程，而不是针对实现编程
<ul>
<li>不将变量类型声明为某个特定的具体类，而是声明为某个接口。</li>
<li>客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。</li>
<li>减少系统中各部分的依赖关系，从而实现“高内聚、松耦合”的类型设计方案。</li>
</ul>
</li>
</ol>
<h4 id="二十三个设计模式">二十三个设计模式</h4>
<table>
<thead>
<tr>
<th>模式名称</th>
<th>应用场景</th>
</tr>
</thead>
<tbody>
<tr>
<td>模板方法模式</td>
<td>常用于框架设计，例如 Windows 的 MFC</td>
</tr>
<tr>
<td>策略模式</td>
<td>代码中如果if else 很多的情况下考虑用这个模式</td>
</tr>
<tr>
<td>观察者模式</td>
<td>如果一个事件发生后，需要很多对象都能对此作出响应，则考虑观察者模式</td>
</tr>
<tr>
<td>装饰模式</td>
<td>动态（组合）地给一个对象增加一些额外的职责</td>
</tr>
<tr>
<td>桥模式</td>
<td>将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化</td>
</tr>
<tr>
<td>工厂方法</td>
<td>提供一种 “封装机制” 来避免客户程序和这种 “具体对象创建工作” 的紧耦合</td>
</tr>
<tr>
<td>抽象工厂</td>
<td>提供一个接口，让该接口负责创建一系列 “相关或者相互依赖的对象”，无需指定它们具体的类</td>
</tr>
<tr>
<td>构建者模式</td>
<td>Builder 模式主要用于 “分步骤构建一个复杂的对象”。在这其中 “分步骤” 是一个稳定的算法，而复杂对象的各个部分则经常变化</td>
</tr>
<tr>
<td>单件模式</td>
<td>软件系统中，有些特殊的类必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性，以及良好的效率</td>
</tr>
<tr>
<td>享元模式</td>
<td>运用共享技术有效的支持大量细粒度的对象</td>
</tr>
<tr>
<td>门面模式</td>
<td>为子系统中一组接口提供一致（稳定）的界面，facade模式定义了一个高层接口，这个接口使得这个子系统更容易的复用</td>
</tr>
<tr>
<td>代理模式</td>
<td>为其他对象提供一种代理以控制（隔离）对这个对象的访问</td>
</tr>
<tr>
<td>适配器模式</td>
<td>将一个类的接口转换成客户希望的另一个接口，一般用在新老模块共同复用的情况</td>
</tr>
<tr>
<td>中介模式</td>
<td>多个对象相互关联交互，对象之间维持一个复杂的引用关系。这种情况下，使用一种中介对象来管理对象的关联关系，避免紧耦合关系</td>
</tr>
<tr>
<td>状态模式</td>
<td>出现需要状态机的场景，此模式与策略模式有点相似</td>
</tr>
<tr>
<td>备忘录</td>
<td>此模式把对象的内部状态存储下来，由于现代语言都提供序列化的特性，此模式已过时</td>
</tr>
<tr>
<td>组合模式</td>
<td>将对象组合成树形结构以表示 “部分/整体” 的层次结构，使得用户对单个对象和组合对象的使用具有一致性。</td>
</tr>
<tr>
<td>迭代器</td>
<td>顺序访问聚合对象中的各个元素，而又不暴露该对象的内部表示。此模式现在已经被泛型编程中的迭代器取代了。</td>
</tr>
<tr>
<td>职责链模式</td>
<td>当某种请求发生时，需要多个模块对此请求作出处理，把各个模块串成链表，依次处理该请求</td>
</tr>
<tr>
<td>命令模式</td>
<td>将一个请求（行为）封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销操作。</td>
</tr>
<tr>
<td>访问器模式</td>
<td>某些类层次结构中需要常常要增加新的行为方法，如果直接在基类中修改，会给子类增加严重负担。 运行时透明的为各层次结构上的各个类添加新操作</td>
</tr>
<tr>
<td>解释器模式</td>
<td>某一个特定领域的问题比较复杂，将特定领域的问题表达为某个语法规则下的句子，然后构建一个解释器来解释句子，从而达到解决问题的目的</td>
</tr>
</tbody>
</table>
<h4 id="重构技法">重构技法</h4>
<ul>
<li>静态转动态</li>
<li>早绑定转晚绑定</li>
<li>继承转组合</li>
<li>编译时依赖转运行时依赖</li>
<li>紧耦合转松耦合</li>
</ul>
<h4 id="什么时候不用模式">什么时候不用模式</h4>
<ul>
<li>代码可读性很差时（这时应该首先改善代码的可读性，用模式救不了你，运用设计模式是在可读性问题解决后的事情）</li>
<li>需求理解很浅时</li>
<li>变化没有显现时 （不要提前过度设计，等到变化的方向明确时，设计模式才不会用错）</li>
<li>不是系统的关键依赖点</li>
<li>项目没有复用价值时 （一般外包公司的项目都是这种类型，所以外包公司的开发人员不关心设计模式）</li>
<li>项目即将发布时 （设计模式是为了更好的维护代码，没有必要在发布前还引入未知bug）</li>
</ul>
<h4 id="经验之谈">经验之谈</h4>
<ul>
<li>不要为了模式而模式</li>
<li>关注抽象类和接口</li>
<li>理清变化点和稳定点</li>
<li>审视依赖关系</li>
<li>要有 Framework 和 Application 的区分思维</li>
<li>良好的设计是演化的结果</li>
</ul>
<h4 id="最重要的事情">最重要的事情</h4>
<p>你可以忘记所有的设计模式，但是<strong>设计原则</strong>必须牢记于心。 所有的模式都是对着这八条原则，在不同的场景下推演出来的。
所有的模式实际上全部是依靠多态这个特性来实现的。
后面几个章节将介绍一下 C 语言开发中常用的设计模式，注意不是 C++ 语言。C 语言同样可以做到面向对象设计。只不过需要开发者自己做一些基础设施。</p>
<hr>
<section class="footnotes" role="doc-endnotes">
<hr>
<ol>
<li id="fn:1" role="doc-endnote">
<p><a href="https://refactoringguru.cn/design-patterns/">https://refactoringguru.cn/design-patterns/</a>&#160;<a href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/#fnref:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
<li id="fn:2" role="doc-endnote">
<p>李建忠《 C++ 设计模式》课件&#160;<a href="http://www.wheegoo.com/post/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%E4%B8%80/#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p>
</li>
</ol>
</section>
</content>
<category scheme="http://www.wheegoo.com/categories/%E8%AE%BE%E8%AE%A1/" term="设计" label="设计" />
<category scheme="http://www.wheegoo.com/tags/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/" term="设计模式" label="设计模式" />
</entry>
<entry>
<title type="text">关于金钱观</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E9%87%91%E9%92%B1%E8%A7%82/" />
<id>http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E9%87%91%E9%92%B1%E8%A7%82/</id>
<updated>2020-07-05T20:39:04+08:00</updated>
<published>2020-07-05T20:39:04+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">把吴军老师《见识》这本书中关于金钱观的金句摘录如下，温故知新： 钱是上帝存在你那……
</summary>
<content type="html"><p><img src="http://www.wheegoo.com/image/money/money.jpg" alt="money.jpg">
把吴军老师《见识》这本书中关于金钱观的金句摘录如下，温故知新：</p>
<ul>
<li>钱是上帝存在你那里的，不是给你的，回头你要还给他的。</li>
<li>钱只有花出去才是你的。</li>
<li>钱和任何东西，都是为了让你的生活过的更加好，而不是给你带来麻烦的。</li>
<li>钱是靠挣出来的，而不是靠省出来的，而挣钱的效率取决于一个人的气度。</li>
<li>钱是花不完的，但是可以迅速投（投资，投机）光。</li>
</ul>
<p>吴军老师对于金钱观中强调<strong>风险意识</strong>确实很令人印象深刻的。由于一两次的投资成功，忘记了风险。从长期来看，一定是投资失败。<em><strong>只要有一次失利，可能输光前面所有的盈利。</strong></em></p>
</content>
<category scheme="http://www.wheegoo.com/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/" term="读后感" label="读后感" />
<category scheme="http://www.wheegoo.com/tags/%E8%AE%A4%E7%9F%A5/" term="认知" label="认知" />
</entry>
<entry>
<title type="text">关于伪工作者</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E4%BC%AA%E5%B7%A5%E4%BD%9C%E8%80%85/" />
<id>http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E4%BC%AA%E5%B7%A5%E4%BD%9C%E8%80%85/</id>
<updated>2020-06-29T22:54:31+08:00</updated>
<published>2020-06-29T22:54:31+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">一封公司研发的内部邮件： 当前，公司处于快速发展的阶段，很多研发人员手上在做的事……
</summary>
<content type="html"><p>一封公司研发的内部邮件：</p>
<p>当前，公司处于快速发展的阶段，很多研发人员手上在做的事情很多，但是却成果不多。</p>
<p>第一，我想和大家聊聊关于“伪工作者的问题”和方法论的问题。在我们这个快速发展的IT领域，很多人都面临的问题“每天的事情很多，总也做不完”。由于我们行业的属性：迭代快速，问题和需求总是不断的产生，工作中很容易失去方向感。因此善于找到最重要的工作，并优先完成它们，这成为一个很重要的工作技能。在美国硅谷的公司里面，每天完成上述的事务性工作就被叫做pseudo worker，直译就叫伪工作者。这些人每天看上去好像也很忙，做的事情也可能是公司里面存在的，但是没有产生效果。我们公司里面如果这样的研发人员多了，公司在竞争中一定会处于下风。</p>
<p>硅谷的公司评价员工不在他看上去有多忙，写了多少行代码，而是看他工作产生了多大的效果。否则，再忙再累都会被淘汰。 我们各级的管理者首先要站到“做什么样的事情能让公司最大获益”的高度上去，这样才能在纷繁复杂的工作中找到那些对公司帮助最大的事情去做，而不是简单的应付老板布置的任务，然后交差。每位一线研发人员要明白积极工作（而不是消极完成任务），受益最大的首先是自己。反之，由于各种原因而消极的工作，慢慢的就会不自觉的就会沦成伪工作者。表象上看，他也任劳任怨的完成任务，但是重要且有难度有影响力的工作从来都不会碰。老板问起来的时候，他会说很认真的在工作，工作量也很饱满。至于为什么重要的事情没有做，他会说时间不够。久而久之，他实际上是自己坑自己。因为随着公司的发展，这一类的人一定会被边缘化，会淘汰。</p>
<p>那事务性的工作怎么办呢？是不是不要做呢？当然不是。而是自己要来理清思路，平庸的工程师一定是消极应对，但是优秀的工程师会从更高的视角去想如何把事务性工作自动化或者一劳永逸。当你焦虑的时候，不妨停下来想一想，站在对公司业务帮助最大的角度把事情理一下。先把效果最大的事情完成。</p>
<p>第二，我想讲讲奋斗的问题，习总书记说“幸福是奋斗出来的”。那什么是“奋斗”？ 华为把奋斗定义为：“为客户创造价值，以及为创造价值而做的准备工作都叫做奋斗，除此之外，再苦再累都不叫奋斗”。 我想我们公司的价值观和华为定义的是基本一致的。 那加班的目的是什么？ 加班是为了把事情做好，让自己的工作能产生“效果”，帮助公司获得最大的收益。 如果加班是为了熬时间，白天磨蹭做无关之事，晚上来起忙头，给领导看（事实上，领导很忙，没空看），那这样的加班毫无意义。 工作必须要产生“效果”。 公司评价研发人员的唯一标准是他创造了多少价值，有多少起到效果的成果物，为功劳买单，苦劳和辛劳都没用。所以去年年初我们试行的OKR的目标管理方法，要继续坚持。研发人员要走走心，为自己设立目标，能力欠缺时，管理者应该帮助他理清目标。所有的努力都是为了达到这个目标。这样才能和公司共同成长。</p>
<p>以下列举IT领域里面的为工作者的特点，大家自己对照一下。如果落入其中，就要警惕了！</p>
<ol>
<li>不能给公司带来较大收益又不能给用户带来改进和“升级”的工作都是伪工作；</li>
<li>坚持用旧方法而非效率更高的新方法；</li>
<li>事前不思考，事中乱试错；</li>
<li>做产品不讲究质量，测试后BUG多，上线后问题多，总花时间在找漏洞和补丁上。</li>
<li>不注重用有限的资源解决95%的问题，而是把大部分精力用于纠结不重要的5%的问题；</li>
<li>每次开会评审找一堆跟此不必要的人旁听，或总参加一些不必要的会议。</li>
</ol>
<p>最后，希望各位在公司高速向上发展的过程中，能跟上发展的脚步，方法和态度都同等重要，共同奋斗，共同成长！</p>
</content>
<category scheme="http://www.wheegoo.com/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/" term="读后感" label="读后感" />
</entry>
<entry>
<title type="text">开箱即用</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/%E5%BC%80%E7%AE%B1%E5%8D%B3%E7%94%A8/" />
<id>http://www.wheegoo.com/post/%E5%BC%80%E7%AE%B1%E5%8D%B3%E7%94%A8/</id>
<updated>2020-06-25T19:49:33+08:00</updated>
<published>2020-06-25T19:49:33+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">我有些开箱即用的感悟想记录下来，分两个方面来讨论： 产品的开箱即用 技术的开箱即用……
</summary>
<content type="html"><figure><img src="http://www.wheegoo.com/image/out-of-the-box/ootb.jpg"/>
</figure>
<p>我有些开箱即用的感悟想记录下来，分两个方面来讨论：</p>
<ol>
<li>产品的开箱即用</li>
<li>技术的开箱即用</li>
</ol>
<h5 id="产品开箱即用">产品开箱即用</h5>
<p>在书上看好很多人都讲，不要给用户太多的选择，其实用户也不知道想要什么，所以只要产品经理定义好产品就好了。这个话只能说对了一半。</p>
<p><strong>没有选择</strong>是开箱即用在产品上的一种体现，我认为的开箱即用其实本质上是为了<strong>降低用户的心智负担</strong>。在产品范畴，&quot;选择&quot;本来就是一个困难的事情，如果一个事情有5个选项，砍掉3项选择，用户的幸福感和满意度立马就会提升。把选择权给用户看似是尊重用户的选择，实质上是对用户的不负责任。为什么这样讲？ 试想本来应该产品设计人员去深度思考的事情，确定产品的规格和参数。现在把这些事情让用户在冗杂的信息中自己去辨别，这不是推卸责任又是什么？但是不是选择越少越好呢？也肯定不是。好的产品设计我觉得应该是洞悉人性的。适度的选择给予自由，多了反而迷茫。</p>
<p>从另外一个角度讲：体会一个场景，你兴匆匆的买了一个想了好久的产品回家，急忙要打开试用，结果搞半天没有用起来。或者拿到手后，发现要看一大堆说明书，简单的操作并无法让产品工作，那种心情会有多悲催？我们设计产品时一定要有一条路径让用户简单的操作就能使得产品工作起来。等到产品工作起来后，再慢慢接受更加高级功能的折腾，大多数用户都能接受。总结一下，产品在用户选择和用户使用前的准备必须要降低到最小。</p>
<h5 id="技术开箱即用">技术开箱即用</h5>
<p>技术上的开箱即用就比较好理解了。举个例子更容易理解，如果有个开源项目不能以默认的配置直接跑出效果让我看到，恐怕我是不会再有兴趣去折腾这个项目了。如果出现编译错误那就更加没有耐心去排查问题了。我宁可扔掉此项目重新去选一个工程也不会去折腾一个编译就出错的工程。所以我一般做库工程，总是会把最小可用的配置全部包含。不让用户去自己一个一个折腾。或者提供一个脚本能让用户一次性把所有依赖都全部安装好。技术上同样要给我的用户提供开箱即用的体验。</p>
</content>
<category scheme="http://www.wheegoo.com/categories/%E5%BF%83%E5%BE%97/" term="心得" label="心得" />
</entry>
<entry>
<title type="text">关于吴军老师的书</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E5%90%B4%E5%86%9B%E8%80%81%E5%B8%88%E7%9A%84%E4%B9%A6/" />
<id>http://www.wheegoo.com/post/%E5%85%B3%E4%BA%8E%E5%90%B4%E5%86%9B%E8%80%81%E5%B8%88%E7%9A%84%E4%B9%A6/</id>
<updated>2020-06-21T09:51:07+08:00</updated>
<published>2020-06-21T09:51:07+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">我比较喜欢吴军老师的书，最早接触到吴军老师的书是《浪潮之颠》，那时候估计刚刚出……
</summary>
<content type="html"><figure><img src="http://www.wheegoo.com/image/WuJunBook/cover.jpeg"/>
</figure>
<p>我比较喜欢吴军老师的书，最早接触到吴军老师的书是《浪潮之颠》，那时候估计刚刚出版。我在当当上看到这本书的介绍，毫不犹豫的就买下了，三天功夫一口气看完。 不得不佩服吴军老师行文的功力，阅读感受非常流畅，就像一位讲故事的人面对面的在和你聊天。吴军老师的视野十分宽阔，把整个硅谷的兴衰史娓娓道来。颠覆式创新早在美国50年代就已经开始了，对 IT 从业人员有很大的启发。</p>
<p>接着又买了他的《硅谷之谜》，书虽然不厚三百页左右。但是书中的几个观点颠覆我之前对管理的认知。例如“工程师等级”理论，工程师划分成五等，每一等之间的差距是一个数量级。重要岗位必须花重金请顶尖高手。这个理念对我后面在招聘软件开发人员上有莫大的帮助，以至于我们团队每个人都传阅了一遍。书中还提到，现在的公司已经从上个世纪的提前规划转变成实时负反馈的系统。这是意识形态上的转换。</p>
<p>然后又买了《大学之路》和《文明之光》，《大学之路》书有上下册，介绍各个美国大学的思想精神，确实和国内的教学理念相差太大。现在国内条件好起来了，很多方面也可以学习美国学的像一点。但是其中的软实力恐怕不是二十年内能马上学到的。《文明之光》估计花了吴军老师很多时间，整整四册把整个东西方的历史都讲了一遍。我利用中午休息时间断断续续的看。同样一贯的行文非常流畅。</p>
<p>最近，在网上看到吴军老师出了新书 “认知三部曲”，<strong>《见识》、《态度》、《格局》</strong> 都买了。这套书确实有营养。以前国外有个人提过一个观点叫做 “刻意练习”，有的人虽然读书无数，但是却不见什么长进，或者长进太慢。 有些人大字不识几个，却能从寥寥信息中获取养分。究其原因，读书读书，书里面写的都是对的，但不是你的。没有反思、没有咀嚼的看书，只是一个人肉翻书机。 我从小就喜欢看书，但是长进不大，上面其实说的就是我的少年时代。 不光是我，大多数人读书不能算做读书，只能算翻书。 回想原因：第一不会选书，小时侯认为能印出来的东西都是好的； 第二不会反思，我读了这本书对我产生什么样的影响？ 常常看完书后觉得很有成就感：“又看完了一本书”。 所以这也是我写博客的另外一个原因，把领悟到的东西记录下来，时常能方便的自己看看。书不在看多少，而在领悟后对自己产生多少影响，如果没有不如不读。</p>
</content>
<category scheme="http://www.wheegoo.com/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/" term="读后感" label="读后感" />
<category scheme="http://www.wheegoo.com/tags/%E8%AF%BB%E4%B9%A6/" term="读书" label="读书" />
</entry>
<entry>
<title type="text">第一篇</title>
<link rel="alternate" type="text/html" href="http://www.wheegoo.com/post/first/" />
<id>http://www.wheegoo.com/post/first/</id>
<updated>2021-11-24T13:52:51+08:00</updated>
<published>2020-06-20T16:45:08+08:00</published>
<author>
<name>JinWei</name>
<uri>https://www.wheegoo.com/</uri>
<email>[email protected]</email>
</author>
<rights>[CC BY-NC-SA 4.0](https://creativecommons.org/licenses/by-nc-sa/4.0/deed.zh)</rights><summary type="html">开博第一篇写点什么呢？ 就讲讲我这个域名的来历吧，2006 年的时候，公司里面大多……
</summary>
<content type="html"><figure><img src="http://www.wheegoo.com/image/first/pfizer.jpg"/>
</figure>
<p>开博第一篇写点什么呢？</p>
<p>就讲讲我这个域名的来历吧，2006 年的时候，公司里面大多数人都叫我伟哥，其实我一开始听着这个名字很不爽的，怎么就和一种药联系起来了呢？我屡次想打破这个困局，无奈天天被人这样叫，想让大家改口都改不过来，叫着叫着，貌似还挺顺口的。算了，形势比人强，就这样作为了我的绰号。</p>
<p>那个时候博客还是个稀奇的东西，尤其看到制作精良和独立域名的博客，都会好好收藏且拜读。后来，我就想注册一个和我名字有点关系的域名。好的域名基本都没有希望，那就挑难听的吧，比如伟哥这样的名字。然后我就用 “www.wego.com” 去搜索，当然这么短小精悍的域名轮不到我。 接着 “www.weegoo.com”，同样也被注册了。然后就发挥我造词的功力了。 英语里面 wh 和 w 的发音是一样的。就加一个 h 试试看。“www.wheegoo.com” 果然没有被注册。然后我就把邮箱和域名都一口气注册了。先不管干啥用，占个坑再说。十多年以后总想弄个网站主页之类的东西，刚好就把这个域名给用上了。</p>
</content>
</entry>
</feed>