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，在桌子上放一罐糖，没事儿给大伙儿发一发，没人会拒绝甜的东西~
创造价值
我们的目的是给公司尽可能创造价值。虽然屁股坐在写字楼里，但眼光要放到一线的产品使用中。去保证产品的正常运行，维护它的品质，响应客户需求，做一个推动公司产品顺利获利的问题终结者。
最后希望这篇文章可以对你起到一点点帮助作用，让你成为一个更好的开发。
欢迎各种形式的支持：“点赞”，“评论”，“收藏”，“转发”。
网友评论