掰掰手指, 试用期都快结束了

嫌长的话就看两句话. 1.有人的地方就有江湖; 2.工程就是妥协.

以下内容的讨论语境是前端.

人情世故并不是简单的事, 懂得和会做真是两码事. v2 常常给人一种错觉, 如果我技术够牛, 我就能为所欲为. 然而做工程, 我觉得一半技术, 另一半是人.

糟糕的代码

落后的框架版本, 随意编写的构建文件, 随处可见的重复代码. <重构>中管这个为代码的坏味道, 应该考虑重构, 或者重新封装, 甚至书中给你提供了大量实战经验告诉你可以这样这样这样. 很美好, 很牛掰, 然后就掉进了过度设计的坑里面. 书里面没明确告诉大家的是, 什么时候应该重构? 什么时候应该处理代码中的"坏味道", 只是隐晦地说了几句, "软件工程没有银弹", 还有序里面对自己重构项目, 然后导致项目失败的经历.

书中"高质量"的代码和实战经验其实都是有代价的. 如封装, 封装可以隔离实体间的联系, 以降低耦合, 代码改起来容易, 理解起来也舒服. 然而封装的优点同时是其缺陷, 特别是写业务代码时, 由于业务变化, 封装时 api 设计不完善, 导致组件之间信息无法通信, 说白了就是需要的功能没有 api, 这时候要么用 hack 方法, 违背设计原则使父子组件直接通信, 要么引入全局状态管理, 要么写个全局服务共享状态.

都不是什么特别好的方案, 用 hack 方法那么为什么还有抽出两个组件? 全局状态管理添加许多代码只为了实现原本几行就能实现的功能? 软件工程充满争议的原因是到处都只能凭经验. 我得到的最大经验是, 先有点职业道德, 把事情做了, 然后再追求自己的匠人情怀. 何况菜鸡如我, 再怎么努力自己想, 还不如去看看人家的代码实际一点.

别人的代码

接手其他人的代码并不愉悦, 总会觉得"这 TM 写的是个啥?". 先收起质疑, 首先, 这是业务代码, 无论你怎么设计, 业务代码最后肯定看起来像坨屎, 需求一直在变, bug 一直在修, 不这样赶不及进度, 只能妥协, 大不了以后再补锅. 其二, 批判之前, 请了解这个项目什么时候开始的, 项目开发过程, 赶进度的代码高不到哪里去.

接手了, 可以减轻痛苦的方法是...沟通. 尽可能不引入新的依赖, 也不要考虑造轮子, 原来代码用了什么库, 封装了什么组件, 乖乖用就是, 看不懂代码就去找人家问. 遇到问题也不要想着自己解决, 都去问, 效率高太多(有时候太过独立也不是什么好事).

(对前端, 接手后代码尽可能不写页面......因为沟通过程很烦人)

沟通

如前面所说, 太过独立并不是什么好事. 我这个人很小开始就接触互联网, 搜索引擎玩得贼溜, 结果就是, 任何问题都 google 解决, 特别是那篇"如何正确提问"深得我心, 我自己也很不耐烦人家问我百度就能解决的问题. 然而, 过了. 事实上在团队中有疑问应该马上就提出, 首先如果只是小问题, 人家指点几下解决, 你能节约大量时间; 其次, 如果是大问题, 及早发现及早解决, 有什么不好呢? 我对自己解决问题的能力就是过于自信了, 导致浪费了很多时间.

我忽然想起了件事情, 我哥当年在大学, 距离期末考还有 3 天, 结果宿舍 6 个都没上过课, 书快 1000 页厚. 结果他们 6 个每人看 1000/6 页书, 然后第三天, 6 人相互教对方自己的看书得到的要点, 然后再通宵, 最后通过考试. 唔, 这大概就是团队的意义.

ps: 握草, 这不就是 map/reduce 吗 ps2: 忽然明白了城市人口增加的益处, 因为第三产业劳动中, 人多会效率变高, 然后做大蛋糕啊.

嗯, 下次做项目想把 PM 拉过来, 让丫给我说明白设计细节和交互细节, 还要拉项目负责人和我说明架构问题和注意事项, 特别是他挖的坑.

写得有点乱, 请见谅.

ps: mock 服务器很好用, 千万不要依赖后端给你的 api 做开发, 怎么死的都不知道.