博客园_随遇而安，细水长流

ASP.NET处理301重定向方法

2012-04-12T03:11:00Z

关于百度等搜索引擎对于是否带"www"前缀的域名的识别问题：即搜索引擎会将www.abc.com和abc.com识别为不同的两个域名，这样做的后果就是分散了对网站的关注度，不利于网站的宣传和推广。

仅仅是通过Response.Redirect方法来重定向该连接，虽然可以将连接进行重定向，但是无法解决搜索引擎的识别分散问题的；此问题可通过301重定向来进行解决，具体在ASP.NET中可通过如下方法来处理：

1         private void CheckTopDomainName(HttpContext context)
2         {
3             Uri url = context.Request.Url;
4             string host = url.Host.ToLower();
5
6             int count = host.Split('.').Length;
7             bool doubleDomainName = host.EndsWith(".com.cn", StringComparison.CurrentCultureIgnoreCase) ||
8                 host.EndsWith(".net.cn", StringComparison.CurrentCultureIgnoreCase) ||
9                 host.EndsWith(".gov.cn", StringComparison.CurrentCultureIgnoreCase) ||
10                 host.EndsWith(".org.cn", StringComparison.CurrentCultureIgnoreCase);
11
12             if (count == 2 || (count == 3 && doubleDomainName))
13             {
14                 context.Response.Status = "301 Moved Permanently";
15                 // 避免替换掉后面的参数中的域名
16                 context.Response.AddHeader(
17                     "Location",
18                     url.AbsoluteUri.Replace(
19                         string.Format("http://{0}", host),
20                         string.Format("http://www.{0}", host)
21                         )
22                     );
23             }

24 }

本文链接

这两天自己写个小应用的感受

2011-08-31T13:02:00Z

这两天在写个小应用，主要是web上实现对各种琐事事情记录这方面的功能，倒是颇有一点儿小感受，正好也好久没有写点儿东东，总觉得有种小小的罪恶感~

最大的一个感受就是要“简单”：其实，以前自己也看过很多这方面的文章和书籍，但那只是一种自己比较认同的观念，但却没有切身的体会，这次算是小小的体验了一把。一开始，自己虽然也是先大致勾画了应用的基本界面和功能，但在实现的过程中，以及和木瓜同学的交流中，发现其实很多东东都是“冗余的”，自己最应该关注的应该是“这东西到底能帮我干啥？”，于是，把那些自己认为有趣的，必备的，花哨的功能都做了个减法，结合自己以前的工作体会，往往是做加法的时候很容易，也很自然，但是做减法的时候往往要耗费N多脑细胞，所以一般情况下，是很少会涉及这方面的工作的，尤其是在任务的后期和维护阶段，加法是一种必然，已经很难在做减法了，因为成本甚巨~！

ok，应用简单了一些了，只保留了最基本的功能，因为我希望它能帮助我简化一些工作内容，这样作为初始也就足够了，因为做加法的时候还没有到哦~

紧接着，自己又被另一个问题缠住了：应该保证怎么样的实现步伐呢？所谓视线步伐，也就是采取怎么样的一个开发过程，因为就一个人嘛，是不是只有很多个人一起开发的时候，这个问题才有必要？看来应该不是，自己一个人的时候，尤其要注意这方面的问题，要保证自己有一个主要的通道！要能分辨出哪些具体的功能细节是和主体功能相关的，是会直接影响用户的功能使用的，这些就是最重要，最优先要解决的！此外，还有一些细节是锦上添花，或者是进一步完善使用体验的，可以稍微往后放~

再有一点，就是一定要保证尽量块地让你的应用开始干活！之所以要尽可能地块，那是因为哪怕是最简单的功能，它也是对你之前工作的一个小小肯定，保证一步一步地节奏，而不是一下子想要咋样咋样，这本身就是一种健康合理的开发方式，所以，多少可以理解为是有一点心理暗示方面的作用，同时，能干活的功能模块也会不断地提醒自己梳理他们之间的关系，从而做一些优化的工作~

说了几个大一点的东东，这里将点具体的，其实，发现在实现功能的过程中，总能有各种各样的点子冒出来，相反，如果坐在那里想，反而会变得毫无进展，或许，这就是实践的魅力吧！事先的思考是非常必要的，但要尽量控制不要陷入冥思苦想，有个大概的思路和框架，那就去实现它吧！或许，当你真的做了自己的第一版之后，会惊奇地发现，和自己起先想的竟然相差那么多！这都是很正常的，因为实现的过程，也是一个不断思考和琢磨的过程，过往的经验能够给予我们灵感，写代码同样能够给予我们灵感！

