阅读 107
如何为团队打造一个好的开发环境——青涩观点

如何为团队打造一个好的开发环境——青涩观点

前言:文章在草稿箱中发现,写于 2018 年,其中有一些本人青涩的观点,发表出来是为了记录自己的心路历程,当时本人是后端工程师,毕业后就职于一家创业公司,目前工龄2年半,这是我的背景,以下大部分内容纯属个人观点,包含自己的一些经历和体会,希望读者可以批判性阅读,欢迎讨论和指正。

基本需求

做“产品”应该要有一个舒适的工作环境、有效的沟通渠道、一手的需求文档和可视化(还要好用)的协助平台和监控平台,这些东西看起来非常华丽,一看就知道不好落地。等一下,先别急着下结论,我们不要有一步到位的思维,先把问题量化,一步一步来,优先解决主要矛盾,事情就变得简单得多。

“古代”人们一开始对环境的要求很简单,就是可以住人,吃得饱。随着经济的增长,人们对环境的要求也越来越高,开始注重舒适度、智能化和服务质量。

那团队中不同角色对于“环境”有什么基本需求呢?

  • 站在开发人员的角度,我想要有一个舒适的开发环境,它可以帮助自己快速成长,变得更加有竞争力,能按计划完成工作安排,按时下班,有自己的闲余时间做自己喜欢的事情等等。
  • 站在产品经理的角度,我希望有一个值得信赖的团队,他们能够快速研发出成熟的产品用于解决用户痛点,同时我还希望可以方便了解每个产品的进度和关键问题,便于我尽快确定产品的未来方向和盈利模式等等。
  • 站在测试人员的角度,我需要对质量和客户负责,所以我需要详细的业务需求文档、测试用例文档、接口文档和专项测试需要的一些指标数据,便于我展开测试工作等等。
  • ...

产品的开始,就是为了结束,产品的从无到有,都是开发人员们搭建起来的。我们如何确保“产品”可以像个健康的孩子那样茁壮成长呢?产品跟我们所处的环境有哪些因素互相制约呢?

把产品当作是自己的“孩子”

一件事做久了,会产生感情,也会产生厌烦,但是对待自己的孩子就不太一样,有时候孩子表现的不好,父母除了一些说教之外,更多的还是关心和一份作为父母的责任。

把产品当做自己的“孩子”需要从心态上去改变,首先我们需要去接纳 “孩子”,哪怕“孩子”是有缺点的。其次,我们要对“孩子”负责,对其有“抚养义务”,但如果“孩子”犯错,我们需要去承担责任,并找出问题所在,通过不断的改进,让“孩子”不再犯同一个错,这也是父母付出之后的回报(建立信心),最后,努力打造一个舒适的环境帮助“孩子”茁壮成长。

成长最好的证明,就是肯定。

做好准备

第一次当爹当妈难免会缺乏经验和理论知识,即使有劲也不知道往哪使,比如哪一品牌的牛奶产品适合自己孩子?什么样的抱姿是正确的?如何帮“孩子”洗澡?何时进食?睡眠问题监控问题等等要解决,有经验的人可能已经咨询了专业的育婴专家,学习了日常较为实用的育婴知识,妥妥的避免了大部分问题,并且还能够解决日常中大部分的育婴问题;有的人没有做好准备,各种误打误撞,临时抱佛脚,甚是疲惫。

作为开发工程师,就必须对得住工程师这三个字,软件工程理论、软件开发思想、软件设计、软件基础知识、软件开发实践、软件测试理论和实践知识必须掌握,使用到的技术和框架(工具)也必须掌握,这些大部分是大学的课程,要求一点都不高。其次,还需要熟悉产品的业务,基础架构,编程规范,集成开发环境的使用,协助方式,协助工具和平台,积极主动去了解技术的发展,如果目前还没能达到要求,没关系,大部分人学习软件知识的动力靠的是兴趣,不会可以学,兴趣是最好的老师。

能用技术和工具避免的问题一开始就尽量去避免,而不是在之后遇到了再去解决,因为未来可能会有更多的不确定因素。

举个例子,在一个小团队中,为了节约成本和快速推出产品,项目初建就没有搭建好自测环境,加上大部分开发人员本身就不爱写测试,这样会导致一种问题,一开始全力冲刺,但后劲不足,开发人员一开始就没有做好自测(单元测试,也有人叫做微测试),导致产品的质量问题随着产品规模的不断扩大,出现了各种各种的质量问题,加上工期紧张,一边修 BUG,一边还增加新功能,开发和维护成本越来越高。可怕的是,没有测试的支撑,没办法做回归测试,不确定重构之后会不会引发更多的 BUG,产品的重构难度和重构成本非常高,这个时候不是不想重构,而是不敢重构。更加可怕的事,问题慢慢进一步恶化,整个产品被打上了各种“狗皮药膏”(补丁)之后,每个人包括用户都不再相信产品的质量,即使测试人员已经对产品做了测试,但是实际上线有没有问题没有人敢保证,只能“阿弥陀佛”了,因为彼此的信任已经逐渐崩塌,整个产品的进展变得越来越缓慢,最终可能会有人离开团队,这已经关系到产品的存亡。

