【软实力分享】如何做一个好开发

Hey，屏幕前面的朋友们大家好，我是一名程序员，目前在深圳做Android。
做开发有些年头，时间漫长，五味杂陈。公司和人也见了不少。觉得有必要写一篇关于程序员职场软实力的文章。希望对想在工作上做的好的同学有所帮助，也算让我这点渺小的经验发光发热。

本文适合人群

• 刚写Helloworld的萌新
• 希望做一个好开发的一线程序员
• 职场老鸟想看看有没有干货

目录：

• 为什么要做个好人
• 人在江湖身不由己
• 首先确定自己的身份
• 别着急动手，先规划要怎么做
• 靠谱的任务拆解和估时
• 高质量的完成编码
• 更有效的沟通
• 创造价值

那么我们开始吧~

---

为什么要做个好人

并不是所有人都想努力上班，提高自己。也许一个天天和你一起吃饭的同事，下个月就跳槽走了。也许一个你以为不好好干活要被开除的小白，其实是正宗的富二代，股份拿的比你领导还多。

不过不管你是憋着要另起炉灶，还是芸芸众生，我认为都有必要做一个“好人”。

当一天和尚敲一天钟，这钟不仅要敲还要敲得响。未来在公司长期发展自然不必多说，哪怕要走也要给人留下好印象。

公司里的人谈论，“害，去年离职那个XXX，如果他还在就好了”。这也是你的人脉资源不是吗？

人在江湖身不由己

公司是个大熔炉，各种大佬前辈、小白萌新在里面水煮沉浮。没人能用一句话简单概括任何一家公司。

不过不管在哪家公司，开发遇到的问题其实都差不多，比如：

• 容易延期
• 编码过程艰难
• 同事不配合
• 提测之后bug多
• 自己很努力，但总做不好事情

更棘手的是，屋漏偏逢连夜雨，问题经常一起出现。本来手头工作都要延期了，还要处理紧急的线上问题，对接的同事又不配合，自己又不太搞得定。Oh，简直让人抓狂不是吗？

首先确定自己的身份

我们是谁？

“软件工程师”

干嘛的？

“码代码跑起来提测改bug完事儿”

没错，但这是理想环境下的软件工程师。由人组成的公司环境很复杂，面临的问题远远多于编码。比如线上APP一个广告无法展示，可能是客户端、服务端、数据库、脚本、现场环境各种原因导致的。被叫过来看问题的开发如果一上来就扑在代码里很可能就不能自拔。

“但我是开发，我不看代码看什么？”

看线索啊~ 如果你先试着收集目击证人的“口供”，确认现象和频率。在这之前谁动过哪里，上线了什么功能。

如果得知这是另一个开发组的人做了广告过滤的功能，甚至一行代码都不用看，调一下过滤配置就可以解决，岂不美哉？

想做一个好开发，首先要确定自己的目标，也就是我在这家公司要以一个什么身份存在。我们不能只做一个会编码的工具人，应该成为的身份是：

推动公司产品顺利获利的问题终结者（刚好熟悉编程）

任何问题只要经过你，就会得到解决。解决方法可能是编码，设计，调查，找其他人帮忙。这样你在公司的地位就不只限于一个程序员，未来的可能性也大得多。

不因为涉及到的了非技术能力就推诿，因为那样你就变成了工具人。

别着急动手，先规划要怎么做

不管是一个迭代开发任务，还是解决线上bug、搭建环境，甚至帮团队申请开发设备。事无巨细都不建议立刻动手，最好先静下来想一想这事儿有没有更好的方案，怎么安排顺序才能完成得更好，而且不影响你的当前任务，甚至还能帮助你的其他工作。

条条大路通罗马，但只有一条路是最合适的。

如果只简单的希望所有问题都立刻完成，势必会打断你当前的进度，也将做不到“所有事都立刻完成”的希望。

合理的时间安排。

首先你手头要做的事情要有个列表，包含他们的截至时间，举个例子：

现在接到了一个任务是“上报日志功能开发 7天后交付”

而你现有的任务有3个：

