最近做一个需求，年前已经讨论过需求了，到了年后便紧锣密鼓的开始按计划进行编码。年前把需求文档看了好几遍，反反复复的看，到了年后确实有点效果，对于基本的流程已经大致掌握，但是因为只想着写代码的事，忘记做很多必要的事情，所以我在这做个简短的复盘。
做一个需求，不仅仅是代码。记得以前写过一篇文档，文中说了需要有产品思维去实现一个功能，不单单从代码实现的角度去考虑问题，还得想着功能性的问题。这个是我刚到杭州参加工作的时候，组里的老大在晨会上说的，因为那时候需求很急，但是很多还只想着实现功能代码，并没有去想其他扩展性的东西，所以他就顺势指导了我们一番，也让刚入职场的我铭记在心。
做一个需求，不仅仅是代码。首先，需要从功能扩展考虑问题。想必大家都会下棋，高手为什么会老是赢了你呢，你想过没有。为什么前几年阿尔法狗在下围棋的时候，能打败李世石，柯洁，因为阿尔法狗的程序里汇聚了N多种棋谱，他在和人类下棋的时候已经想到了后面的好多步骤，所以在对阵的时候能够根据场上形势做最好的判断。李世石他们为什么经常拿冠军，很大一部分也是因为人家能想到更多的步骤吧。围棋你不会，象棋总会吧，根据各个角色的走法，胜者肯定能做出更好的规划。小编以前在和电脑对阵的时候，经常输，输了就把当时的棋反悔重新来，结果就可想而知了。所以，写产品，写程序就是类似的，程序员需要考虑的不仅仅是实现好功能，还得想到针对此需求，后面还会不会有类似的功能出来，如果现在你想到了，后面真的来了类似的需求，你是不是就觉得很轻松了呢。
做一个需求，不仅仅是代码。需要做好必要的设计，必要的架构。刚写Android代码的时候，那是12年左右，都说Android是MVC架构，然后初出茅庐的我在Activity上堆积代码，刚入行的时候，曾经看到过一个Activity有5千行代码，恐怖吧。所以，那时候经常在网上看到调侃程序员的话，说多久之后回过头来看自己写的代码，感觉很乱，甚至还有注释说上帝才能看懂。那是因为，起先写代码的时候，没有做更好的设计，写了代码，然后就扔一边去了。我以前有口头禅“这个优化，到时候我有时间会优化的”，这个有时间，直到我离开项目组都不会有时间，悲哀吧，但这就是现实。后来Android有了MVP，MVVM等，看了Demo，确实比在Activity上堆积代码好了些，但是后面不注意的话，还会不经意间堆代码实现，牛逼的架构需要清晰的思路才可以。所以，写Android的你，现在如何了呢？
做一个需求，不仅仅是代码。需要做好设计模式相关，还有必要的数据结构。这个是我最近的感受，其实我想表达的主要是代码如何更好的使用设计模式，如何在和同事对接接口的时候更好的设计好数据结构。设计模式的计划已经提上日程了，很快将会跟着书本学习一番，总结一番。现在很多同学应该苦恼的是，学设计模式的时候感觉思路清晰，但一到了真实项目，总是使用不好，这个困惑我也有，我现在用的也不多，观察者模式，单例模式，适配器模式。之前去面试一家公司，因为设计模式的问题卡壳了，后来就没有那份offer，现在想想真是可惜。还有数据结构的问题，对接接口是一个耗时耗力的问题，对的好，同事之间的关系都会更融洽；对接的不好，互相都会感觉很累，所以，你是不是有同感呢。接口的数据结构，会跟着需求的发展不断的更新，这时候你要做的就是兼容新老版本，所以如果你在前期设计的好，后面功能扩展就会好很多。我现在就处在这个阶段，感觉做的不咋地，让前端的朋友受苦了。其实自己写了那么多年Andorid，对接接口没少吃过亏，能有所长进就有所长进，对后来的你肯定非常有帮助。
做一个需求，不仅仅是代码。写着写着，想起来，应该画图。在前东家接受过一套完整的需求分析到产品实现的流程，一位台湾的大牛过来讲课的。在整个PI开发期间，需求分析大会是首要，然后后面还有开发和测试的串讲和反串讲（期间需要各自画流程图，这个图叫什么名字忘记了，我回头找找笔记再进行补充），然后工作量评估（我的评估能力就从那时候开始培养的），再就是进行程序开发，等后面一系列正常流程。这样做出来的产品，不敢说如何如何好，但是肯定也不会差到哪去，这个是经过很多公司项目的实践经验得来的。可能复盘的不大对，大致流程是这样的。
所以，简单的做了一个复盘，来对年后高强度工作一个小总结，工作量评估在4周，目前进度来说还在我的掌握之中，期间穿插过几个需求，但还是挺过来了，很是开心，没有比较拖后腿。希望这篇发出去了，然后就来大脸，拖了别人的后腿，我先敷个面膜保护下我的脸，不然会很疼的。
如果你认同我的观点，点个好看，动动你的小手帮忙转发下，让大家一同在写程序的路上越走越远。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
