@helloccav 是的，如果有多个模块，就请求多个 api ，我们目前就是按照这样的方式处理。 这样 api 在很大程度上能得到复用，这更有利于 api 维护管理。 如果全部面向页面来做 api ，我认为越往后走， api 维护以及代码维护的成本就会越来越高。 当然，这样肯定就会面临多次网络 io 的开销，但我认为在目前 4G 流行的场景这不是一个大问题。 而且如果发现这块真的是一个短板，那么可以考虑加入 API gateway 。

这个就和大学里面检查你开的宽带有没有开共享一样。 方法海了去了，比如 TTL 啥的

补充一个连接： [微服务实战（二）：使用 API Gateway]( http://dockone.io/article/482) 或许有些帮助。

观点： 后台提供的 api 应该是面向数据的，而不是面向页面的。 面向页面的接口，一旦页面发生变动， api 就要发生对应的调整。 而且这样的接口也不够通用，会导致很多割裂的接口，这不是一个好的现象。
方案： 如果大佬讲理由讲不通，那也只得按他们的来咯。 但是你可以考虑增加一个 API gateway ， 由这个 api gateway 完成面向页面的 api 封装，向后调用面向数据的 api 。 如果前端后 node.js 的话，直接丢给他们做。

good job!

每个服务器一个 shell 脚本， 名如: ssh2aly, ssh2sch...

看楼上的这个连接，有说如何给自定义的函数、类等等，增加类型提示。 我目前就这样使用，自己写好参数以及返回值的类型后，提示功能和自带的类 /函数就没有什么区别了。

@lightening 的确，如果能优化到快速看明白(无论时抽取函数、清晰命名、提取脉络等)，那最好不过。 但在我实际工作经验中，我会经常遇到一些逻辑(很操蛋的逻辑)，并不能通过以上手段来达到使其清晰明了。

git blame 这个，我更倾向于在 git 的 log 中写'做了什么'。 再且，注释写在代码中，我能一目了然的获取到我想要的信息；我可不想再去 git blame 一个个的去翻 why 。

然后注释带来的问题这个：
1. 猪队友这种情况，真的只有认了
2. 注释的详细程度，应该有个合适的度。 一味的靠注释来阐述代码，那代码必然时糟糕的。

综上，我的观点是： 写必要的、简洁明了的注释，用来快速的理解 或 帮助回忆代码逻辑。 即，注释是辅助工具。

私以为代码自注释都是扯淡。现在写的代码中，大部分都是业务相关的，业务相关的代码必然会有些业务相关的逻辑，而这些逻辑不是代码能清晰的说明 why 的；再且增加一些能简明达意的注释何乐而不为。

一般来说，如果我认为一段代码，我不能在 10 秒以内或者更短的时间内读懂它，那么我就认为我需要加注释。

用钱方好久吧，我们成都这边蛮多的。 PS ：最近还有红包活动

nice.