总想写点儿有逻辑的东东，看看上面，貌似也是想到哪里写到那里了~那就这样吧，也算是一个小小的记录~

本文链接

改进C#代码之25：用事件模式实现通知

2011-08-18T06:35:00Z

事件提供了一种标准的机制来通知监听者。.NET的事件模式使用了事件语法来实现观察者模式。任意数量的客户对象都可以将自己的处理函数注册到事件上，然后处理这些事件。这些客户对象不需要再编译期就给出。时间也不必非要有订阅者才能正常工作。在C#中使用事件可以降低发送者和可能的通知接受者之间的耦合。发送者可以完全独立于接收者进行开发。事件是实现广播类型行为信息的标准方式。

下面按照使用场景的不同，简单列举三种事件模式的实现方式：

0. 公共代码部分

1 /// <summary>

2     /// 日志参数类
3     /// </summary>
4     public class LoggerEventArgs : EventArgs
5     {
6         public string Message { get; private set; }
7         public int Priority { get; private set; }
8
9         public LoggerEventArgs(int p, string m)
10         {
11             Priority = p;
12             Message = m;
13         }
14     }

1. 最常用方式

1 /// <summary>

2     /// 日志类（第一版）：最常见的使用方法，适用于单一调用者情况。
3     /// </summary>
4     public class Logger
5     {
6         /// <summary>
7         /// 内部事件句柄
8         /// </summary>
9         public event EventHandler<LoggerEventArgs> Log;
10         /// <summary>
11         /// 内部日志单键实例
12         /// </summary>
13         private static Logger theOnly = null;
14         public static Logger Singleton
15         {
16             get { return theOnly; }
17         }
18
19         private Logger()
20         { }
21
22         static Logger()
23         {
24             theOnly = new Logger();
25         }
26
27         /// <summary>
28         /// 添加日志信息
29         /// </summary>
30         /// <param name="priority"></param>
31         /// <param name="msg"></param>
32         public void AddMsg(int priority, string msg)
33         {
34             // 该临时变量可预防多线程环境中的竞争条件
35             EventHandler<LoggerEventArgs> l = Log;
36             // 执行事件方法
37             if (l != null)
38             {
39                 l(this, new LoggerEventArgs(priority, msg));
40             }
41         }
42     }

2. 针对事件数量多的情况

1 /// <summary>

2     /// 日志类（第二版）：适用于包含事件数量非常多的情况，即添加了一个事件容器，避免因多事件导致的设计臃肿。
3     /// </summary>
4     public sealed class Logger
5     {
6         /// <summary>
7         /// 事件容器
8         /// </summary>
9         private static System.ComponentModel.EventHandlerList Handlers = new System.ComponentModel.EventHandlerList();
10
11         /// <summary>
12         /// 添加事件
13         /// </summary>
14         /// <param name="system"></param>
15         /// <param name="ev"></param>
16         public static void AddLogger(string system, EventHandler<LoggerEventArgs> ev)
17         {
18             Handlers.AddHandler(system, ev);
19         }
20
21         /// <summary>
22         /// 清除事件
23         /// </summary>
24         /// <param name="system"></param>
25         /// <param name="ev"></param>
26         public static void RemoveLogger(string system, EventHandler<LoggerEventArgs> ev)
27         {
28             Handlers.RemoveHandler(system, ev);
29         }
30
31         /// <summary>
32         /// 添加日志信息
33         /// </summary>
34         /// <param name="system"></param>
35         /// <param name="priority"></param>
36         /// <param name="msg"></param>
37         public static void AddMsg(string system, int priority, string msg)
38         {
39             if (!string.IsNullOrEmpty(system))
40             {
41                 // 根据key获取相应的事件
42                 EventHandler<LoggerEventArgs> l = Handlers[system] as EventHandler<LoggerEventArgs>;
43                 // 事件参数
44                 LoggerEventArgs args = new LoggerEventArgs(priority, msg);
45                 if (l != null)
46                 {
47                     l(null, args);
48                 }
49                 // 若不存在，执行默认事件
50                 l = Handlers[""] as EventHandler<LoggerEventArgs>;
51                 if (l != null)
52                 {
53                     l(null, args);
54                 }
55             }
56         }
57     }

