前言

今年给自己定了个小目标，写文30+篇，可一直不知道该写什么，每每想写点技术上的分享的时候会发现已经有前辈写的不能再好了。思来想去，觉得我还是更适合写东西给自己而不是分享，分享是需要考虑大众的，写得好读者们可能会喜欢，写的不好，读者们一定会讨厌。而写给自己就不用在乎那么多，权当是记个笔记，日后复盘。

结合最近对工作的一些反思以及阅读完《人人都是产品经理》之后的感悟，来谈谈自己从工作以及书籍中的收获从而弥补自身的不足。

感悟一：以用户为目标来看待编码

在我看来，其实本质上来说互联网行业就是个服务行业，我们程序员只是这个行业众多服务人员中的一种。可以类比为餐馆里的厨师，厨师要求做出的饭菜要色香味俱全，用户吃完都说好，下次还来。同理，我们也要时刻的谨记，”用户才是上帝”。

但是”用户是上帝”这句话我觉得并不准确，主要有两点疑问。

• 第一点是站在技术人员的视角，到底那些人是我们的用户呢？
• 第二点是上帝到底喜欢什么？我们得知上帝的喜好才能投其所好呀。

继续分析，以我为例，作为一个前端工程师，那些人是我的用户呢？其实我认为大致可以分为两类。

一类是旁边的同事，包括同组的前端同学，以及相关的测试同学。因为我们有时候维护的是同一个项目，写的代码都是要给彼此阅读的，所以可以理解为我写的代码是“产品”，而要阅读我代码的他们自然就是我的用户啦。

第二类则是会使用我参与的项目的”真实用户”，这个也好理解，我的代码最终变成产品中的某一环，所以使用该产品的用户自然也是我的用户。

说到这里，好像还是只是在提这一段的标题的前半部分-以用户为目标，并没有说如何去看待编码。别急，继续看。

当你的用户是同事时

本篇开始之前，先问各位一个问题，你希望你的同组伙伴写出的代码是什么样的？可以来评论区留言回复一下哟。

将自己写的代码作为产品，同事作为用户的话，我会认为我的代码至少应该有以下几个特点（并不代表我目前有这个能力?）

• 易读（没有注释的大量代码让之后的同事怎么维护？）
• 简洁（尽可能一个功能点编写一个函数里，目的也是为了好维护）
• 规范（不遵从项目中统一的规范就好像一个士兵不听部队的指挥）

那么该如何达到这些要求呢？我的理解是仔细，其实这部分只要用心就能做到，没有刻意去做只能说明自己对于项目的可维护性没有任何意识。同时我也觉得大家更愿意和这些注意细节的工程师共事。为了自己长期的职业生涯考虑，还是要努力的提升自己的代码质量呀。

当你的用户是产品的使用者

这个时候要考虑的问题就会更多并且更慎重了。因为你代码写的拉胯让人不舒服，至少最多就被骂两句。但是一旦你写的程序一旦出了问题，这就是事故了，会影响到公司的收益，说难听点就是你要承担的后果很严重。甚至可能会失业。

这里绝不夸张，说的这么难听是为了提升大家对于产品的意识。

言归正传，当你的用户是产品的使用者，你认为用户希望使用的产品拥有什么特点呢？

在我看来应该有以下几点

• 基本功能正常（这是最基本的要求吧，打车软件最少可以打车吧？点餐软件最好可以用来点菜吧？）
• 页面美观（人是视觉动物，留住用户的心就得留住用户的眼）
• 性能流畅（卡顿，掉帧，崩溃你能忍那个？）
• 安全（有bug我还能接受，有病毒谁敢用）

如果在考虑到用户的基数比较庞大，还应该考虑

• 多端兼容（凭什么可以在手机上运行，电脑上却没有？这个按钮怎么在平板上怎么会这么大呀？丑死了！！！）
• 等等

以上只是站在我个人的视角去考虑的，关于产品的优劣仁者见仁智者见智，大家可以各抒己见，但我认为通用的特点还是那么几个，总结而言一句话：好用，好看，好安全。

