Large technology companies will share coffee - Postscript
This afternoon inside the company held a back-end technology developers will share a total of seven individuals, not more soldiers; three coffee Huawei Senior programmers to share with us those things, with my only memories now to write it down, hope after a career of help.
I recall, sharing content can be summarized in three major points:
1) regarding the design documents of those things;
2) large coffee than ten years of development experience to share;
3) to share with each other, put forward opinions and suggestions.
Those things about design documents:
1, do software development to accept the fact that software development is not a breaking discovery-error process, certainly not perfect, so the design documents to speed out, from coarse to fine, a common problem is that perfectionism (especially beginners ).
2, design documents to achieve a certain degree, in fact, it is routine, the main components as follows:
Architecture: data model, interface definition;
process: the normal flow, abnormal scene; design
cross-impact: the configuration interface, database, reliability, performance, etc. .
3, the design document is the most important scene (process): normal scene, abnormal scene.
4, before the design document can have a feasibility exploration.
5, the benefits of design documents:
. A forced thinking scene (CASE is the essence of the scene), well written documentation, coding chaos;
b can guide the design documentation throughout the development process, including coding, interface documentation and test cases, all occurrences. the problems can be traced back to the design document;
. c out of the design documentation, engineering can be encoded (that is, to achieve the details);
d remind myself repeatedly thinking, enhance understanding, seek better implementation.
6, design documents are most afraid of is the design scene missing, promptly after the issue, the problem can be found as soon as possible, we can read the recommendations, such as their own design which missed scene.
7, the document is designed to guide their next steps, including the full guidance coding, interface documentation and test cases, but not addressed to the leadership to see.
8, design documents written in detail, so that others can understand able to put forward their views to themselves, before they can make their own do better, there is a design flaw abnormal and even less.
9, remember to outline a list (including major functional point document design), architecture in-depth by the outline design document inside.
10, writing design documents do not use it? Documents can ensure you develop the point does not leak, clear, high-level people who write high level of design documents, is to write the highest standards, such as HTTP, RFC and so on.
11. Why study standards? For example, two docking system is a problem how to do, who to change, to change is based on what? By browsing the agreement, the agreement is found to be so defined, the definition of a field that can not pass through, then you have to pass the change.
12, writing design documents for writing skills are still required, clarity of expression, to help themselves and others can understand, and do not think there is a typo is not important, personal image is only one (if one day write with you and the Boss a design document).
13, in fact, is the design documentation corresponds to a decomposing step, hard things can be decomposed into a trivial thing to accomplish, corresponding to normal and abnormal scenes to design.
14, to have the opportunity to write design documents, boldly issued share their design documents, and then simple development also first after the completion of the design document encoding.
14, design documents to be accompanied by a prototype map (lo-fi interface diagram), means unimportant, nor does the drawing is the key, there are several ways:
A prototype design software.
Download: HTTPS: // the WWW. mockplus.cn/ , need to register with a personal mailbox free version;
b using an Excel spreadsheet draw a prototype map;.
. c handwriting draft drawing, cell phone camera to upload.
Experience Sharing & opinions and suggestions
1, come from experience, if everything goes well it is a good thing?
Not a good thing, because if everything is going well, then the value will be zero growth; if you are always doing CRUD, find yourself in duplication of effort, then growth is zero; should be like a sponge to absorb the additional points related problems encountered and the more the better.
2、知识技能体系，成长体系？
这些知识体系并不会因为你没有掌握和注意，该体系就不存在，体系实际是重要的成长目标牵引；比如MySQL这个体系，你也许会安装和简单的使用Mysql，但是比如Mysql优化和高级搜索里面的某些东西你不一定懂，而他确实是存在的，确实也是有开发人员掌握了的，此时自己要想办法覆盖这整个体系，完善自己的知识技能树。
3、问题处理是练兵的利器？
问题单处理流程实际上是处理问题的通用流程；问题单处理多了，你自然就会思考，这个问题为什么要这样子处理，为何是这个流程呢？然后，慢慢的这个东西就会融入了你的血液，成为你身体的一部分。
4、对于个人成长，当下最重要的是什么？
最重要的是结合当前自己的工作，填充自己欠缺的知识技能，出色的完成上级安排的任务；因为如果连上班8小时，本职的工作都做不好，还能在其他的领域有杰出突破贡献吗？工作的思考：不要重复工作，对于那些必不得已得重复的工作要搞出花来，比如很快地完成或是搞个工具自带完成等待；一些优秀的书籍会限制你认识事物的上限；刚刚毕业1~2年的小伙子，最重要的是自己要学会思考，多上上心；开发人员的基本功最为重要，同时要覆盖自己的知识技能体系，你的对手永远都只是你自己。
5、事务分解能力？
包括问题处理和需求开发，再难的任务都可以分解成一件件小事去完成。
6、作为后台开发人员，要怎么解决问题呢？
首先是问题描述，该问题一定是可以复现的，现象出来后你的定位思路是如何，然后你的定位过程是如何，最终你解决的问题一定是你定位出来的而且是能重现的问题。
开发人员面对问题时有两种态度：
1、遇到问题直接面对他，解决他；
2、遇到问题绕过去，绕过去就是上面所提到的顺不顺利的问题，如果绕过去了，就失去了一个成长的机会。
处理问题：
最重要的一点就是要先把问题复现，然后根据它的现象推测，有可能是哪些问题，再通过日志打印判断大概问题出在哪里，或是根据消息，查看消息里面携带的参数，看书在哪一步出的问题，正常的流程是怎样的，异常的又是怎样的，有可能是几种流程，大胆的猜测验证。
复现--->定界(前后端问题、哪个模块问题)--->推测--->打印、消息、日志、参数--->99%的问题都是可以通过Debug(本地Dubug和远程Debug)和日志解决。
杨总给我的建议是：性格调整下，多与人沟通交流。