3. 针对事件数量多的情况（泛型版本）

1 /// <summary>

2     /// 日志类（第三版）：适用于多事件情况的泛型版本。主要优势是降低了转型/转换的工作，但增加了一些用来映射事件的代码。
3     /// </summary>
4     public sealed class Logger
5     {
6         /// <summary>
7         /// 事件字典
8         /// </summary>
9         private static Dictionary<string, EventHandler<LoggerEventArgs>> Handlers = new Dictionary<string, EventHandler<LoggerEventArgs>>();
10
11         /// <summary>
12         /// 添加事件
13         /// </summary>
14         /// <param name="system"></param>
15         /// <param name="ev"></param>
16         static public void AddLogger(string system, EventHandler<LoggerEventArgs> ev)
17         {
18             if (Handlers.ContainsKey(system))
19             {
20                 Handlers[system] += ev;
21             }
22             else
23             {
24                 Handlers.Add(system, ev);
25             }
26         }
27
28         /// <summary>
29         /// 清除事件
30         /// </summary>
31         /// <param name="system"></param>
32         /// <param name="ev"></param>
33         static public void RemoveLogger(string system, EventHandler<LoggerEventArgs> ev)
34         {
35             Handlers[system] -= ev;
36         }
37
38         /// <summary>
39         /// 添加日志信息
40         /// </summary>
41         /// <param name="system"></param>
42         /// <param name="priority"></param>
43         /// <param name="msg"></param>
44         static public void AddMsg(string system, int priority, string msg)
45         {
46             if (string.IsNullOrEmpty(system))
47             {
48                 // 从字典中获取事件
49                 EventHandler<LoggerEventArgs> l = null;
50                 Handlers.TryGetValue(system, out l);
51                 // 事件参数
52                 LoggerEventArgs args = new LoggerEventArgs(priority, msg);
53                 // 执行事件
54                 if (l != null)
55                 {
56                     l(null, args);
57                 }
58                 // 若不存在，则尝试执行默认事件
59                 l = Handlers[""] as EventHandler<LoggerEventArgs>;
60                 if (l != null)
61                 {
62                     l(null, args);
63                 }
64             }
65         }
66     }

至于选择哪种方式来实现，就要看具体的应用场景了；此外，大多数时候我们都会使用匿名委托来声明回调函数，或事件委托，所以会导致代码的运行时态有一些小波折，尤其在读别人的代码的时候，这样的情况很普遍，会不会有更好的办法来让这种回调和委托比较容易跟踪？这个还在思考中……

希望能有所帮助~

本文链接

处理一个棘手小bug后的一点体会

2011-08-16T02:52:00Z

简单描述下俺要废话的背景吧，这几天都在排查一个bug：silverlight客户端应用中的某个控件，会因为多次操作而导致浏览器内存飙升，至于飙升的速度嘛，差不多操作半个小时后，浏览器估计就累死了……

接到这个棘手的活儿后，先大概捋了一下自己的思路：

1. 复现问题：并掌握问题复现的“规律”。

2. 熟悉问题控件的生命周期：一方面是控件的需求功能，一方面是控件的代码实现。

3. 用阶段排除法定位可疑代码段：主要是通过调试、观察，逐渐缩小问题包围圈。

4. 仔细研究可疑代码段：尽量能够连其上下文都要进行了解，以避免引入新的问题。

5. 思考具体的解决方案，并进行可行性尝试。

6. 修改代码，并更新。

乍看上去，还是很“美好”的，真正开始搞起来以后，才发现其实还是很棘手的，具体表现：问题很容易复现，控件生命周期在同事的热心帮助下也能基本搞懂，用排除法定位到了“问题代码段”，看似顺风顺水的，还不赖哈，下面就出事儿了，需要对代码段进行细致研究，这一研究不要紧，一头扎进去就不容易爬出来了……

