在编码过程中,对需求的深刻理解

71 阅读3分钟

持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第22天,点击查看活动详情

背景

  1. 刚入行的时候,更多考虑的是:需求是否有难度,是否能够在规定的时间内完成,而在设计层面是缺乏思考的。在知识和经验不足的情况下,是不知道该怎么办的。也不知道一件事情的标准做法是什么。

  2. 做了三到四年的时候,发现原来的思路其实是错误的,需要转变过来。需要培养一个意识,那就是如何对需求进行设计上的考量

  3. 做到5年的时候,就会效率高,质量好。

过程

  • 写的不是代码,而是自己与别人沟通后的理解。如果能够很好的理解别人需求,那么代码写出来的质量就特别高。多问:需求的使用场景?需求的意义?

  • 需求不明确,整体脉络没有设计好,没有想明白,不要着急写代码,先问清楚,然后多花费时间做设计,即使是业务层面,也要尽可能做到更好。而且在写的过程中,也会凸显一些自己尚未考虑到的点,这也是非常正常的,不要有怀疑自己的心理,如果有,就一定要想办法去克服,练习,然后坚持。

  • 不要顾虑这个需求别人是否知道和理解,因为,需要总有人是理解的。因此:不用管别人是否知道,自己都应该积极主动去询问,总一个人会知道的。

  • 考虑需求的时候:不要立即去想和回忆项目中的实现细节,实现这样的需求需要花费多少时间和努力。更多是,去思考,这个需求点本身,应该怎么做更加标准和专业。做到不过重设计,也不能不进行设计。花费更多的时间去学习如何拿捏好这个点。 这样做的好处就是:培养自己去做tradeoff。

  • 比如上层协议,可以做的更加通用和标准化,在底层实现过程中,可以采用中间层进行协议转换,而这样的协议,可以小到是:上层是时间戳,底层是其他日期格式。也可以是其他协议。

  • 比如后台服务程序:永远考虑业务数据的合理性,不要考虑它应该在页面怎么去展示,不要有这样的顾虑。

  • 练习。没有练习,很难熟练。不熟练,是没有工作效率的。

  • 做任何一件事:无论外界条件是怎样的,自己应该按照自己的节奏去做事情,该做反思的一定要做反思,该做总结的一定要踏踏实实地做总结,这些步骤一步也不能少了。而且该问的都必须要去问。问并不是说自己弱于别人,并不是自己不懂,而是自己仅仅不知道而已,这些信息无关能力。

  • 更多去培养自己这样的意识。面对问题的态度,解决问题的思路,与人沟通的技巧。而不是掌握了多少技术,会使用多少中间件。

小结

  • 心得体会来源:自己主动跟架构组同事请教,在编码过程中的反思和琢磨,学到的一些意识,这些也是需要自己一生进行练习的,知道和潜移默化是有很深鸿沟的。

  • 练习。当惧怕一些东西的时候,就硬着头皮去练习,多练习几次,就熟练了,会发现,多简单的,把这样的感觉牢牢记住,当出现了恐惧的时候,就回忆一下上次是怎么克服的。

  • 沟通。是很有难度的,好在有这样的意识去改善了,慢慢来,未来还是可期的。