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