发现问题是因为载入的silverlight控件的内容较大，所以导致载入的对象比较大，此外，最主要的还是因为每次操作都会导致一个新的对象生成，于是很直接地就想到了，时不时有一些资源无法被GC放掉，于是导致了内存溢出呢？既然选择了这条路，那么就要一路走到底了，首先先把该控件涉及到的内容进行分类，然后逐一地进行删减以排查最终的“内存杀手”到底是谁……不过运气不好，发现通过silverlight载入控件的时候可能会导致一些模板类的资源无法得到释放，但是经过单独的demo测试又没有重现问题，继续通过windbg来查看IE进程的内存使用情况，发现其中一部分日志功能代码导致了一部分的内存溢出，大概占整体GC内存占用量的16%左右，算是一个小小的成果吧；但貌似继续追查下去也只能到这儿了，因为我们发现GC占用的内存总量才占到IE进程的10%左右，有90%的内存怀疑是被一些非托管的资源占用了，但说到我们到底有啥办法改善上面，貌似是无能为力了

但是问题还要解决的，于是再次重新Review全部功能代码，发现在第一开始确定解决问题思路的时候，貌似自己遗留了关键的一点：“每次创建新对象……”，好吧，这是自己马虎了，总想着从纵向地根除问题，但是没有想到从横向去解决问题，如果我能保证所有对该控件公共属性面板的引用只有一个的话，是不是问题就解决了呢？答案是：Yes！

虽然不可思议，但问题终于是解决了，虽然还留下一点儿小小的遗憾……

回过头来看看这次的经历，还是有所收获的：

1. 首先，在排查问题的时候，做做小计划还是很有必要的；

2. 再者，一旦定位问题的大致原因，不要急着按照自己想到的第一种方法深入，不妨再想想有没有其他的办法来解决问题；

3. 不管你信不信，有的时候，我们可能找不到最终的原因，但我们必须要解决问题！这一点可能存在争议，但我觉得在面对上线在即的产品研发的最后阶段，是可以适当采取一些“妥协”的方案的，但这并不意味因为困难，这问题就不解决了，我们完全可以放到后面的时间再去深入地解决。

以上就是自己在这次经历后的一点小小体会，分享给大家，希望能对大家有所帮助！~

本文链接

改进C#代码之24：通过定义并实现接口替代继承

2011-08-15T09:02:00Z

1. 委托为我们提供了类型安全的回调定义。虽然大多数常见的委托应用都和事件有关，但这并不是C#委托应用的全部场合。当类之间有通信的需要，并且我们期望一种比接口所提供的更为松散的耦合机制时，委托便是最佳的选择。委托允许我们在运行时配置目标并通知多个客户对象。

2. 多播委托将会把所有添加到该委托中的目标函数组合成一个单一的调用。不过组合中有两点需要注意：第一，如果有委托调用出现异常，那么这种方式不能保证安全；第二，整个调用的返回值将为最后一个函数调用的返回值。

3. 在多播委托调用过程中，每个目标会被依次调用。委托对象本身不会捕捉任何异常。因此，任何目标抛出的异常都会结束委托链的调用。

本文链接

改进C#代码之22：通过定义并实现接口替代继承

2011-08-12T08:23:00Z

1. 基类描述并实现了一组相关类型间共用的行为。接口则定义了一组具有原子性的功能，供其他不相关的具体类型来实现。二者均有其用武之地，但用处各有不同。接口是一种按契约设计的方式：一个实现了某个接口的类型，必须提供接口中约定的方法实现。抽象基类则为一组相关的类型提供了一个共用的抽象。使用类层次来定义相关的类型，用接口暴露功能，并可让不同的类型实现这些接口。

2. 有时候，使用接口还可以帮助我们避免struct类型拆箱所带来的代价。当我们将struct装箱时，该装箱对象实际上支持struct支持的所有接口。当通过接口指针来访问该struct时，我们不必拆箱即可访问到内部的数据。

本文链接

改进C#代码之21：限制类型的可见性

2011-08-10T09:47:00Z

1. 并不是所有人都要看到所有的事情，你的每个类型也不都需要是公有的。在保证类型可以完成其工作的前提下，你应该尽可能地给类型分配最小的可见性。类型的可见性一般都没有你预料中的那么高。内部或似有的类也能实现公有的接口。所有的使用者都能访问到私有类型中公有接口定义的功能。

2. 很多独立的类都应该是内部的（internal），你还可以进一步地限制可见性，将受保护或私有类嵌入到原有的类中。可见性越低，那么稍后升级更改时所需要的变化就越少。原因很简单，能访问你的功能的代码越少，以后可能出现的修改也就会越少。

3. 创建内部类是一种常被忽略的限制类型作用域的做法。

