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

ゝ一纸荒年。 2022-12-02 04:07 157阅读 0赞

#### 背景 ####

1.  **刚入行的时候**，更多考虑的是：需求是否有难度，是否能够在规定的时间内完成，而在设计层面是缺乏思考的。在知识和经验不足的情况下，是不知道该怎么办的。也不知道一件事情的标准做法是什么。
2.  **做了三到四年的时候**，发现原来的思路其实是错误的，需要转变过来。需要培养一个意识，那就是**如何对需求进行设计上的考量**。
3.  **做到5年的时候**，就会效率高，质量好。

#### 过程 ####

*  **写的不是代码，而是自己与别人沟通后的理解**。如果能够很好的理解别人需求，那么代码写出来的质量就特别高。多问：需求的使用场景？需求的意义？
 *  **需求不明确，整体脉络没有设计好，没有想明白，不要着急写代码**，先问清楚，然后多花费时间做设计，即使是业务层面，也要尽可能做到更好。而且在写的过程中，也会凸显一些自己尚未考虑到的点，这也是非常正常的，不要有怀疑自己的心理，如果有，就一定要想办法去克服，练习，然后坚持。
 *  **不要顾虑这个需求别人是否知道和理解，因为，需要总有人是理解的**。因此：不用管别人是否知道，自己都应该积极主动去询问，总一个人会知道的。
 *  考虑需求的时候：不要立即去想和回忆项目中的实现细节，实现这样的需求需要花费多少时间和努力。更多是，去思考，这个需求点本身，应该怎么做更加标准和专业。**做到不过重设计，也不能不进行设计。花费更多的时间去学习如何拿捏好这个点。** 这样做的好处就是：培养自己去做tradeoff。
 *  比如上层协议，可以做的更加通用和标准化，在底层实现过程中，可以采用中间层进行协议转换，而这样的协议，可以小到是：上层是时间戳，底层是其他日期格式。也可以是其他协议。
 *  比如后台服务程序：永远考虑业务数据的合理性，不要考虑它应该在页面怎么去展示，不要有这样的顾虑。
 *  **练习**。没有练习，很难熟练。不熟练，是没有工作效率的。
 *  做任何一件事：无论外界条件是怎样的，**自己应该按照自己的节奏去做事情**，该做反思的一定要做反思，该做总结的一定要踏踏实实地做总结，这些步骤一步也不能少了。而且该问的都必须要去问。问并不是说自己弱于别人，并不是自己不懂，而是自己仅仅不知道而已，这些信息无关能力。
 *  **更多去培养自己这样的意识**。面对问题的态度，解决问题的思路，与人沟通的技巧。而不是掌握了多少技术，会使用多少中间件。

#### 小结 ####

*  心得体会来源：**自己主动跟架构组同事请教，在编码过程中的反思和琢磨，学到的一些意识**，这些也是需要自己一生进行练习的，知道和潜移默化是有很深鸿沟的。
 *  **练习**。当惧怕一些东西的时候，就硬着头皮去练习，多练习几次，就熟练了，会发现，多简单的，把这样的感觉牢牢记住，当出现了恐惧的时候，就回忆一下上次是怎么克服的。
 *  **沟通**。是很有难度的，好在有这样的意识去改善了，慢慢来，未来还是可期的。