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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4

❮

❯

2017-03-14 23:36:22 +08:00

回复了 ApizzaTeam 创建的主题 › 程序员 › Apizza 一个专业的 api 在线管理，调试，测试工具。（可能很多小伙伴已经知道了^_^）

成都的公司，赞一个

2017-03-07 13:09:05 +08:00

回复了 jarry777 创建的主题 › 分享发现 › GoDaddy 在 NBA 打了中文广告

涨知识

2017-03-06 13:40:37 +08:00

回复了 wfwdex 创建的主题 › 问与答 › 这个 API 文档是用什么生成的？ https://www.pingxx.com/api

5 楼推荐的不错

2017-02-28 13:16:40 +08:00

回复了 chuanqirenwu 创建的主题 › 奇思妙想 › 基于用户兴趣标签的海量程序员相关内容聚合推荐应用，大家觉得怎么样？

http://toutiao.io/

2017-02-23 23:01:09 +08:00

回复了 Quaintjade 创建的主题 › 信息安全 › SHA-1 的第一个成功碰撞

要逆天

2017-02-20 13:19:55 +08:00

回复了 Aresn 创建的主题 › JavaScript › iView 发布 1.0 正式版， 43 个 UI 组件助力中后台业务开发

支持，目前用的 ele 的 (element)[http://element.eleme.io/#/zh-CN]

2017-02-17 13:30:30 +08:00

回复了 xiaoz 创建的主题 › CentOS › 生产环境你们用 CentOS 6.X 还是 CnetOS 7.X，为什么？

线上还是 6 ，历史原因，短时间不会更新

2017-02-13 13:44:56 +08:00

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

@Immortal 要立字据啊

2017-02-13 13:42:39 +08:00

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

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

2017-02-13 13:32:00 +08:00

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

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

2017-02-13 13:19:15 +08:00

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

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

2017-02-13 13:10:04 +08:00

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

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

2016-12-06 13:32:37 +08:00

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

good job!

2016-07-18 22:03:38 +08:00

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

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

2016-06-28 18:58:30 +08:00

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

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

2016-06-28 18:57:04 +08:00

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

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

2016-06-12 20:48:45 +08:00

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

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

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

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

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

2016-06-12 19:30:51 +08:00

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

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

2016-06-12 19:27:08 +08:00

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

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

2016-05-14 19:34:55 +08:00

回复了 yuanzj521 创建的主题 › 微信 › 微信商户支付的问题，已经恶心我好久。

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

1 2 3 4

❮

❯