• 重构日志工具，美化输出 3天后交付
• 参加下个迭代的需求评审 2天后交付
• 购物车增加新功能 10天后交付

那么显然你立刻去做“上报日志”是不合适的，最好放在“重构日志工具”的后面对吧。如果你先做了“上报日志”，那“重构日志工具”必然影响“上报日志”。

等到3天之后要开始做了也别急，先去问问产品“上报日志”功能有没有什么需求变动，避免信息不对称，防患于未然。

任务规划

不同类型的任务需要不同的规划：

开发的规划主要是预研、设计（UML）、联调准备（比如和对接人预约时间）

解决疑难BUG的规划就涉及现场调查和沟通、搭建复现环境、熟悉代码逻辑。（知道怎么改之后通常改动会很小）

这些前置工作做好了，剩下的码代码就简单了，通常只是时间问题。

靠谱的任务拆解和估时

没人希望自己的工作延期交付，在公司你会发现有些人经常延期，但有的人却总能按时完成。这和任务拆解和估时的能力是分不开的。

当完成了任务的设计工作后，大体需要做什么头脑已经很清楚了。这时要尽快将知识记录下来，作为你接下来的工作大纲。然后把每个子任务再细化，拆分成可执行的Task。以小时为单位，每个Task建议3小时左右。

比如客户端要做一个登录逻辑，就可以拆分成：

• UI-登录界面框架 2
• UI-输入框 2
• UI-登录按钮 0.5
• 接口-登录网络接口格式定义 2
• 接口-登录网络接口联调 3
• 逻辑-使用输入内容调用登录接口的逻辑 2
• 逻辑-登录后跳转页面和异常处理 2

这些Task后面的数字代表小时，可以根据你的个人速度来调整。

可以把这些Task录入Excel，方便合计出总工时，反馈给上级。注意上报工时的时候要把Excel作为附件一起提供，用来支撑你的估时。也方便上级灵活的删除/添加Task。

每完成一个Task就把格子颜色标绿，方便跟踪进度。而且也可以知道你距离做完还剩多少小时，是否需要加快速度，还是可以关注更多细节或补充单元测试。

Task不止编码，沟通、熟悉业务的时间都要写上。这样你给出的工时会相对准确，减少延期的风险。多多考虑“非编码”的Task，因为常常被忽略。尽量预留一些时间，用来处理中途遇到的其他事务打扰。

这里要注意不要故意估很长的时间给Task，这会破坏团队对你的信任。信任的建立是非常难的，需要多次工作成果输出来建立信任，可是一次谎言便会打破它。

随着估时越来越多，每次估时都可以参考上一次的结果。你也会估的越来越准，团队也会更信任你。

高质量的完成编码

编码质量影响提测之后的bug率，也决定了将来有多大可能去线上填坑。所以这是需要严肃对待的事情。

不过由于编码的时候不关心质量也没人知道，所以很少引起重视。

写单测是个好手段，不过很遗憾很多公司没时间写。code review也很难全面覆盖，因为review的人也未必在做你的事情，所以业务逻辑方面有问题他基本是发现不了的。

sonarqube或者lint其实做了很多review代码的工作，比如流是否close，是否没判空之类。所以业务上的漏洞目前还是只能靠自己。

这就需要在编码之前对你在做的模块有充分的了解，如果不是，就要在拆分任务时加上看代码的Task。总要知道心脏在哪再开刀不是吗。

代码的骨骼搭建

由于已经有了编码的规划思路，现在就可以在代码里写注释或者伪代码了。

这里建议从外（抽象）往里（细节）写，比如做APP升级功能，你要轮询或者接收MQ推送来触发升级，然后下载安装包，下载完后自动安装。

这时你就可以按照已经做好的UML设计，把UploadChecker, RabbitMqManager, Downloader, ApkInstaller这些必备的工具类建立起来。

可以先定义一些函数或者接口但不要实现，用代码把他们串联起来。这样你的UML结构就成型了，至于这些留空白的具体实现，在结构稳定后再按部就班的填充。你每填好一个细节UML结构都没变，事态总是稳步进行。思路更清晰，bug自然也少了。

