@
GTim @
Mutoo 等等你俩不会在软二吧 ...
不嫌弃路边烧烤摊的话 ... 晚上出来饮个酒聊聊天 ..?
广义范围的技术交流的话 ... 牛庄有个爱特咖啡有 Tech-Club ... 不过说的面太广 ...
偶尔去当个热闹听听还是可以的 ...
存在普通一线员工这个概念的 ... 或者是公司业务做得大 ... 或者是公司管理有问题 ...
之前我带部门的时候全部门只有四个人 ... 每个人有优点有缺点 ...
但组合在一起各取所长 ... 应对各种需求绰绰有余 ...
鸡多不下蛋人多瞎捣乱 ... 用好手上的每一个人比盲目扩张规模要有效得多 ...
至于开发某个功能所用的构架和想法 ...
作为第一把手 ... 你必须知道 ... 构架不存在透明的问题 ... 是强制要求 ...
对于我 ... 加入我的团队第一步就是要熟悉我的框架和一些规范 ...
我自己有一个 php 5.4 的内部框架 ... 大量使用 closure 和 traits ...
我的代码规范里要求了很多听起来匪夷所思的东西 ...
比如我讨厌 class indexController extends Controller {} ...
日常开发中我会极力避免这种为了框架结构而框架结构的行为 ...
比如我没有做 ORM ... 你需要封装 SQL 语句 ... 以及读写分离也是在程序层完成的 ...
因为我个人有一个信条是我宁可开发麻烦一点也要用户访问更快 ...
如果是应付事的外包项目找个成熟的框架写吧写吧实现即可 ...
但这是自家的团队自家的项目 ... 每一个细节都要力臻完美 ...
又比如不许定义全局函数 ... 自己的模块用到什么就在自己的模块作用域下定义 closure ...
一旦要开发全局可调用的内容 ... 做完之后你要审核 ... 思考是否还有不足 ...
如果你的审核过了 ... 那么需要出文档 ... 哪怕很简单的文档也可 ...
让整个团队知道这个你实现了他们可以拿来用 ... 并且他们会知道该怎么用 ...
我知道我的框架不成熟 ... 上手可能各种别扭 ...
不爽可以提 ... 如果你能说服我那么我们整个部门热火朝天一起改 ...
如果你不能 ... 那你就必须适应我的框架 ... 这是作为技术第一把手的权利 ...
构架级的规范是定死的 ... 但进入每个人开发的领域 ... 天马行空 ... 我不会去管 ...
代码是部门内开放共享的 ... 事实上代码是公司的资产 ... 想不开放都不行 ...
如果你愿意可以自己去读 ... 完全凭兴趣和好奇心 ...
不愿意的话 ... 也不代表你可以一心只写自己的东西 ... 我会逼你读一些别人的代码的 ...
如果这一周大家都有开发 ... 那么会有例行的代码评审会 ...
评审会上大家拿出自己这周写的东西来讲讲自己是怎么做的 ... 每个人就当听热闹听听 ...
如果你技术差 ... 可以从别人的代码里汲取灵感 ... 不懂就问 ...
如果你技术好 ... 你可以直接拍案而起说你这里不对 ... 你可以用更好的什么什么方式 ...
如果你发现了谁又重新造了你造过的轮子 ... 也可以嘲笑他不看代码 ... 这都是允许的 ...
我主张这种交流 ... 每个人介绍自己创造的东西给大家 ... 大家跟着一起思考 ...
如果你介绍自己写的东西的时候简单略过 ... 别人介绍的时候漠不关心 ...
偶尔用几个语气词来表达你还在听 ... 对不起我不需要你 ... 哪怕你技术比我好 ...
除非你做了技术第一把手 ... 你说了算 ... 如果你不是 ... 我说了算 ...
当然 ... 这个是部门级别的会议 ... 公司其他人都无权干涉 ...
如果你觉得这属于打搅开发和思考的非必要性会议 ... 你来做一把手的时候可以取消掉 ...
至于说生怕自己想的不周到这种事情 ... 你只是部门的第一把手 ...
你上面还有我是 Technical Director ... 有想法随时来问 ... 我给你建议 ...
如果你和我都想的不周到 ... 那指定栽跟头 ... 记下来 ... 同一个坑不跌倒两次 ...
团队合作三要素 ... 遇到问题 ... 解决问题 ... 分享经验 ...
跌坑里不是坏事 ... 关键是要明白自己为什么摔下去了 ... 这就是成长的过程 ...
至于后面说的 ... 共享项目进度一起加班 ... 作为技术经理陪着加班不是理所应当么 ...
如果哪个技术经理做不到这个 ... 就是那个公司有问题了吧 ...
也不知道写了多少 ... 大体就这些 ... 这就是我的经验啦 ...