提供一个实习岗位不要太容易 ... 于是要不要来做前端 ..?

@loveuqian 可以呀 ... 为什么不行 ...

@njutree 这套系统比起 JIRA redmine 之流确实不够严谨 ... 但对于我来说足够用 ...

关于人人可以打怪这个设定 ... 我作为管理者会把野生的怪物指定给某一个人来提升效率 ...

也就是日常任务的感觉 ... 在我没有指定的时候大家自由处理 ...

因为和绩效挂钩 ... 大家就会有抢怪的动力 ... 可以有效避免每个人都在等别人解决怪物的拖沓情况 ...

以及说有些危害程度不高的怪物 ... 一个手不熟的人花了很长时间解决了 ...

虽然从效率角度讲的确不如给一个手熟的人 ... 但从团队成长角度讲我更喜欢每个人都有锻炼的机会 ...

关于怪物的大小强弱 ... bug 还好说 ... 因为打掉之前的某个 feature 产生的 bug 视为怪物复生 ...

复生这个概念我之前也提过 ... 讲故事就是一个大 BOSS 被铲掉之后它的小弟们前来报仇这种感觉 ...

小弟的数量和危害会影响打掉这个 feature 的人得到的金币数量 ... 分给打掉这些小弟的人 ...

如果那个 feature 已经过了确认阶段进入历史了 ... 那么这个 bug 不和原来的 feature 挂钩 ...

这大概就是你说的死灰复燃 ... 不管原来谁写的不管现在谁触发的 ... 都作为新 bug 来放置怪物 ...

如果是纯新 feature ... 难易确实不好判断 ... 现在只能靠我人工 ... 我还没想到更好的处理办法 ...

至于怪物死亡很容易判断 ... 一旦需求方测试通过就是 Mission Accomplished ... 拿经验拿第一笔金币 ...

如果有测试不严谨的地方发现有什么边角细节遗漏也视为怪物复生 ... 放置新怪物下去就好 ...

打怪技巧也是同理 ... 我这套系统是结果导向的 ...

不管一个怪物是自己死掉的还是你费了九牛二虎之力才解决的 ... 只要最后解决了就是你的功劳 ...

系统之外的部分我会说代码写得好与不好等等 ... 人为的控制后续确认阶段的金币给予量 ...

我之前考虑过把系统跟 Sonar 打通来为每次战斗评级 ... 但还没实现 ...

基本就是这样 ... 不知道我有没有描述清楚 ...

Embody 的强大就在于它的可定制性 ... 每个人都可以把它调节成让自己最舒服的样子 ...

@ijse 是自己写的内部系统啦 ... 还没开源 ... 因为感觉还有些细节还需要完善 ...

类似的团队用的小玩意我零零散散写过好多 ... 比如还有团队效率管理和 Knowledge Base 什么的 ...

我惦记着把这些都整合起来再开源呢 ...

我自己有一套内部使用的技术组打怪系统 ...

怪物可以由任何人提交 ... 可能是 bug 或者 feature ...

怪物分危害大小 ... 但每个人每周最多只能放置两个 EMERGENCY 级别的怪物 ...

每个怪物可以被 assign 到某个固定的人 ... 或者由有空的人自己领来打 ...

打掉怪之后有金币有经验 ... 金币根据怪物级别打怪时间长短和怪物复生率在一定范围内波动 ...

金币可以用来兑换绩效工资 ... 兑换比例根据目前总金币流通数量波动 ...

大体就是这样 ... 总之就是一个以游戏之名结合需求管理与绩效考核的系统 ...

此外因为还有些零食掉落和 DKP 一类的设定 ... 实际使用起来还挺有趣的其实 ...

增删改查基础操作的语法不能错 ... 即 SELECT / INSERT / UPDATE / DELETE ...

SELECT 相关的看一下 UNION 和 GROPY BY / HAVING 语法 ... 知道这东西和 WHERE 的差别 ...

INSERT 相关的知道 INSERT IGNORE 和 ON DUPLICATED KEY UPDATE / REPLACE 即可 ...

