职业与管理

一般而言，项目的任务计划都是由项目负责人制定的，其中需要明确每一条任务的优先级、开发周期和开发负责人。 但是，有些项目负责人的技术背景是前端，有的是后端，还有的是终端。 这就会遇到一个问题：他们怎么去制定其他技术栈成员的任务并进行验收？ 在此之前，我们默认都是由项目负责人完成这些工作的。比如，项目负责人张三是前端出身，现在他要给后端的李四制定开发任务。 通常的做法是，张三会和李四沟通要开发的功能，然后由李四给出功能开发所需的时间，接着张三填写任务时间，任务安排便完成了。 这里就存在可操作的空间，因为李四给出的时间没有第二人进行审核。而张三是前端出身，并不具备审核后端任务时间的能力。如此一来，任务安排就完全取决于李四是否厚道了。 我们一直反复强调人性，可依赖人性做事情，迟早会出问题。 今天李四心情好，可能就凭良心给出合理时间；哪天他心情不好，或许就会把任务时间拉长，好趁机摸鱼。 写到这里，我想起 2020 年的几场培训，培训老师说过的一句话让我印象深刻： “如果你不想吃亏的话，要以最坏的情况去判断你的员工。” 即便李四为人厚道、兢兢业业，不会偷奸耍滑，那你能保证王五、赵六也不会这样吗？ 你真的有时间和精力去仔细分析每个人，或者持续观察他们的一言一行吗？ 那样的话，你自己就不用干活了。 所以，还是要回归到流程规范上来，不回避任何问题，把它暴露在阳光下，通过望闻问切，仔细分析原因和我们的诉求。 接着就是大家沟通达成共识，用规定来约束，用流程从源头解决问题。 那接下来，如何从流程规范入手解决这个问题呢？ 这要从我们的目的出发，我们的目的是对任务进行有效制定、跟进和验收，而不是流于形式。 既然要 “有效”，就要实事求是，杜绝虚假。而规避虚假的办法，就是专业的事情交给专业的人。 现实情况是，项目负责人并非全能全知，所以可以把这部分工作交给对应的同事来执行，引入技术端负责人的角色。 各项目可根据实际情况，设立前端负责人、后端负责人和终端负责人。他们的职责是协助项目负责人明确对应技术端任务的开发所需时间，跟进任务进展，并负责验收。 整个项目的人员架构就变成：项目成员 - 技术端负责人 - 项目负责人。 那么，项目成员的任务申请时间变更，由谁来审核呢？ 本来我觉得，项目的全部任务本应由项目负责人审核，而技术端负责人已经对开发周期（即天数）进行了把关，项目负责人依据这一点判断即可。 但技术端负责人需要覆盖三个关键环节：制定、跟进和验收。变更属于跟进部分，如果这一环节改由项目负责人执行，整个任务的生命周期就无法形成闭环了。 在项目管理系统中，曾经的设计思路是：项目成员的任务时间变更，审核人都是项目负责人。 如果现在引入端负责人的角色，那么技术端成员的任务时间变更就应由对应的技术端负责人审核，而技术端负责人的任务变更则由项目负责人审核。 至此，我认为可以解决项目负责人如何制定、跟进和验收不同技术栈成员任务的问题。