但如果一开始只建立UploadChecker类并从实现开始写起，可能出现虽然写的很精致，但它暴露出来的接口可能并不适应你的设计，甚至导致反工。而且很容易盲人摸象，意识不到UploadChecker如何与其他组件交互。

避免改坏原始逻辑

在增加代码时，势必会对已有逻辑造成改动。如果发觉改动即将发生，那么先不要动手，先debug跟踪一下把原始逻辑弄清楚。然后增加代码之后一定再debug一下逻辑，确保没有把已有逻辑改坏了。当然如果已经有单元测试，事情会简单很多。

注意如果是后台程序员，“这个原始逻辑”还要考虑其他微服务项目。

至于老生常谈的编码语法质量不是软实力就不在这篇文章赘述了。

更有效的沟通

沟通是程序员不应该的软肋，毕竟我们并不是纯科研技术人员，而是工程师。一个天天研究数学的博士你说它不善言辞倒也说得过去，但一个工程师扭扭捏捏的像怎么回事。

这里沟通涉及对产品、客户、下属、领导的沟通。沟通得好，死局也活了，沟通的不好那可真是阴沟里翻船，死都不知道怎么死的。

对产品经理的沟通

比如经典的产品经理和程序员，网上总是调侃说是死对头。毕竟一个说“改需求”，一个说“做不了”。

不过这只是无良自媒体以讹传讹而已。

其实作为开发，是可以在产品立项或者需求开始之前就提很多宝贵建议的。比如一些不方便实现需求，最好提前沟通。其实很多地方是可以灵活变通的，只不过不要人家原型图都画好了，甚至UI都出图了你才说做不了。难免伤了和气。

需求评审会也可以解决这个问题，不过在会上一定要踊跃发言。

另外产品其实在出需求的时候，并不太清楚开发到底哪些能做到哪些不能。这时开发其实可以主动去讲说“这里我可以做到更好的程度”，或者“这里可以做一个动画去实现更好的效果”。

如果在项目评审会上遇到已经成型的产品需求，如果的确实现上有难度要立刻拿到台面上讲清楚，这时候改至少还来得及。

客户（领导）

客户未必是指公司的商业客户。领导、项目经理、产品一般是下发任务的人，对于你个人而言其实也算是客户。对于客户来讲，他们希望你可以顺利完成任务。这就考验你对自己的判断和规划能力。

因为一诺千金，说可以那真就是可以。

最怕的是“埋头苦干”+“敢于承诺”的人，一开始说的挺好，“没问题，没问题”，等最后要交差的时候说搞不定了，这是职场里的大忌。

因为你说“没问题”的时候，客户很可能会安排在你交付的后一天去使用你的产品，甚至其他部门的进展也会依赖你的交付日。到最后你说不行，那造成的损失难以估量。

所以对于你真的没把握的事要敢于拒绝，这也杜绝了将来逼到墙角做不出来的尴尬。

至于你搞得定的，按照上面介绍的“任务拆解”去估出合理的交付日期，汇报给客户。按照自己的规划进行开发。

给出可演示的阶段性成果时主动去汇报进度。客户看到自己安排的事情稳定的推进，自然会对你刮目相看，将来会有更有价值的任务交给你做。

当然如果中途有风险，也要及时反映。越早提出也许就越有回旋的余地。如果真的不可抗力导致任务失败，至少客户也会认为你这人办事靠谱，知道提前降低损失。

注意不要因为对方职级比你低或者平齐就不重视别人的任务，口碑是干出来的，你是不是个势力的人大家都不傻。当你对任何人都毕恭毕敬时，你的声望也在稳步提升。

关于沟通有个小Tip，在桌子上放一罐糖，没事儿给大伙儿发一发，没人会拒绝甜的东西~

创造价值

我们的目的是给公司尽可能创造价值。虽然屁股坐在写字楼里，但眼光要放到一线的产品使用中。去保证产品的正常运行，维护它的品质，响应客户需求，做一个推动公司产品顺利获利的问题终结者。

最后希望这篇文章可以对你起到一点点帮助作用，让你成为一个更好的开发。

欢迎各种形式的支持：“点赞”，“评论”，“收藏”，“转发”。