这是一个创建于 1970 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2020-05-25 18:40:46 +08:00
一如既往的包容与关怀
 | 1 wysnylc 2020-05-25 17:24:39 +08:00  18 想想为什么这样的人会是你同事而不是我同事 |
 | 2 wangkun025 2020-05-25 17:25:37 +08:00 有这种人衬托，你该开心才对。 |
 | 3 shintendo 2020-05-25 17:26:36 +08:00 2 你说的太泛泛了，唯一举的例子 submitData 和 submit，没觉得有什么问题 |
 | 4 RHxW 2020-05-25 17:30:28 +08:00 1 你这算啥，你见过连 for 循环都写不明白的么 |
 | 5 wisetc OP @wysnylc 我想过很久，我开始慌了，因为我没有一个学历，因为我的雇主是个 tech-less，因为没价值 |
| 6 wisetc OP @wangkun025 相反，我很郁闷 |
| /td> | 7 wisetc OP @shintendo 是的，我并不是为了检举，而是出于无奈的心情，所以不讲究具体和实证。实际其实不是 submitData，而是 submitMemo |
 | 8 jiyingze 2020-05-25 17:48:17 +08:00 via iPhone 这种人，他开心就好。你写好自己的代码就是。不要和他生气，没必要。生气伤身体，还浪费时间。如果他是你的上级，虽然按照他的写法很不爽，但是改也花不了多少时间，不要和他吵，省点时间自己可以多学习学习 |
 | 9 cmqwan 2020-05-25 17:56:47 +08:00 我觉得他说的没啥问题,2 种写法各有利弊. 写后端有时根据某个实体对象(比如 user 表)查询数据库,以前命名是 queryByEntity/add/update/list,看似通用,但是查问题时,还需要去查找在某个对应的类里面. 如果我命名是 queryByUser,那我全局搜索,就能一步到 xml 了 这里只是编程习惯的问题,如果整个公司没有规范,那就是按自己觉得方便的方式去写. 强行要求他人按他的习惯来就没必要 |
 | 10 mumbler 2020-05-25 17:58:20 +08:00 via Android 所以要抵制培训班 |
 | 11 chairuosen 2020-05-25 18:01:00 +08:00 看场景吧 queryUser queryUserByUid api 封装我选后者，User 类用前者 |
| 12 shintendo 2020-05-25 18:01:47 +08:00 @wisetc 取决于业务上会不会有不同种类的 submit 吧。不过有一点，事件名用驼峰是不推荐的，要用也应该 kebab-case |
 | 13 vansouth 2020-05-25 18:10:47 +08:00 就 submit 而已确实不是太可读性吧 submitMemo，submitData 好点吧 |
 | 14 ppd 2020-05-25 18:17:35 +08:00 1 你如果是写架构的，你可以写的抽象点，你作为一个写业务的，写具体点，难道不好？ |
 | 15 U7Q5tLAex2FI0o0g 2020-05-25 18:19:59 +08:00 就 submit 这一点而言，我同意你同事的观点，不管是可读性，后续别人维护性，都是不错的 |
| 16 wisetc OP @wangkun025 说的有道理，哈哈哈 |
| 17 wisetc OP @jiyingze 中肯，感谢。我们不是上下级关系，而是比较要好的伙伴，我也没有责怪他，也正是他替我挡了些不愿投入的事，也许每个人的追求不一样，只是感觉寂寞，跟经验和知识结构有关系。 |
 | 18 banricho 2020-05-25 18:29:08 +08:00 看事件名似乎你的同事是没什么问题的，当然也不是说你有问题……这个完全应该是团队规范的事，没规范么大家随意发挥，起码没拼音已经很不错了。 sync 我理解但是一般也避免去用。 你说的都不算能支撑你的论点啊 =。= |
| 20 wisetc OP @mumbler 有时候雇主创造一些就业，老人能够给年轻人一些机会，培训出来的能够容下培训出来的，专业的就不这么认为了，抢了他们的蛋糕，而且很明显有公平性和正直性问题 |
| 21 wisetc OP @chairuosen 我都选后者，哈哈哈 |
 | 22 ohao 2020-05-25 18:42:34 +08:00 发工资的时候又发现 他工资比你高 你说气人不 233333 |
 | 23 Chingim 2020-05-25 18:46:00 +08:00 via Android 方法命名最佳实践难道不是动宾短语吗？ submitMemo 挺好的 |
| 25 wisetc OP @banricho 谢谢理解，只是我一贯喜欢写通用性的代码，突然被人指责觉得难受，确实需要增加一些达成的规范。额，sync 的话，是 emit update:param 语法糖，双向绑定有时候还是简洁的，减少了出错，我只是理解不了为什么他这么久了还没有学会 |
| 28 wangkun025 2020-05-25 19:07:33 +08:00 @wisetc 大哥，你回复我两次，我觉得你大概是分裂的。 |
 | 29 ps4512 2020-05-25 19:17:14 +08:00 via iPhone 寸有所长 尺有所短，多多交流，也能有些心得。 |
| 30 wisetc OP @wangkun025 你怎么知道我是大哥回复你三次，那就 |
 | 32 pkupyx 2020-05-25 21:05:21 +08:00 你同事要求具体才正确啊，UI 没有复用性的地方写具体有可读性当然更好了。 |
 | 33 lewinlan 2020-05-25 22:43:11 +08:00 via Android 1 『程序员都觉得自己的代码写得好，别人的一坨』 |
 | 34 WilliamYang 2020-05-26 00:11:19 +08:00 1 楼说得才是最正确的，想想你怎样才能远离水平低的同事，即使在这里，也有很多水平一般的人，不可尽听 |
 | 35 ccraohng 2020-05-26 08:41:41 +08:00 via Android 暴露出的事件名，就该更加通用点。你完全可以把你的业务代码的处理函数名具体化 |
 | 36 JasperYanky 2020-05-26 09:44:56 +08:00 如果你写过 OC，就会对方法名的长短看淡很多 |
 | 37 hevi 2020-05-26 10:26:57 +08:00 方法名、参数名长点具体一点其实挺好的。 .sync 官方其实也不推荐使用，虽然糖挺甜的。 官方推荐使用事件的方式去更新，我就没刻意去记了。 |
 | 38 bertonzh 2020-05-26 10:51:27 +08:00 submit 和 submitData 在我看来其实差不多，都比较抽象。 楼主说的这种现象我也见过：我写的通用组件满足不了对方的需求，比如需要条件性地改一些样式，隐藏一些东西，正常人扩展这个组件，可能会选择传入自定义 className，或者提供类似 styleXXX, hiddenXXX 之类的属性，但是他自己改这个组件加属性，结果用的属性名字是他自己的业务属性。如果只看这个组件的代码，谁也读不懂这个属性名，看不懂这个名字和里面的逻辑是什么关系。非常蛋疼 |
 | 39 Haujilo 2020-05-26 20:46:53 +08:00 1 楼说得固然有道理，但是事情往往不是非黑即白的。同事我见过更坑的，关系户进来的那种，说多年 Python 经验，PEP8 不知道是什么的，空格和 TAB 齐飞。用个 Git 只会 add 、commit 和 push，代码冲突不会 merge 或者 rebase，埋冤别人冲突了，或者让别人帮他合并代码。写的代码也惨不忍睹，喜欢复制粘贴，最终自己都看不懂了，一个项目克隆了几份来复制粘贴（估计不懂 branch ）。遇到这样的，实在不能忍只有自己走或者把别人弄走两种选择而已。 |
Select Language