解决问题的思路和设计代码的思路

解决问题的思路:
1.出现问题,除非是特别容易重现的,可以直接重现来解决,或者某个模块做过大的修改,之前的版本已经差别很大,有些问题不用再调查。否则每个能重现的问题都是巨大的福利,因为很多客户的问题都是没有重现环境的,所以要把握好能够重现的机会,不论多困难,找出背后的原因,而不是想着用新版本看能不能解决。因为这个问题在新的版本中可能被掩盖了,再找出这个问题就难了,就成了定时炸弹。你看,今天我们这个问题最后揪出多少严重问题,今天如果不在我的环境中重现,还不知道猴年马月能发现,那个时候花费的就不是一晚上。而且今天晚上发现了一连串的问题,这就是辛苦的收获。
2.而且发现一个线索必须要重视,比如onResize的问题,我说这个肯定是问题,贾贝说后面jschart会被覆盖,认为也许这个就不是错误,结果这个onResize中暴露了很多问题,尤其是删模型不删数据属性这种严重问题,所以千万不要放过一个线索。
3.还有就是用搜索代码的方法不能解决所有问题,比如今晚的,谁能想到是仪表盘上的别的模型的参数导致的问题,这样搜代码根本想不到这个问题。
4.你们没有做过支持真正产品的工程师,那时候就知道这些信息是多么宝贵,我现在后台的很多问题就是,有可能跑几个小时跑出一次错误,而且是内存错误,根本不知道怎么引起的,这种没有线索的问题排查起来就是殚精竭虑。
5.通过这种联合调试代码的方式配合,虽然花费了大量精力,异常辛苦,但是成果非常显著,这个即使我们坐在一个桌子旁边,也就是这个配合效率。所以希望形成一个解决问题的方法论,学到点思维方式,也是值得的。你会发现,正确的思维方式和解决问题的方式,是可以解决大部分问题,同样在设计新功能的时候一样可以用到。这就是珍贵的软能力。
6.今天用到的很多协调、配合方式、解决问题的方式(我对代码比较熟悉,董老师的环境中出现了bug, 我告诉他设置断点的位置,查看变量应该是什么值,断点场景中是什么值,以此来判断问题)也是在做项目管理中必备技能,否则很少几个人都协调不了,遇到问题也无法互相帮助,也无法统一代码质量和设计原则,更不要说几十个人,几百个人配合做一件事情了。

产品设计思路:
1.你要仔细思考我每次用的逻辑,第一如何保证行为是合理的,让使用者不会产生疑惑,不会被质疑的,同时还要在设计和实现上也是更容易的,更不需要增加各种不必要的分支的,更容易被抽象的
2.以后要有习惯把重要的数据结构通过注释的形式写在初始化函数或者对应的类前面。弱类型脚本语言最恐怖的就是数据结构的不稳定,查问题都不知道怎么查。
3.如果涉及到的点比较多.仔细思考想清楚,把每个点都记录到文档上,然后再把它们一点点放到一个设计的流程图里去,看这些点哪个被if覆盖,那个被elseif覆盖,哪个被else覆盖。用这样的方法,最后所有的需求都不会漏,同时设计还足够干净,不至于想到哪写到哪
记住,以后每次都得给我用这种设计方法:
1. 列出所有需要完成的行为;平时这些点一定不要漏,都是素材,一定记录下来,有可能现在没时间看。这些都是刚才第一步需要的素材。等到设计都做好了,它们都被考虑到了,它们就没用了。
2. 仔细思考有没有哪种行为没有被覆盖,保证需求足够完整。这是产品需求的穷举;
3. 仔细思考这些行为的分类,站在用户角度思考,是不是用户看到的类似的行为都得到同一类结果。这是产品需求的抽象总结;
4. 开始设计具体的实现逻辑,看上述的需求如果被设计全部覆盖,而且代码量最小,于是抽象的最好,封装的最好;
5.思考这个设计跟之前的哪个设计相关,是不是应该合并,还是扩展。
6. 思考这个设计本身有没有扩展性,会不会未来有新的变化可以轻松应对。

你把这个原则记到重要的地方,每次都这么去贯彻,再结合不停的模仿,设计能力和分析能力一定会提高,动手能力也一定能提高。

包括上次的两套模型参数的维护,使用,修改,合并也一样的设计思路。

不能每次都让我给掰开了揉碎了这么解释,会耽误我很大的精力,我的精力分散越多,这样项目的进度会受影响更大。当然,这个也不是一次两次就能完全融会贯通,只要有这个理念和意识,然后一点点强化,总能解决。

然后就是平时这些点一定不要漏,都是素材,一定记录下来,有可能现在没时间看。这些都是刚才第一步需要的素材。等到设计都做好了,它们都被考虑到了,它们就没用了。

这就是书越读越厚的过程,后面几步就是书越读越薄的过程。

关键是需求怎么来的
我们在考虑的时候,就是需求不全,考虑容易出现偏差
这个其实是需求的取舍问题
大产品经理->产品经理->研发人员的推演和延伸、扩展,现在我就是大产品经理和产品经理,你们在做的过程中也反向向产品经理的角色渗透一部分,小公司都不会分的那么清晰。所以多思考,多沟通。拿不定主意,不知道把控风险的,我会把控,因为我要让产品适应市场,让产品生存,让产品盈利。
平时大家可以多关注别的产品,多关注别的产品的功能逻辑,以及一些优秀的产品经理的思考问题的方式,以及优秀的产品的设计。但是,我更建议大家多关注一些具体的技术实现,它跟产品管理完全不是一套路,也不是一个方向。当然,落地最重要,具体的经验最重要,空有理论是最没有价值的。从实践中总结出自己的经验,再去看优秀的产品和技术经验,再去碰撞是最有效的路。否则容易要么闭门造车,要么空中楼阁。