V2EX › ideascf 的所有回复 › 第 3 页 / 共 4 页

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

2017 年 2 月 13 日

回复了 0139 创建的主题 › 问与答 › 运营商如何判断手机在开热点？

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

2017 年 2 月 13 日

回复了 Immortal 创建的主题 › 程序员 › 服务端 API 设计到什么程度算合适

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

2017 年 2 月 13 日

回复了 Immortal 创建的主题 › 程序员 › 服务端 API 设计到什么程度算合适

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

2016 年 12 月 6 日

回复了 iMmatrix 创建的主题 › Python › 实例讲解基于 Flask+React 的全栈开发和部署

good job!

2016 年 7 月 18 日

回复了 Xuanwo 创建的主题 › 程序员 › 求问老司机，手头的服务器多了怎么管理呢？

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

2016 年 6 月 28 日

回复了 hihihihihi 创建的主题 › Python › C++/C# 程序员转 Python 的困惑

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

2016 年 6 月 28 日

回复了 hihihihihi 创建的主题 › Python › C++/C# 程序员转 Python 的困惑

https://www.jetbrains.com/help/pycharm/2016.1/type-hinting-in-pycharm.html

2016 年 6 月 12 日

回复了 brucefeng 创建的主题 › Java › 大家注释怎么写的

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

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

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

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

2016 年 6 月 12 日

回复了 brucefeng 创建的主题 › Java › 大家注释怎么写的

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

2016 年 6 月 12 日

回复了 brucefeng 创建的主题 › Java › 大家注释怎么写的

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

1 2 3 4

❮

❯