erl misc

======2015.12.9======

1.  不一定要把模块分得十分细，或者严格仿效OOP的方式去细化模块。

     先做好大方向的模块划分，比如： player,  sys_guild（业务处理模块）,  guild（guild服务进程）， mysql...  当系统中的某个子系统比较大时，再考虑细分出来， 比如： player_guild， sys_guild_skill， guild_util，mysql_conn，mysql_conn_mgr...     一开始代码“糅”在一个模块， 并没有什么大问题，重要的事是做好接口的设计和函数的封装。 当发现一个模块的代码量确实太多时，如前所说，再考虑按子系统/子功能抽取、分拆代码。

2. 对于类似帮派系统的协议处理：

　 （1） 部分业务逻辑可以全部在玩家进程中做处理；

    （2） 在玩家进程做必要的check处理（注意到有些逻辑只能在玩家进程做检测）， cast给帮派进程后， 在帮派进程做进一步（主要是针对可能存在的并发问题）的check处理；

    （3） 第2点的方式其实有点繁琐，如果可以的话，在玩家进程简单检测过滤掉非法协议的情况后， 后续的业务逻辑检测和处理就统一委托到帮派进程去做，省得繁琐。

     Note： 不要把简单事情复杂化！

3. 代码做适当的容错是必要的， 但是没有必要处处容错、处处担心可能会有这样或那样的问题，否则，同样会把简单事情复杂化！

    勿忘契约（契约式编程），如果出错，那么很可能你该考虑的是解决/修复引发问题的源头，或者构思和使用一个更好的设计，而不是一味容错。

    周密构思后，在关键的地方容错即可， 然后辅于充分一点的测试。

 

 

======2015.12.15======

1. 据同事反馈， 当大量进程频繁调用crypto:strong_rand_bytes/1时，并发性能将严重下降，据说是因为锁的原因。

  当然，本来是不应该出现这种情况的（bug导致）， 这里记录和警醒一下。

2. 写代码（特别是一些比较繁琐的业务逻辑系统）时，模块内的函数排布或者其他东西的排布可以临时性地将就凌乱点，只要方便写代码就行。 等功能完成后，再统一整理和重新排布即可，以便于阅读和增加美感。

 这其实和盖房子一个道理，盖房子的过程中，工地的脏乱是不可免的（当然了，框架不能乱），等房子盖好后，再收拾清理干净即可。

 

 

======2015.12.16======

 1. 如果用对象思想，是否要独立出一个对应的模块来？

　  (1)如果对象比较大，那么就用一个独立的模块，以更好地体现对象思想，比如：用po.erl对应玩家对象，npc_o.erl对应NPC对象，guild_o.erl对应帮派对象，bu.erl对应战斗单位（battle unit）对象等；

  　(2)如果对象较小，则可独立，也可不独立用一个模块对应，怎么方便怎么来。如果不独立，到后期当发现有必要独立出来的时候，则重构之；

     (3)另外，对象使用范围的广与窄，以及（未来）需求是否多变，也是决策因素，视情况而定。

2.通常情况下，能用cast（异步）的就不要用call（同步），

但是，对于部分操作的处理，可以考虑用call，比如：创建帮派，解散帮派，加入帮派，退出帮派等。
考虑到：(1) 这类操作的频率较低，用call基本上不影响性能；
           (2) 用call能使逻辑实现起来更简单和清晰，省去了异步的繁琐；
           (3) 用call能更有效避免并发和不一致的问题。对于异步，一去一回的过程中，如果出现异常并且代码考虑不周密，则有可能导致数据不一致。

3. 团队要有战略，否则会失去方向，而且战略要正确，否则，就是白忙一场。

团队要有管理和流程，否则会散漫或乱成一锅粥。
但是，最核心的，最重要的，其实是，人！ 团队是由人组成，具体落实做事的，也是人！
而这些人中，相对更重要的，是各分组的主心骨，如主程，主策，主美。因为俗话说：兵熊熊一个，将熊熊一窝。

4. 自尊心是必要的，这是肯定的。但如果自尊心太强，太过敏感，就未必是什么好事了，有时候，你得脸皮厚点，跟自己说，去TMD的自尊心，然后专注于完成事情或解决问题本身，而不是在其他方面无谓地消耗你的心力。

生命有限，时间宝贵，把精力投在该投入的地方，而不是浪费在无意义的琐事、杂想上。 如果工作不是你的真正兴趣所在，那么，专注、高效快速地完成工作，给生活腾出更多的时间和空间，然后去做自己喜欢的事情，和自己喜欢的一切在一起！

 

 

======2015.12.19======

技术上， 当前阶段首要是拓展宽度，故首要是学习和熟悉client开发（其实和打篮球道理类似，只会强手是不行的，弱手更需要强化练习，以达到无所谓强弱手、没有短板的水平，这就是“宽度”的重要性！）。

进一步，从产品角度思考，牵涉的主要技能是策划。

此外，技术、产品、职业和创业，都不一定仅限于game，或许可以考虑/关注其他，是否有更好的机会。

 

======2015.12.21======
如果非独立游戏，
要么自己打造一支优秀的团队
要么自己与伙伴打造一支优秀的团队
要么寻求加入一支优秀的团队

 

======2015.12.22======
（深入）了解一门技术和（深入）了解一段历史有些类似。

 有时候，你对某段历史只是有一个比较模糊的概念和了解，基本上是通过一些道听途说或只言片语了解，
 这种感觉，与你对某项技术只是有一个模糊和粗浅的认识很相似。
 当你具体去了解一段历史之后，感觉它也就那样，先前存在的疑问也不再是疑问，感觉“神秘”之处也不再是什么“秘密”，
 这种感觉，也与深入了解一门技术后的感觉很相似。

因此，道理其实大多是相通的，了解或学习的方式也是可以相互借鉴的，
对于未掌握的技术，不必畏之，兴趣再加上用点心，一回生二回熟，没啥搞不定的。

而有时当情况要求你必须快速搞定某个问题时，就得直奔目的————明确目标，明确你想要的是什么，然后信息筛选，适当囫囵吞枣就是必须的了，
当然，这种情况通常也意味着意外或者失控，不是什么好事，应尽量避免。

 

======2017.7.8=======

关于global：

1. 对于全局性的公共进程，比如全局排行榜进程，方便起见，可以注册为global（通过global:register_name(Name, Pid)注册）。

   但是对于玩家进程，数量较多，因此不建议注册为global，否则会影响性能（至少，当某进程注册为global后，global模块会对其添加一条监控 ---- 通过erlang:monitor(process, Pid)）

2. global模块的代码，理解起来有一定难度，这是因为需求本身就不简单，要考虑的细节和异常情况比较多。

    里面的一些思想和代码还是有较大的参考价值，比如（全局）锁的实现机制，名字冲突的解决方式，节点down了然后又重新up后的应对处理方法，等等。