这是一个创建于 1634 天前的主题，其中的信息可能已经有所发展或是发生改变。
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，在桌子上放一罐糖，没事儿给大伙儿发一发，没人会拒绝甜的东西~
创造价值
我们的目的是给公司尽可能创造价值。虽然屁股坐在写字楼里，但眼光要放到一线的产品使用中。去保证产品的正常运行，维护它的品质，响应客户需求，做一个推动公司产品顺利获利的问题终结者。
最后希望这篇文章可以对你起到一点点帮助作用，让你成为一个更好的开发。
欢迎各种形式的支持：“点赞”，“评论”，“收藏”，“转发”。
 |
1
jmyz0455 2020-06-14 16:56:36 +08:00
很长，看完了，讲得很细，挺好的。
上头总是喜欢要我给出开发的所需时间，而且必须要承诺。我预估这块总是做不好，只能加班，报多了上头也不喜欢，后来发现其实上头自己也不能准确地预估工时，所以才要细化每一个人的时间然后“盯”着。这点有什么建议吗？ |
 |
2
rabbitinhere OP |
 |
3
ugentlenicho 2020-06-14 19:06:22 +08:00
说的不错
|
Select Language