闲言碎语——第二期

关于注释

团队协作的代码，风格迥异，经常从命名和注释的风格，就能猜到是哪位同事的杰作，但大部分时候，我都不建议在代码中增加注释，当然，这是针对优秀的开发来说的。

首先，一段好的代码，是可以自解释的，根本不需要额外的文字来描述其含义，需要注释的代码，仅仅是那些包含业务逻辑或者算法逻辑的代码段，通过注释可以让其他开发者尽快了解其功能。

下面先看几个有意思的注释。

// 时间
var time: Long

这种注释，你是怀疑你的同事没学过英语吗？进行下优化。

// 开始阅读的时间
var time: Long

这样确实完全体现出了注释的优势，因为如果没有注释，你根本不知道这个变量是干啥的。再进行下优化。

var timeToStartReading: Long

这样的命名，还需要注释吗？

所以，命名很重要，一个全新的项目，命名完成，项目就完成了一半，这是一个康姓开发者的原话，虽然有点夸张，但是代码中一个好的命名，会让代码像读散文一样，命名长点无所谓，关键是要描述清楚其最核心的含义。

关于英语

英语很重要，特别是对于编程来说，当然阅读文献、Google之类的老生常谈的事我就不提了，再举几个简单的例子。

// 标题
var title: String
// 副标题
var subTile: String

这样的代码，我觉得是打你英语老师的脸（真不是拼错了）。

还有一种代码，就是各种manager、各种controllor，这样命名的代码，也不是好的代码。如果说我们的代码是一篇文章，那么这些方法名，变量名，就是我们的大纲，如果大纲写的不好，可想而知，代码一定很难让人称赞，这也是为什么很多中国人写的代码，总是觉得和外国人的相比就是差一口气，其实这也难怪，毕竟英语不是我们的母语，大部分的程序员都很难像外国人一样用丰富的词汇量来编码，但是，我们可以多花一些时间在命名这件事上，即使英文不行，有Google有百度，总会找到合适的命名方式。

代码复用

话说天下大事，分久必合，合久必分。没有什么架构能复用天下，所以所谓的代码复用，也都是子虚乌有的事情，老夫就喜欢一把梭（当然，这也是开玩笑的）。

那么究竟写什么样的代码需要复用，什么样的代码不应该复用呢？

首先，我们需要把代码进行划分，先问问自己，你段代码，是属于Ability（能力），还是属于Business（业务）。

属于Ability的代码，一定要考虑复用，即考虑其通用性，而属于Business的代码，能不复用，就不要复用。

举个简单的例子，现在有AB两个业务都用到了同一个能力做一个类似的UI需求，那么这个能力一定是要抽出来作为可复用代码的，甚至是业务完全无关的通用函数，而AB这两个看上去类似的UI需求，虽然现在复用可以减少代码量，但是——话说天下大事，分久必合，合久必分，一旦业务需求发生改变，那么复用的代码就会变成灾难，各种if else会让后面维护的同事崩溃。

业务开发写的代码，是让人能够持续维护的，而不是用来展示你的代码水平的，simple is fast，越是简单的代码，越是能够更好的迭代，所以，去掉那些所谓的复用、所谓的抽象、所谓的设计模式，先想想是否需要，再来考虑设计。

碎片时间

自从有了宝宝之后，平时在家能闲着的时间几乎完全看宝宝心情了，而上下边从地铁变成了开车，原本地铁上的一些碎片时间也被开车征用了。所以，周末的时间就显得尤为重要了，平时的时候，会在各种渠道接收一些碎片文章，各种群、朋友圈、朋友的推荐等等，这些碎片文章大部分是一些比较片面的，线性的文章，我一般都是先粗看一遍，如果发现有什么亮点，就会收藏起来，否则支持pass，然后，再我的某个碎片时间，比如哄宝宝睡觉，等宝宝睡觉，看宝宝睡觉这些时候，再把这些平时粗筛的文章拿出来看，这次再看有哪些可以被我吸收的知识，然后给它打上tag，最后在遇到一些问题的时候，就可以从这些tag中，寻找答案，所以，一般一篇好的文章，我会读三遍以上，而获得这些碎片文章，则是我碎片时间的主要目的。

碎片文章其实是有很大隐患的，因为长期只从片面的角度看这些文章的东西，会让你的思维变得混乱、焦虑，所以你需要一段时间就进行一次磁盘碎片整理，将这些碎片文章，添加到你自己的知识体系树上，只有让这些碎片成为你的知识体系的一个根节点，这些碎片文章才是有意义的，否则，这些碎片时间就完全被浪费掉了。这就是为什么，我看了各个大佬的干货，却依然成不了大佬？

线上事故

最近团队内部发生了不少线上事故，找找原因，最后被某个开发背了黑锅。其实，现在这么大的团队，不管是什么线上事故，一定不是某个人的问题，而是团队整体的认知偏差。一个程序员会出的问题，换一个程序员，大概率也是会出错，除非这个程序员经验老道，所以这样一个问题，一定是整体链路上的环节缺失，也许是上游代码的逻辑漏洞，也许是测试用例覆盖不到位，也许是代码架构拆解不好，鲁棒性不强。

这么大的一个团队，如果全靠某个程序员的嗅觉来避免风险，那就是扯淡，当发生线上问题时，整个团队都应该反思，这条链路到底发生了什么，导致一个年轻的程序员就这样背上了锅？

关于成长

开发者的成长路径，是每一个程序员都要时刻思考的问题，否则，经过时间的筛选，你就泯然众人矣。

在我看来，程序员的成长有三个境界。

• 出入职场：专攻技术点，针对某个技术、某个体系不断探索，挖掘深度。

• 小有所成：这个时候，你不再关注某个具体的技术点，而是会站在整个链路的基础上来看待问题，将一个个技术点串联起来，形成脉络，不管是业务架构还是知识体系，形成链路的知识，才是这个阶段最大的追求。

• 大有所成：在这个阶段上，更多的是需要进一步站在团队的角度上看待问题了，为团队抉择最佳的技术方向，为团队拓展最佳的开发实践，让团队创造其应有，甚至更高的价值。

架构评审

每个全新的多人协作需求，实际上都需要进行架构评审，架构评审实际上不用非常正式，也不用PPT做的多好，一帮人聚在一起，拆分需求，主导者讲解需求的一个个细节，其他人逐渐了解需求的全貌，最后主导者提出架构的设计，其它人来思考这个架构是否合理，可能半小时就足够了，那么为什么要做这件事情呢？这就是因为每个开发者的知识广度不同，也许在你的意识里，这个需求只能使用A技术来实现，但另一个程序员可能了解其它的技术点，用B技术来实现可能更加方便，或者说，这个架构在某些场景下，可能出现什么样的问题，这就是评审的意义，让更多的人帮你云填坑。

同时，通过架构评审，也让一些初级开发者能够拓展眼界，这对于他们的成长，是非常有用的。

三个臭皮匠顶个诸葛亮，即使团队里面没有什么大牛，经过评审，三个人帮你做一个需求，也会好过你一个人独自去面对各种意想不到的问题要好。

向大家推荐下我的网站 https://xuyisheng.top/  点击原文一键直达

专注 Android-Kotlin-Flutter 欢迎大家访问