@gy0624ww 似乎你已经知道答案了。

听上去并不是 git 流程的问题。试着让前端可以通过修改配置文件等手段监听不同的端口吗？这样就不需要覆盖了。
如果 ABC 三个需求会造成 conflict, 合并到测试分支时解决 conflict 还是合并到 master 解决 conflict，conflict 始终存在。如果需求之间没有什么关系，那肯定是分别做 3 个 PR 来做 master merge 会更清晰点。

@yazoox 没有。最多就是奖金少发股票没有经理约你谈话而已。

苏州微软的奋斗逼太多了。早 9 晚 9 自发 996 的我见过(非阿里系)，法定节假日主动加班自拍发工作群的我也见过。
刚真，出活靠堆时间，水平没啥大长进，真的不考虑下将来吗？

cache 念 cage.

已 sub 。老哥加油。

@letianqiu 你的理解是正确的。

因为是第一个申明的是 ArrayList<Object>, 1 可以被 autobox 成 Integer 放进去没问题。
第二个申明的是 ArrayList<String>, 1 不是 String，所以在编译的时候就报类型不匹配的错啦。
以上都没有到 runtime。

final boolean isValid = true;

...

if (isVaild == true) { // do something. }

买不到草啊 草荒

@20015jjw 13 年的时候有啊 之前和后面我就不知道了。反正福利是好的很，经常看到有人在房间里用 xbox 踢 FIFA

@20015jjw 在 meraki 看 bay bridge 真的很赞阿 食堂也不错 离 caltrain 步行也很近

很少。我自己的策略就是在每次改动代码的时候做小规模重构。当然这样会有同事说你 git commit 碰了太多没必要碰的代码。另外一种策略就是在不是那么忙的几天，添加单元测试，同时部分重构。
至今没有遇到上级会同意，“嘿，这周你把 xxx 重构一下”。

同意二楼。
因为这里 has_data 被两次使用来用 condition check，毫无疑问第一种好。
如果 has_data 只被用一次做 condition check, 两种感觉都可以。
readability > pythonic for the sake of being pythonic

看讲某个项目或者技术的时候有没有激情，激情这个东西是装不来的。
当然了，最后还是看和我是不是合拍>.<

长的很像我的 planck

和楼上意见一致。params 应该不是 dict。你可以 print(type(params)) 试试

@GreatTony
1. 我可能没理解正确：对应的 case 具体处理函数不管在任何情况下都要编写，我不是很理解为什么存在多余不多余的情况
2. 函数加入 dict，从你的设计来看，确实是只需要加一个装饰器即可。如果按照我的想法封装在 dict 里面，我个人不同意这是一个多余的步骤，比如就在 dict 初始化时一步完成：func_mapping = { "case1": handle_case_1_func, "case": handle_case_2_func, ...}

追加两点：
1. 除非是把所有 case handling 函数强行封装在某个单独文件或者某个 class 里面，按照你的设计，这些函数理论上可以随意分布，即虽然你给的例子，三个函数是连续定义的，但是实际操作中可以被任何别的语块割裂。另外你的 register 是偏隐性，和 dict 的 explictly 定义，后者可读性更强。
2. 抛开维护和扩展而言，设计此类特性，更偏向于需求方的要求。decrator 在某些 use case 下是很优雅，但是不代表因为优雅就会去使用