先请求一个公钥，客户端用这个公钥给用户数据编码，然后随便什么 get post 请求把数据发给服务端都可以了。
只要没加密，放在 request body 和 request header 和 url 都是不安全的

为什么这么多吹苹果的呢，买个联想华为平板感受一下

我用 surface pro 4，同档次的产品，市面上没有任何替代品

互联网公司产品经理的想法，你理解不了的。
自从乔布斯被神话以后，全中国的互联网产品经理都觉得自己比用户更聪明

非机动车道就不存在逆行的说法，我回家还得扛着车上天桥再下来搬着车进小区？
要是这样行人道的行人也别逆行了呗，需要靠左行走的情况请向后转，倒着走。
长安街明天你看看坦克和装甲车有没有逆行，让上海警察去罚款吧。

只用 div span 说明是开发者以功能角度或当作编程语言去看待 html 的，这样写出来的功能和样式严格符合期望，兼容性还好。
但 html 不是编程语言，是标记语言，它应该像文档一样段落分明，语义清晰......
就好像穿衣服一样，不同场合穿不一样的，永远穿一套 divspan 就等同于只满足了保暖的低阶需求

很多前端的最佳实践我觉得要分场景来看待，反正我不用 scss,less 这些冗余的东西，只用标准 css 语法，将来的趋势也是标准化，项目依赖更干净

把用户中心改造成单页应用，打包发布到私有 npm
在当前项目动态 import 组件，放到模态框显示

约束＞沟通
只要每个人把自己的事做到 100%正确，团队就会正确。很多沟通是无效或者低效率的，比如代码改动不更新文档 /错别字 /技术方案由不懂技术细节的经理制定，都产生太多无用的沟通

35 岁，是普通学历能力的人进体制的最后一次机会

@wd 在养猪场削苹果和苹果园杀猪，都不合适，大多数公司就是这种环境。

为什么要给自己设置限定呢，比如自己只是一个前端，不该去学习数据库，比如自己只是一个开发，不该去学设计、测试，这样以后路越来越窄，除非成为某个领域非常资深经验丰富的专家，能成为专家的永远是少数人

各位，我说了 Code Review 是好的，但是多数公司包括大厂也一样，最终会把技术问题演变成流程问题。
关于流程，Git Flow 工作流，双周迭代(固定隔周的星期二发布窗口)，很多项目管理的细节都贴近敏捷软件开发。都是最佳实践啊，哪里出问题了？
我觉得还是人的问题，平均素质差(无论技术上还是价值观上)的即使用了最佳实践，结果也不一定好

@Jiavwen 前端，涉及逻辑的部分是有单元测试的，其他 UI 相关的都是人工检查，这部分很难用程序逻辑去描述是否正确

Code Review 的好处太多了，但那只有硅谷或者国内小部分工程师文化的公司才能享受，大多数不那么工程师文化的大厂最后演变成了: 上级要求下级 Approve PR，下级一般会假装看代码，然后 Approve ；同级之间 Code Review，就看互相关系好不好，你讨厌一个程序员，那就在他的 PR 中挑毛病吧。

我在 PR 阶段被提出的最多问题就是: 变量命名之类的问题。我认为这类属于协作效率问题，不应该在某个具体 bugfix 的 PR 阶段提出，而应该是每周或每月开小组技术会议的时候一起 check。真正应该关注的是: diff 中是否改动了无关代码，改动部分的影响范围，当然还有程序逻辑是否正确，会不会产生更多潜在的 Bug。

为什么 stack overflow 上面我经常搜不到想看的问题
直接用搜索引擎更快

如果全员邮件宣布涨薪，明确了人员范围有你，但是因为离职申请而被部门 HR 拒绝涨薪，你有权利主张涨薪。
因为离职申请和涨薪是两件事情。
举个例子，吃米饭的时候就不能吃面条了吗？