4. 以公有形式暴露给外界的类和接口将成为你的组件的契约，必须认真对待。接口越是冗杂，日后的修改也会越加受限。暴露出的公有类型越少，稍后更新扩展时候周旋的余地也会越大。

本文链接

改进C#代码之20：保证值类型的常量性和原子性

2011-08-10T02:17:00Z

经常会遇到一些需要保证常量值不能被外界修改的情况，当然，我们可以通过使用private set;的方式来保证内部成员属性不会被外界修改，但是，如果遇到了多线程的情况，可能还是保证不了常量内部数据值的一致性，下面把常用的三种常量定义方式罗列一下，且越往后的方式越使得常量的原子性更强：

1. 常用的定义方式：

1     public struct Animal
2     {
3         public string Name
4         {
5             get;
6             set;
7         }
8
9         public string Age
10         {
11             get;
12             set;
13         }
14     }

2. 单线程情况下的实现形式：private保证了在初始化后，常量内部成员不被修改，但不能保证多线程同时初始化而产生的数据冲突。

1 public struct Animal2

2     {
3         public string Name
4         {
5             get;
6             private set;
7         }
8
9         public string Age
10         {
11             get;
12             private set;
13         }
14
15         public Animal2(string name, string age)
16             : this()
17         {
18             Name = name;
19             Age = age;
20         }
21     }

3. 多线程情况下的形式：readonly保证了只能在构造函数初始化的时候初始化一次，进而保证多线程不多次初始化，并且初始化之后不能被修改。

1 public struct Animal3

2     {
3         private readonly string _name;
4         private readonly string _age;
5
6         public string Name
7         {
8             get
9 {
10                 return _name;
11             }
12         }
13
14         public string Age
15         {
16             get
17             {
18                 return _age;
19             }
20         }
21
22         public Animal3(string name, string age)
23             : this()
24         {
25             this._name = name;
26             this._age = age;
27         }
28     }

PS：看到大家的回复，让大家感到了困惑，真是抱歉，可能是因为自己没有加入过多的说明，所以导致了大家没有理解，向大家致歉，同时借“白面青铜 ”兄的说明，进行了更新，希望能有所改善，谢谢~

本文链接

在追赶产品上线的路上，我们是否为在为将来“埋雷”呢？

2011-07-01T15:48:00Z

不知道别的公司啥情况，就自己带过的3家公司来说，基本都存在一种普遍的“赶工期”的现象，之所以说是普遍现象，这也有一些朋友的亲身经历，似乎这就是一种IT行业的特色，毕竟随着互联网化的长足发展，对产品的更新速度是一个空前的挑战！时间就是利润啊，这个道理想必大家都懂，这里就多说了。

暂时不考虑这些外部因素的影响，但从产品研发周期上来讲，我们大家在疲于奔命的无休止的为了产品上线，而不断地以铲地皮的速度累积功能的同时，我们也在为我们产品的未来埋下N多的“定时炸弹”！

都有哪些可能的隐患会悄悄地溜进我们的产品中呢？这里结合自己目前正在参与的一个项目，来作为一个引子，谈谈自己的一点个人理解：

1. 不同的编程风格侵入：如果没有事先进行一些编码规范，习惯性规约方面的准备工作，极有可能会造成大家按照自己的风格思路来完成分配的任务项，这样行进的后果很直接，也很显而易见，那就是对后期的二次开发和维护造成致命的苦难！

2. 对某些重要功能进行重复修改：对产品的一些核心的功能部分，如果没有事先考虑得足够透彻，就很有可能会出现在需求的不断演进中，我们要不断地去骚扰这些本应该是最为稳定工作的功能，重复修改这些代码，对每个人都是一大考验，因为光要能摸清它的来龙去脉就要花费很多的时间和精力，而且还要保证与其关联的各种功能的正常运作基础上，添加新的内容，其本身就是一种无形的折磨，极容易引入一些隐性的bug。

3. 缺少产品代码标准库：众所周知，有一些通用的功能代码，应该尽量保存在某个固定的地方，作为一个程序库来使用，这样做的好处就是能够极大幅度地减少程序中的冗余代码量，同时能够给团队成员一个完成相似功能的“参照”，越是做得通用，越能够减少他人使用的难度！反之，不仅会大大降低团队的开发进度，还会造成相同的功能不同的代码思路，这个非常可怕，简直就是后期维护的噩梦！