在这篇文章《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中，已经讲明了当前项目过进度的方式：要求各项目成员到前面的座位来，把上两周以及下两周要做的工作情况汇报一下。 但是，在执行大半年的时间里，发现有的项目成员在会议上汇报自己任务情况时，只是简单说明内容，两三句话就说完了。 怎么引导项目成员更多地反馈工作中的情况，而不是让会议变成形式化、流水账式的无意义会议呢？ 我反复思考了一下，项目成员为什么不想说那么多呢？这个点其实在《19 - 过进度方式二：项目成员依次说明和演示任务完成情况》中也有过分析，这里就不再过多赘述了，无外乎就是多一事不如少一事 —— 只要我说得越少，问题也就越少。 不过，我也能想到其他的可能，比如 “就是线上修复了几个 Bug，没有什么可说的”“就是正常的功能开发，没什么可说的”“我做的是其他项目的，跟其他人关系不大，没什么可说的”。 关键点就在于 “没有什么可说的”。 为什么没有什么可说的呢？ 难道每个人在开发的过程中，真的一点问题都没有吗？ 每一条任务的制定，都包含需求、方案、研发、技术笔记和验收等多个环节。 这几个环节中，总该有可以说的点吧？ 但是，为什么没有什么可说的呢？原因就是没有做好相关的工作。 很多需求只是一句话，或者口头说一下；很多方案也只是当面沟通一下，沟通好就完事了，没有整理成方案文档记录下来。 至于研发过程中遇到的问题，有些 Bug 在没解决之前是 Bug，解决之后恍然大悟，就会觉得问题不值一提 “原来如此，我居然会犯这个低级错误？” 所以，也就觉得没有什么值得总结和记录的了。 还有技术笔记，写这个是要花时间的，完全看每个人是否自觉去做，那真的太难了，大多数人的想法是，还不如省下这些时间去做下一条任务。 甚至，有些人会觉得，这种知识点还要写技术笔记，会不会让人觉得自己技术很菜、水平很低，还不如不写。 任何问题都要透过表象抓住本质，一般这种问题，只是从人身上入手，效果不会很理想的，你可以口头要求对方一次两次，过段时间，只要你稍微疏忽了，对方也就松懈了，所以，还是要从源头去解决，也就是要从流程入手、从规章制度入手，经过沟通讨论，定下一些规定，让大家一起遵守就好。 比如，项目负责人在制定任务的时候，需要把任务要求写清楚，任务要先整理详细的需求文档、解决方案和技术笔记。 之前可能只是 1 条 “支持 10 万台设备接入”的开发任务，里面涵盖着想让成员写各种文档的期望，现在这个事情直接挑明了，拆分成 3 条任务： 支持 10 万台设备接入需求文档 支持 10 万台设备接入解决方案 XXX 框架基本使用、疑难问题解决等技术笔记 这样，就把之前依赖项目成员自觉的工作，变成硬性要求，以任务形式下达，让工作从无序变成有序，从无条理变为有章法。 在这个基础上，项目进度会议中项目成员汇报进度时，就可以把这些资料都过一遍，然后再进行验收，应该能有效解决会议流水账的问题。

背景 在项目开发过程中，代码评审还是很重要的，主要是为了解决代码规范、功能开发方式、相互学习等问题，代码是否符合规范，关系到项目成员协作的问题。 如果写出来的代码风格五花八门，那么，在沟通交流上面，就额外增加了难度，而这是完全没有必要的。 除此之外，上面说到的功能开发方式问题，意思就是，每个人都有可能是孤岛，一个人的想法可能会有缺陷，如果多个人沟通以及探讨，相互学习，有可能会从不同视角发现潜在的问题。 人工代码评审 一直以来，我们要做项目代码评审，通常都是有这几种方式，比如项目组成员交叉验收各自的功能代码，然后把问题整理到文档，再一起组织代码评审会议，把问题都过一遍，然后安排任务去调整。一方面解决了代码存在的问题，另一方面通过深入交流，大家相互学习。 还有，就是在 GitLab 代码合并阶段，项目成员发起功能分支合并至主分支，由项目负责人去审查项目成员提交的代码分支。 如果没有问题，则合并到主分支；如果有问题，则反馈给项目成员。待项目成员修复完成再次发起分支代码合并，然后，项目负责人确认之后，合并到主分支。这个应该就是常规的代码评审流程。 但是，随着团队的发展以及对降本增效的要求，开始着手去研究，团队中哪些工作是有可优化的空间？ 项目负责人承担的工作事务越来越多，怎么去有效简化无意义的工作，成为了当前亟需解决的问题。 SonarQube 基于上面降本增效的目的，我之前调研了 SonarQube 代码检测工具。 它基本支持了市面上的 Java、Go、JavaScript、TypeScript 等十多种语言，并提供几千条代码规则，用于代码规范检查、代码优化提示等代码质量问题。 支持结合 GitLab 的 CI/CD 做流水线事件中断，方便代码提交人员，自行去查看反馈的问题。 并且，提供 SonarLint 这个 IDE 插件，在代码编写时，就反馈存在的问题，并给出修改建议。 后来为了减少项目负责人的代码评审工作，整个部门的项目，就都接入了 SonarQube 来实现代码问题检查工作。 在使用 SonarQube 的过程中，给我印象深刻的主要有以下几点： 如果一个历史项目要接入使用 SonarQube 工具去检查代码，这个时候，势必会有很多问题反馈，比如可能 2000 个问题，这个时候，是否要立马安排时间去解决呢？ 立马安排的话，就需要比较多的时间了，如果不立马安排解决的话，这些问题应该什么时候去解决呢？ SonarQube 提出了一个 “新代码” 的概念了，意思就是，可以不立即就把这 2000 个问题修复掉，而是在项目功能迭代的过程中，逐步把有问题的代码修复掉。 因为项目功能有迭代，意味着，这部分代码就需要去改动，趁此机会，刚好同步解决掉遗留的代码问题，慢慢地，遗留的 2000 个问题就会以这种方式解决掉。 至于哪些没有迭代的，说明功能已经很稳定了，或者功能不重要，那优先级也相对更低了。 SonarQube 官网文档的这篇说明 《Clean as You Code》 提出的这个方法论，我觉得理念还是很不错的： SonarQube 旨在通过帮助您（开发人员）确保您提交到项目中的每个代码更改都没有问题，从而确保高代码质量和安全性。通过始终提交干净的代码，您可以逐步提高项目的整体质量。我们称这种方法为“Clean as You Code”。 Clean as You Code 的核心思想是将注意力和精力集中在新代码上。在您进行功能和改进时，SonarQube 会在每次新提交时分析您的代码，并在任何代码质量问题和安全问题上提醒您。然后，您可以立即解决这些问题，并确保添加到项目中的所有新代码始终是干净的。 ...

