本文主要是介绍Jeddict研究过程中的总结，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一、与作者交流的总结
说来也是惭愧，没有太多的经验，先给大家贴两张图，看看大家能不能发现问题：
在最开始的时候，都处于Gaurav Gupta让我给材料的过程，因为我不是缺这个就是缺那个，根本说不清楚问题。然后交流的效率不是很高。我们能通一次邮件解决一次问题，是从我开始这样回邮件开始：
首先我是在邮件正文中加以问题描述，然后在附件中附录了以下信息：
当我有意识到我并没有提供专业和必须的信息时，我尽可能的让Gaurav Gupta能够了解到发生了什么。简单点来说，就是根据我的描述和文件，我确保能够恢复我当时所遇到的问题场景。也因此，我们后来的交流异常的畅快。
思考：我为什么最开始没有做到？？？ 后来，我是怎么做到的？？？在我以后，如何向别人专业的描述一个问题场景？？？在请求别人帮助时，哪些材料是必须要提供的？？？ PS：比如说，SDE信息，这里面，你觉得应该包含什么内容？？？
二、与小组开发人员的交流
当时在组内遇到了一个关于自动生成代码的权限问题，我一直都跟大boss有不同的意见，但是，我一直没有说。然后，给安排的活儿，也没心去做。搞得这个问题一直存在，并且在jeddict这块还是个比较严重的问题。 后来，我想了好久，也是因为大boss有天下午过来跟我说了一下他对目前开发的想法，然后，晚上11点多了，还是决定跟他说说我的想法。
然而：为什么会发生这样的状况？？？事实证明，我的那个想法，才是对的，我为什么就是不说，然后耽误开发进度，也让问题一直存在？？？
我后来思考了，有以下的因素，导致了我最开始的不说，和我后来的说：
1，我不自信，因为大家都对大boss很信服，基本上就是让我们做什么，就做什么的那种。我理论上认为自己对，但又潜意识的觉得大boss不会错。
2，问题在那儿就在那儿呗，反正又不是我一个人的问题，大家这不都暂时解决不了嘛，我先忙完我手里的活儿，让大家折腾惦记去吧。（虽然有点无耻，但我深刻的反思了一下，确实有这个因素）
3，感觉这不是我该想的事儿，包括联系国外的作者，交流等等一系列的事儿，感觉都应该是大boss去做。还有一个就是，担心被无情的否决了，显得自己无极限low！
4，因为是属于新的架构技术研究，时间上没有对我很苛刻，我过得很舒服。
以上，都是我之前选择不说，沉默，甚至附和的原因。
5，既然我已经在这个小组里了，那么每出现的一个问题，我都有责任要去解决它
6，与其自己在这儿坚持自我，大家在那儿坚持大我，那还不如去说服或者被说服，至少心里没有“二心”，整个小组能够更加拧成一股绳的在做事儿
7，我认为，我真的没有理解错！
思考：以后，在发生我不认可别人的时候，我要怎么办？？？如果那个人是我一个很有权威的上司，我又该怎么办？？？ 我想，交流还是必须的，但我可能需要想想办法提升和改善我的交流表达，更专业，更为让双方都接受！
三、思维方式的转变
也是在研究这个Jeddict的过程中，小组里一直有权限访问的问题，然后一直顺着自己当前所遇到的问题，和自己提出的需求去跟作者提问。但是，我后来一想，好像是我们的需求有问题，而不是人家的产品有问题。在这个过程中，我主要思考了两点：
1，做产品的时候，首先要思考的是，这个产品应该是什么样子，而不是我们能做成什么样子。 我们之所以提出那样的提问，就是因为我们一直陷入了自己当前所遇到的问题，而忽略了它正常的生产逻辑是什么。以至于，我们提出的要求，已经不合理了！
2，Jeddict的作者，至少是我现在还无法去比的。他所在的那个层面的技术人员，毕竟目前是比我们小组强，所以，我们能考虑到的问题，他们很有可能比我们想得更周全更多。为什么，我不先承认是我错了，而不是对方的疏忽和遗漏？？？
承认是自己错了，然后再结合到第一点去思考，最后，问题就被解决了！ PS：通过和作者的进一步沟通，以及查阅权威说明（我的意思是，我再去看了相关技术栈定义说明，和一些文档），事实证明，确实是自己错了！
四、个人总结
Jeddict这个工具，包括和作者进行沟通，一直我都在做这个事儿，我自己的收获很多，但我怎么样，才能让其他的人，也收获到我的东西？？？
在这个过程中，发现自己也是一个比较执着的人，这些天，真的也是反常了。天天做测试，天天 根据作者的指引和解疑写代码。最终，还算是不负大boss所托，小组成员也都各有收获，挺好的！
这篇关于Jeddict研究过程中的总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