以及要知道这是 MySQL 的专有语法 ...

此外看一下联表 ... 左右内外的差别 ...

索引方面知道 Primary Key / Index / Unique 索引的区别 ... 以及知道索引要合理而不是越多越好 ...

临时抱佛脚抱这么多就行了 ... 贪多嚼不烂 ...

如果面试的时候被问到有个很大的数据库怎么优化 ... 想办法把话题从数据库扯到缓存去 ...

说些什么在高并发下压数据库是不合理的行为一类的话 ...

如果逃不过去就说下分区和分表 ...

分区关键字是 PARTITION BY ... 分表只谈横向分 ... 原则是根据某个字段的不同范围存在不同的表里 ...

其他的扯一扯 ... 比如表类型 ... MyISAM / InnoDB / HEAP / Archive 一类的 ...

又比如事务处理 ... 行锁表锁什么的 ... 然后还能延伸到分布式 ... MySQL 主从啦 ... 读写分离什么的 ...

这些都是点一下表明你知道就行 ... 别扯深了容易露馅 ...

基本就是这样 ... 死记硬背一些概念 ... 其他的看发挥啦 ...

毛骗 ... 看看还是可以的 ...

关键字 WeixinJSBridge ... 转发成功有回调的 ...

不支持拆 ... 具体参考我之前的回复 /t/150282#reply12 ...

结构化的部分使用合理的缩进区分 ...

首先猫猫狗狗交配并不是因为相爱而是因为发情 ...

其次猫猫狗狗在发情的时候才不会管对方是不是跟自己有血缘关系 ...

再次人类在培育纯种猫狗的时候故意使兄妹相奸姐弟相奸的事情不要太多 ...

有基因缺陷的会因为捕食困难或抵抗力低下而被自然淘汰掉 ... 能活下来的就是赢家 ...

@wolfan 大挪窝也不会换的 ... 这么多年下来早就有感情了 ...

说起来 ... 我这个号已经是从大哥大的那种 9 开头的模拟网转过来的了 ...

如果 V2 上有用同一个手机号超过十五年的人 ... 那么基本在 V2 也没几个人会比他岁数大了 ...

我从上个世纪以来就没换过号 ... 到现在快十四年了 ...

反正就是一直用着 ... 这辈子就没准备再换了 ...

曾经准备买两门版 C180 然后看到真车被丑哭了的人路过 ...

二车其实我准备换 CLA ... 感觉会好看一些 ...

顶楼的思路其实是前瞻断言吧 ... 写成 \d+(?=<) 就不会把 < 匹配进去了 ...

不过说来以顶楼的原文来看 ... 直接用 \d+ 匹配不好吗 ...

不得不说 Coding 是近年来我见过最有情怀的互联网公司了 ...

作为一个开发者平台 ... 用户的默认头像 ... 项目的默认图标 ...

还有个人页面的头像大小 ... 个人标签的措辞等等 ... 以及错误信息 ...

http://ww2.sinaimg.cn/large/ed682b54jw1emyiku6fu1j209102ht8m.jpg

无处不萌 ... 而且最关键的是在前端萌的同时居然后端功能也一点不差 ...

而且我去偷窥扣钉员工的动态 ... 给我的感觉就是每个人都在很开心的创造这个平台 ...

这个状态已经不能用科学来解释了 ... 这不是情怀是什么 ...

如果有机会的话 ... 真想去偷窥一下这到底是家怎样的公司呀 ...

嘛 ... 虽然可能已经没人看了 ... 但我还是说一下最新进展好了 ...

顶楼的代码我自以为在「可读性」与「简洁性」之间找到了一个平衡点 ... 看来做得还是不够 ...

于是我又把它重构掉了 ... 去掉了所有三元嵌套只为增加可读性 ...

顶楼的代码就是孤本了 ... 挂在这里做个纪念好啦 ...

代码没问题 ... 重启下 VS 重建个文件执行一下吧 ...