如何写好代码：从团队协作到个人习惯

背景

去年我读了《代码整洁之道》这本书，试图深入探讨如何写好代码这个话题。但越深入研究，越发现这个问题的复杂性 - 它几乎等同于"如何成为一名优秀的程序员"这样一个宏大的命题。

今年，一位同事找我讨论Vue项目中的代码组织问题，特别是关于Composition API的使用方式。这让我意识到，也许应该从一个更实际的角度来探讨这个问题：如何在团队协作中找到代码质量的平衡点。

代码探讨我认为这篇文章也不是终点，可能需要一个长期的过程，之前我也有一些文献，有兴趣的可以去看下

一次代码优化记录 --- 代码审核实践（二）

代码审核实践（一）

代码封装的艺术：寻找平衡点

同事的疑问是：Vue项目中的业务相关性代码是否应该放在一起？按照我最初的建议，相同的业务逻辑应该封装成独立的function。但在实际讨论中，我发现了一个更深层次的问题：过度封装的风险。

这个和与人相处一样，如果 一个人非常爱干净，一个人非常不爱干净乱扔东西，那这 2个人相处起来就会很困难。

在团队协作中，我觉得最重要的是遵循ESLint规范，这是代码质量的底线。至于封装程度，我个人认为应该按需封装，不要为了封装而封装。同时要保持代码的可读性，让相关逻辑放在一起。对于不同类型的代码，我们应该区别对待，重要的代码需要精雕细琢，而简单逻辑则怎么简单怎么来就好。

当然，也有些编码问题我是不能接受的，比如复杂逻辑缺少注释、变量名拼写错误，以及如果移除功能都需要把对应的代码移除而不是单纯隐藏等。这些基本的质量要求还是我对我自己与团队的要求。

对于平衡点来说其实工作中还有很多，比如和不同同事以及领导沟通上，有些需求需要考虑多少DFX设计，是否对于所有代码都需要投入相同的精力等，这些都是博弈，需要一些经验。

代码整洁与个人习惯

那很多习惯我和一些同事都是自发生成的，那这是一种习惯使然，我来简单阐述下。

我在对工作环境有特别的要求：个人办公的桌面整洁、电脑桌面要清爽实用、浏览器标签页要及时清理、个人博客的整洁干净。这些细节反映在工作中，就是我产出的代码必须既好看又好用。

我注意到有些同事的电脑桌面总是堆满各种 word 或者 excel 文件，浏览器也开着十几个标签页从不关闭。我觉得这些小的细节和习惯可能会影响整个工作生涯。

我有关注过，很多部门都有乱放设备，完全不整理的情况，甚至冰箱里都堆满了很多已过期的东西。

像 Anthony Fu 和 vue 团队成员，他们甚至会去关注ESLint配置、个人博客的效果，深入到很多开发体验的工作中去。相比之下，我已经算不是很有强迫症的人了。

而且，我认为很多动力来自于解决技术问题带来的正反馈。写代码时看到控制台有报错会让我很不爽，可能代码还是可以跑，但解决一个报错就会有一些小小的成就感。这些正反馈会慢慢改善我的工作状态。

我推荐一个游戏《A Little to the Left》，这是一个益智类简单整理的游戏，我也会带我的孩子一起玩，当把凌乱的东西整齐的放到各自的地方去以后，我经常会不进行下一关，而是欣赏一下整理完后的成果，舒服~

但个人习惯不是一下子改变的，还是需要日积月累的过程，从小事开始做起，追求长期回报。

总结

写好代码没有标准答案，但关键是要认识到代码是团队资产，不是个人作品，所以团队协作应该放在首位。在代码质量和开发效率之间需要找到合适的位置，这往往是一个哲学层面的平衡问题。

培养良好的编程习惯需要从小处着手，逐步改进。我们可以向优秀的开发者学习，不断提升自己的技术水平。最重要的是要记住，代码质量是一个持续改进的过程，关键在于开始行动，并在实践中找到适合自己的方式。