4. 含糊不清的需求联系：如果针对一些重要的需求功能，总是迟迟不能有一个完整、具体的需求说明，那就势必会造成在版本的不断演进中，不断地出现由于需求调整，导致程序员好不容易搞好的一个功能变成无用的垃圾，这个不但对整体进度造成了影响，更对程序员的心情造成了很大的负面效应。虽说不能完全避免，但一定要有一种预防此类事故发生的意识，越早发现越好。

5. 缺少程序模板的概念：这点似乎和程序标准库类似，但是也略有不同，所谓模板，可以理解为一个程序架子，其涵盖了此类功能通用的功能元素，对开发者最大的好处就是能够让大家只关注于不同功能的区别点区开发，而不用在那些通用的地方花费多余的经历，这也是一种严谨的变成习惯。当然，就算不用，产品一样能够完成开发，不过同样是以牺牲产品代码的简单清晰和引入潜在bug的代价作为前提的。

6. 既是“天使”又是“魔鬼”的脚本大爆炸：这个可能会具体一些，也就是我们再开发一些web应用的时候，往往不注重编写脚本的规范，比如应该如何命名全局的变量；应该如何划分不同的脚本功能块，并尽量行程单独的脚本库；如何处理浏览器兼容问题；如何与CSS协同工作等等，千万不要小看脚本的力量，它已经用它的巨大影响力证明了自己的价值，而web应用中超规模的脚本代码量也向我们证实了其重要性，所以，我们有必要用合理的编码规范、清晰的程序结构、简洁精炼的代码来减少为我们自己“埋雷”的风险。

上面节点主要是源于自己对当前参与项目中暴露的一些问题的思考和延伸，可能对一些从来没有编程过的产品经理，里面有很多东西可能并不十分了解，但依旧有必要和团队的技术负责人一起保持一些基本的关注度，如果放任不管，或只抓人追活，随意安排任务项的话，那迎接你们的极有可能就是一场有去无回的惨烈战斗！

本文链接

创新工场组织的产品经理沙龙 – 部分内容摘录

2011-06-29T03:31:00Z

魔图团队设计师刘静分享如何站在设计师的角度看待产品研发，还有知乎和经纬的两位朋友分享了一些自己创业的经历，简单摘录如下：

1. 设计师最好介入全程的产品周期。

2. 放下自己过往的种种经验、限制和约束，一切从头开始地去设计产品。

3. 从简单开始：感觉很简单，其实不简单，要能够让用户用着爽，同时不断地进行改进，使得产品能够伴随着用户而不断地成长，这才是一种健康的产品成长轨迹。

4. 做合理的设计，要考虑到平台特性、资源紧张和技术难题等方面，可有选择地通过设计来绕过一些耗时项或技术瓶颈。

5. 把决定权交给专业的人。

6. 人人都是设计师，都对产品富有自己的责任感。要保证团队沟通的顺畅，以便能够共同解决遇到的问题和困难。

7. 大胆地尝试。

8. 用数据说话。

9. 调研相关的数据，尤其是市场分布状况这一类对产品影响深远的信息。

10. 关注数据报告。

11. 关注用户，走进用户：反馈、互动、核心用户群、时刻问自己在为谁做设计？这就要求我们冷静地看待一些用户的意见，要结合产品的战略目标进行思考。

12. 产品的使命是啥？

13. 保持产品的特色：UI、通用功能和独特性。尽量寻找独特的一面去做产品，避免跟风而丧失特色。

14. 保证产品基因能贯穿于产品的每一个细节。

15. 产品意识。

16. 心态：保持开放的心态，多听多看；尽量多地尝试新的、不同的方案，避免一条道走到黑。

17. 保证产品的简单性，保证能过解决用户某方面的紧急问题。

18. 如何评判新的点子？通过判断其离核心价值的距离来进行思考和评价，且根据具体的实际情况来判定是否选择加入该功能点，可通过与团队成员进行讨论来进一步确定。

19. 对待团队成员，要尽量给大家能发挥其能力的自由空间；切忌不要替别人做决定，尽量引导大家思考（沟通方法）；要尽量做协调和沟通，然后再确定优先级，让大家有一种创业的感觉。

20. 对待boss的想法，英先试着去理解老板的商业嗅觉，再去思考其中的不足，然后去试着提出改进意见和沟通新的可能性。

本文链接