两个月前,从待了2年的老东家那边离职,到了另外一家企业。
之后对于深陷泥潭的新东家感到无比痛心与无力。

一枚小前端,叩首而行。
从当成满腔热血什么都不懂的二菜,如今终于变成了一个纯正的二货。
在老东家手下工作的时候十分开心。
离职两个月,依旧十分感谢当年路哥的接纳。
偶尔也会和老东家和前同事聊聊天、谈谈技术,
一起交流一下未来的发展,
以及曾经我在职期间留下的技术债的重构和解决方向,
甚至义务做了点简单的开发。

由于个人原因,离职来到了新东家这边。
说实话,感觉很糟糕。
在这短短一个半月,一枚新员工,被赋予了前端组组长的职位。
却深刻的理解到这家公司,在技术上的弱势有着更深层次的原因。

反倒有了一丝绝望感。

经历的两家公司,正好做个总结。

该司确实还是希望能将技术这块做好,
开出的薪资在当地也算可观。
但是其根本上谬误太深,
在只是一介技术员工的情况下,
实在无力拔除。

希望,所有在困扰的人们,都能够有个光明的未来。


从我和一些朋友们的经历来看,似乎很多企业对于公司技术的管理理念有着根本上的谬误。
该文从技术的本质为出发点,来做一些基础点的提炼。
优先级与写作顺序无关。

1. 不要吝啬于给员工提供一个好的工作环境

这里不只是单纯的技术人员,而是公司的每一个职工。
这里指的不是办公大楼的气派和豪华,而是每一个职工工作的舒适程度。
包括但不限于:

  1. 工作的设备与资源
  2. 对员工学习提升的支持
  3. 对员工工作的硬件保证
  4. 对员工在公司休息环境的保证

一个豪华的写字楼确实可以帮助你司 看起来 更高大上更有实力。
但至少请给ui和开发一台好的显示器和电脑。
给需要久坐的员工一个舒适的座椅。

写字楼的豪华没那么重要。
至少对于一个工程师来说,没有他的电脑、椅子和显示器重要。

2. 当你觉得技术无所谓的时候,技术会主动来向你介绍他的重要性。

代码不是积木。
垃圾代码是无法堆成高楼大厦的。
它只会藏在大楼的地基深处,腐蚀后人埋下的钢筋。

  1. 永远不要轻视了代码质量的重要性
  2. 永远不要轻视了垃圾代码的可怕性

垃圾代码产生的原因很多,一般分为以下几点。

  1. 历史原因,编码方式和理念更新换代
  2. 项目开发人员技术和经验的不足
  3. 开发人员配备不齐全,导致跨领域开发
  4. 项目开发进度过快导致的盲目赶工

其中1是无法避免的,只要有一定年份的公司一定会遇上这个问题。
至于2、3、4,更多的是出于无奈。
这里就涉及到了公司的驱动模式。
在非技术驱动的公司,这种情况会比较常见。

给垃圾代码定好优先级,
给垃圾代码分配好计划和时间。

垃圾代码的产生原因很多且难以避免,
有的代码或许当时当下确实是最优的解决方案,
只是随着时间和进度的推移,逐渐的变成了 过时的代码 而已。

据本人不靠谱瞎吹,99%的公司都会有垃圾代码。
请从战略上重视他们。而不是等到着火了才去买灭火器。

请把 必要的 代码维护和新业务开发放到同等重要的位置。

3. 技术需要继承和流动

代码不是积木。

当你司的代码传承断裂时,就变成了魔法和黑洞。

这就是为什么员工离职时一定要做好交接,
而代码的架构和规范一定要尽可能的完善。

曾经见过知乎上有司在项目完成,上线前三天要求大部分技术人员离职。
young! simple! naive!
黑洞等着你。

代码是开发者的思想。

思想是需要交流、碰撞和变化的。
这里并不是提倡公司人员的高流动,这样只会加快黑洞的产生。
我想说的只是提倡思想上的交流。

提倡学习新的技术,尽可能的拥抱变化。
鼓励思想交流,甚至碰撞。
并给予适当的尝试和犯错成本。

除此,
还需积极谋求友司人员互相交流。

个人的思想是有惯性的,甚至可以说是狭隘的。
至于狭隘的程度与个人的视野、思维、技能等因数有关。

积极交流,积极与外界交流。
当对内的碰撞到了一定的程度后就只是闭门造车了。
更可怕的,还会形成无知与自大。

作为个人,不要畏惧外界,积极寻求交流。这是每个人都明白的公理。
公司和团队,也一样。

4. 产品的无序频繁变更对技术的影响是毁灭性的

上一条已经提到了代码需要继承。
罗马不是一天建成的,产品也是。

或许你只是有个大方向,对产品的整体形态并没有一个清晰的脉络。
此时此刻你需要大量的尝试和变动,去观察市场的反应。
于是开始尝试各种方法希望能够尽快俘获市场的芳心。

这未必是错的。一切都要跟随当前的需求来定。
但是在这个阶段,就不要去组建一个专业的开发部门了。

没有一个工程师愿意去花费大量的物料、精力。
去设计制造一个第二天可能就会被炸掉的摩天大楼。

外包更适合你。

5. KPI !!!

适当的KPI是大型团队和公司简化管理的神器。
不能否认其在管理中的地位和作用。

适当的KPI是奔跑的燃料。
恶劣的KPI是顽固的疾病。
过早的KPI是毁灭的炸弹。

即便是在代码架构中也有叫做 过渡优化过早设计 这样的理念。

管理中更是如此。
在扁平化概念不断盛行的今天,
依旧有许多规模不大,却各种主义盛行的企业。
深处其中,十分绝望。

6. 没有银弹!

“招一个牛逼的大神,把公司的技术搞起来。”

企图只靠一招打天下的想法,都是愚昧、无知、恶意的偷懒。
既是行为上的偷懒,也是战略上的偷懒。

其程度就如同 “我有个改变世界的想法,只差一个程序员了” 一样恶劣。

架构、流程、管理,
如何追求团队中每个人的最大积极性和最大工作能力的发挥。
都是仅凭个人无能为力的

请不断的思考和探索。
需要做的事情还有很多。


To be continued……
2016-05-18 00:52:26


昨天去和技术总监提了离职。
总监开出了涨薪原薪资50%+作为交涉条件。

已拒绝

由于在试用期,希望能在下周完成离职手续。
被拒批,双方僵持近1个小时。
个人并不希望闹得太僵,毕竟共事一场。
终定在6月1日办理离职。
并需离职前给指定几名员工进行两场职业培训。

虽然手下人员技术不强,但是短短一个月时间已经能看到其不断进步。
似乎看到了两年前的自己。

这是我在这家公司最开心的一件事。

祝愿其一路成长。

2016-05-20 22:21:37


顺便再说说新技术的一些看法。
前端早已经进入了开荒暴走期。
新的工具、方法、技术层出不穷。

适合自己的业务的技术,才是最好的。

新技术的推广没有那么困难。
如果感到困难了,那只是表示这个技术现阶段还不是那么合适当下的业务而已。

在新东家这边技术实力并不强的地方,
使用gulp+es6+stylus的开发环境。
一路上并没有遇到什么阻碍。

当然react就不太可能了……

一切都和当下的业务和人员有关。
合适的就是最好的。

就算是新东西也不要畏惧,不是所有的新技术都有着极高的开发门槛。
很多时候只是缺了一个人去推动罢了。
考虑好当下的情况,取最合适的开发模式。(当然花费必要的构建时间不可避免)
不要畏惧,轻轻一推就好。

so easy~