我们应该具备足够的储备,快速的学习能力,不断为各种挑战做好准备。

不断完善我们的环境

团队通过一段磨合期,可能会有其他的问题出现,比如团队协助效率低下、需求频繁改动、开发效率低下、程序不稳定、经常超工期和熬夜加班等问题,这个时候,就需要有人能够及早“嗅出一些不好的味道”,尽早控制住问题的规模,不要当一只“温水里的青蛙”,不然这种环境会慢慢让人窒息,比如上面提到的例子,假设一开始就有人“嗅到代码腐烂的味道”,这个时候赶紧组织团队一起沟通、商讨,尽快搭建自测环境,并附上规范的单元测试例子供开发人员模仿和学习,定期 code review,那么问题就可以在问题规模比较小的时候控制住,如果这个问题到了产品中后期才去解决,那么除了上面的要求之外,还需要补旧功能的单元测试,直到测试覆盖率到达可重构的前提下再做重构,降低重构带来的成本和风险,这个过程的成本跟项目的规模成正比,所以越早发现,越早解决,成本越低,还有非常多的因素导致这个过程非常艰难。

在考虑资源、成本、风险和效率的情况下,有追求的开发人员对开发环境进行如下改善(但不限于此):

  • 清晰的个人任务工作台。
  • 灵活的底层架构。
  • 代码规范化、模块化。
  • 易于维护。
  • 版本控制。
  • 容易编写单元测试。
  • 流畅的开发环境。
  • 故障恢复,回滚,邮件通知。
  • 可视化监控。
  • 能做 CI、CD,就不要人工来做。
  • 能自动生成,就不要一个一个敲(比如自动生成代码,自动生成测试报告,自动生成接口文档、自动生成测试文档,自动生成覆盖率报告等等)。
  • 能自动检测,就不要人工检测(比如代码风格检测工具)。
  • 能用工具解决,就用工具解决(比如代码托平台,issues管理,各种可视化工具等等)。
  • ...

有资源的公司 + 有能力有经验的技术 Leader 一开始能够做好大部分基础设施工作,那对于项目中后期来说是相当有优势,因为开发人员不再需要关注技术上繁琐的重复问题,而是能够专注于业务问题,从而提高整体工作效率;对于开发人员来说,既能腾出时间了解业务知识,又能学习到现有平台的技术,对谁都有利。

这样就够了吗?还是不够,现在技术革新非常快,说不定哪一天又有更高效的工具出现,如果天时地利人和,就引入项目,如果能够自主研发,那已经非常厉害了。

这样还是不够,要做到精益求精,家里需要经常打扫整理才能整洁卫生,代码也一样,在测试的支撑下,有时间应该把那些难以维护的代码都重构一下,为以后做好准备。

不要想一步到位,一竿子插到底,一步一步来,优先解决主要矛盾

建立良性的沟通渠道

  • 每周例会,了解进度,了解业务方向,降低信息不对称情况。
  • 每周一次沟通会议,内容较为开放,主要促进团队沟通,互相学习,可以讨论工作中遇到的问题以及解决方案,分享等等,时间控在 30 ~ 60 分钟。
  • 举行活动。

良性的沟通其实不简单,我自己还在寻找和尝试。

双赢

个人认为,在工作中,我们需要跳出自己的立场去看待问题,这样可以让我们看到更多的客观因素。为什么?因为只站在自己立场看问题大多时候的受益方只是自己,这其中也考验一个人的说话方式和说话技巧,我曾经也是吃过这个亏,我非常急切提出重构的需求,这个需求已经提了非常久了,一直没有实施,随着产品需求越加越多,导致系统更加交互错综复杂,代码难以维护,系统稳定性差,单元测试几乎没有,每次部署都要小心翼翼,烧香拜佛祈祷别出问题,但是产品和 leader 都比较重业务和商务,对技术的了解非常欠缺,加上团队的资源不够,开发团队几乎没有任何士气,在一次会议上提到了之后产品的优化方向,却没有为产品预留出重构的工期,我当场就生气了,搞得非常不愉快,现在觉得当时的做法非常愚蠢,如果我先沟通好,把重构计划定出来,再跟大家说明情况,重构对产品和我们的重要性,大家都是受益方,相信这样肯定比之前做得更好。

现在都是团队合作的年代,每个人都会顾及到自己的利益。

沉淀

技术、业务和人与人之间的信任都应该能够沉淀,这样才有利于持续发展。

看了阿里的《企业IT架构转型转型之道》后,才明白原来技术和业务的沉淀是可以通过打造一个优秀的产品平台来帮忙催化的,虽然有一定的局限性,但是对于学习来说非常有帮助,详细内容可以参考书本。

技术和业务不用说,比较好理解,需要一笔一划总结出来。

信任这个东西一旦失去,就很难的挽回,所以一开始就应该有一颗做好产品的心,而且还需要足够的理论知识和实践经验结合。

没有蠢的人,只有懒的人。

总结

用正确的理论指导正确的行为。

文章分类
代码人生
文章标签