对于程序员来说，技术网站还是很多的，我可以列举出来很多个，比如 CSDN，简书，掘金，博客园，开源中国，力扣，InfoQ、思否等。 早些年我是逛开源中国的，后来，发现了 CSDN，就迁移到 CSDN 了，但是，CSDN 广告真的太恐怖了，不到万不得已，我是绝对不想打开的，因为真的受不了这个广告， 简书出来之后，就转到简书了，继续写一些技术文章，内容主要是遇到的问题分析、积累的一些解决方案等，但是，后来简书真的吃相越来越难看了。 满屏的广告不说，文章最后本来应该就是评论区的，硬是要在这个小地方塞进去了十几篇推荐的文章，每次看到最后，想看下评论区，都要把窗口拖下去很久才行。 文章左侧还有一个 APP 二维码，一直闪烁，我都不清楚简书的产品经理脑袋里装的都是什么，完全没有脑子，阅读文章内容时，注意力老是被这个二维码的动效干扰，人都变得很烦躁，猜测这个功能的目的，是为了推流下载简书 APP，但是，在实现这个目的过程中，采用了简答粗暴的方式，真的一点脑子都没有。 再加上文章详情页，右侧推荐的文章都是那种 “庞太师与我娘亲二三事” 之类的文章，我当时就觉得受够了，简书死不足惜。 再加上 2017 年饱醉豚无端抹黑程序员事件，彻底激了众怒了，所以，就转到博客园了。 博客园的优点其实很多的，比如整个网站没什么广告，然后个人博客风格还可以自定义，编辑器也过得去，但是不知道什么原因，没有继续在上面发发技术文章，或者平时逛逛，基本上得很少用，只能是我自己的选择问题了。 最后，就迁移到极客时间推出的 InfoQ 网站了，在上面写了几篇技术文章，感觉这个网站没那么多广告，这点还是很不错的，然后不管是编辑器、个人主页都很清爽，但说实话人气确实不咋地。而且，很多文章都是太资讯、行业化了？一看就不是程序员平时写的东西。 后面，迁移到掘金了，在掘金应该是比较久的了，之前一直也是不错的，但是，最近感觉掘金的广告也变多了起来，可能是有 KPI 绩效的要求，每次打开，都要顶部撑开一个大位置，用来放广告，然后再收缩起来，不知道这个动画效果是不是没有处理好的原因，每次都感觉卡顿，然后莫名其妙的。 这一点也是很烦的。以致有人写了文章吐槽这个，有意思的是，这篇文章还上掘金热搜榜了，也不知道掘金小编是怎么审核通过的，还是有格局的，亦或是早就看不惯了，迫于上级要求，只能通过这个方式表达不满了。 然后我现在发文，是掘金和公众号一起，先是在公众号发完，然后同步到掘金，然后再同步到个人博客。这一流程基本沿用至今。 上面就是一些使用技术网站的背景，从上面的描述中，可以看到，其实，自己是疯狂吐槽简书的，挑的问题也最多，那是因为很喜欢简书的，至少一开始真的很惊艳，干干净净，简简单单的，但是现在已经全都变了。 但是，任何事情都要结合实际情况来分析，从不同的角度去看，每个人都有不一样的难处。 用户觉得广告太多，阅读体验差，网站觉得我要运营，要买服务器，要花钱的，不搞点收益，怎么活下去，你们白嫖了还到处抱怨？ 要解决这个问题，还是在于用不用。 如果不用那就眼不见为净，没有任何烦恼，如果要用，单纯去指责网站意义不大，愤怒、指责、抱怨只是短暂发泄下负面的情绪，没办法彻底解决掉这个问题。因为赚钱嘛，不寒碜。 同时，如果技术网站，要推行类似 Medium 的付费模式。我估计死得更快，我赏脸在你这个破网站上发表文章，没找你要稿费都不错了，我看点别人的文章还要收费？ 毕竟，我们没有这个付费的传统习惯，从最初的音乐、电影、单机游戏和办公软件之类的，能用盗版用盗版，这个怎么说呢，不去评判好坏了。 我也有理由说的！现在的视频网站，都什么操作？开通会员还得看广告，这不是坑人吗？会员等级还分三六九等，VIP分成了好几个档次，简直是要把用户的钱包榨干！更夸张的是，同一份资源，换个设备看还要多花钱，这也太离谱了吧！还有那些限制分辨率、限制投屏的操作，这不是欺负人吗？我可是乖乖交了会员费的好人，怎么就要被这样对待？好人就该被枪指着是吧！你们既然这样，那别怪我去找盗版了！脸都不要了！ 很多人都有过上面的经历，所以，才没办法单纯评判好坏。我们不是没有这个付费的传统习惯，我们只会为值得的东西买单。 再加上 Windows 之前之所以能在中国打开市场，并且，占据大部分市场份额，就是因为它默许了 Windows 盗版横行。而且，在开源这一块也是一样，要想让我们付费和打赏，还是太难了，我看尤雨溪入驻国内 “爱发电” 平台，想要扩宽国内的 Vue 赞助渠道，不会有几个钢镚的。 所以，回归正传，怎么解决这个技术网站的阅读体验问题呢？ 只能是折中的手段，那就是通过安装广告拦截插件来解决了。甚至定位并拦截哪些广告区域，通过这个方式，后面再浏览各大技术网站时，已经干净很多了。 至此，现在看技术博文，就是在掘金比较多了，偶尔看下 InfoQ 上的文章，因为有一些资讯或者访谈类的文章，其实还是不错的。 然后，因为之前的 ARTS 打卡活动，也经常要看下力扣的，现在这个打卡活动结束了，时不时也去看下日常的讨论，还有就是思否，这种问答式的模式其实还是很不错的，只是感觉有些时候，感兴趣的话题不是很多。 现在，基本不会怎么改变这个习惯了吧。