回到正题上，我们该如何在开发过程中去帮助产品达到以上几点呢？

其实我还是那句话，要有产品意识。如果你真的意识到了自己的编码可能影响到很多很多使用你参与开发的产品的时候，你自然就会在编码的时候注意自己的代码质量。

举个例子

刚开始的时候我会为了完成任务，会去写一些可以实现目标需求但是完全不考虑内存，性能的代码。你也理解为以后这些代码都会变成屎山的一部分。比如写react代码时疯狂的setState, 有几个变量就让页面渲染几次，现在会去想着能不能将其中的一些合并成一个减少页面的刷新频率。

还是就是内存，对于那些每次页面刷新都要去循环处理的数据其实是可以用map缓存一下的。

对于CSS，能不写死就不要写死，是页面本身去做适配。

这里我挺想贴出代码来给大家看一下的，但是这样做不是很好，而且这篇文章本就不是什么技术文章，属于杂谈吧，所谓就纯扯淡，大家看个乐。

感受二：要有效率的搬砖

这段时间感觉自己大部分时候都在事倍功半，花了很多时间做的工作却很少，经过认真反思之后，对自己之前为什么工作效率低进行了复盘以及总结了一下在之后应该如何提升工作效率。

欲速则不达

急于求成可以很贴切的形容这段时间的开发心态，对于到自己手中的需求往往希望迅速的将其解决然后去接下一个，提高自己的产出，而忽略了需求开发前的思考过程。因为一些需求它或许并不是表面上看上去那么简单，或许技术上实现没什么难度，但其实需要你很细心，尤其是C端，样式上不能有任何问题，而一昧的追求速度会导致质量上出现问题。

贴语: 要在数量和质量上寻找平衡点，花尽可能少的时间保质保量的完成需求。合理的管理自己的时间，将需求开发的过程细分到每天要完成多少任务量。

谋定而后动

这里和上面那个缺点其实很相似，那就是不注重开发前的思考过程一昧的追求速度，最终导致质量出现问题，然后前面省出来的时间花费到后面修改上去了，得不偿失。

另外值得一提的是，以往开发习惯是边写边调，最后验证，但是这种开发习惯要慢慢的摒弃掉，因为跟不上的现在的开发节奏。现在应该是开发前多花点时间想想之后要怎么写，然后再”下笔如有神”，最后细节出再去微调。

贴语: 刚开始这种开发习惯的转变可能会有点不适应，但是必须得去做，不然自己将永远是个低效的码农，空不出其他时间做更有意义的事情。

工欲善其事，必先利其器

作为一门工程师，要熟悉自己手里的语言以及开发工具。比如对于CSS，之前只是碎片化的学习了一下，知道有哪些属性，大概怎么去用，面对简单的UI当然是没用问题，但是万一要做的是东西不简单甚至要有不俗的动画感，就彻底傻眼了。

另外就是开发工具了，我用的是VSCode，因为对它的不熟悉导致我在前期的开发过程中范了很多很傻的错误，尤其是在git的使用上。其实如果可以熟练的使用开发工具，必然可以帮助我们大幅度的提高工作效率，至少在格式化代码，调试代码等除开发外的时候帮我们很大的忙。

贴语: 找篇文章好好了解一下自己所使用的IDE的全部功能。

基础不牢，地动山摇

扎实的基础知识绝对是高效完成工作的前提。所谓读书破万卷，下笔如有神，当你对一门语言或者一门技术的理论知识掌握的十分熟练时，我相信你会在编码的时候绝不会有经常阻塞的时候，而且在遇到难点的时候也会有很多思路去解决。基础知识可以觉得一个程序员能走多远。

贴语: 扎实的基础知识帮助我们高效的完成工作从而有更多的时间学习其他的知识，形成正反馈。所以即使再忙也不要忘记学习。

结语

总结一下以上几点

• 编码时记得考虑对产品的影响，考虑对用户的影响，注意细节，不急于求成。
• 有效率的完成工作，保量的基础上记得保质。
• 编码前多思考，编码时仔细认真，编码后也要记得学习。