2020 年 7 月，因为第一次使用 Flutter 来开发项目，所以研究后发现，如果要使用 iPhone 真机调试，需要在 XCode 上运行。但当时苹果手机系统版本是 13.6，而 XCode 是 11.3.1，所以运行时出现如下提示： This iPhone 11 is running iOS 13.6 (17G68), which may not be supported by this version of Xcode. An updated version of Xcode may be found on the App Store or at developer.apple.com. 也就是说，当前 XCode 版本过低，不支持当前手机的版本。然而，App Store 没有 XCode 升级提示，我便以为 XCode 还没有新版本发布。那么，要解决这个问题，当下就是想办法让其支持 13.6 版本的手机。 于是我在百度上搜索，发现 CSDN 有很多 iOS 13.6 真机调试包可以下载，但需要积分。由于 CSDN 广告太多，我早已反感，之前攒的积分也花光了，所以没办法下载。 当时我就想，为什么别人能弄到这个 13.6 真机调试包，总不可能都是自己做出来的吧。反正我看到 CSDN 上面到处都是，都标着很高的积分，心里暗自吐槽，这尼玛是不是都你抄我、我抄你的啊。好多东西无非就是信息差，提前知道了，或者在外网看了相关讯息，拿到别人的东西，就拿到国内来卖。 如果是自己辛辛苦苦弄出来的，也认了，毕竟是自己的劳动成果。但如果是拿别人的东西来唬人，那性质就不是一样的了。 反正很长一段时间里，我使用百度搜索一些问题的解决方案，不下五六篇都是一模一样的，我都不知道谁才是原创。或者本来答案就是 Stack Overflow 上面的，只不过翻译了一下而已，也不给个链接或者标注下，真是糟糕透了。 基于这个原因，我用必应搜索，搜索到的结果很干净，没有那么多杂七杂八的东西（比如满屏的广告）干扰定位问题答案。 比如搜索 XCode 13.6 相关内容，我慢慢找，就发现了这个问题：Xcode 11.5 doesn’t support iOS 13.6?，没错，Stack Overflow 上面就有答案。 Stack Overflow 除了访问很慢，其它没什么问题。而且在这个问答里，我找到了 13.6 真机调试包下载的地方，也就是 Github 上面的iPhoneOSDeviceSupport。我看了这个项目，是好几年前的了，甚至 14.0 的真机调试包都有提供。所以我严重怀疑 CSDN 上面那些就是抄的这里的，从这里下载后，自己标上积分供人下载。 ...