公司技术大咖分享会--后记

公司技术大咖分享会--后记

 

今天下午公司内部召开了个后台开发人员技术分享会，总共7我的，兵不在多；三个华为资深大咖给咱们分享了程序员那些事，凭我仅有的记忆如今把它记下，但愿对以后的职业生涯有所帮助。

回想当时，分享的内容能够归纳为三个大点：

1）关于设计文档那些事；
2）大咖十几年开发经验分享；
3）你们相互交流，提出意见和建议等。

 

关于设计文档那些事：

一、作软件开发要接受一个现实，那就是软件开发就是不个断发现错误的过程，必定不是完美的，因此设计文档要速出，由粗到细，常见的问题就是完美主义(尤为是新手)。

二、设计文档作到必定程度，它实际上是有套路的，主要组成以下：
架构：数据模型、接口定义；
流程：正常流程、异常场景；设计
交叉影响：配置接口、数据库、可靠性、性能等。

三、设计文档中最重要的就是场景(处理过程)：正常场景、异常场景。

四、在设计文档以前能够有个可行性探索。

五、设计文档的好处：
a. 逼迫思考场景(CASE的实质就是场景)，文档写得好，编码不乱；
b. 设计文档可以指导整个开发流程，包括编码、接口文档和测试用例，全部出现的问题均可以追溯到设计文档中；
c. 出了设计文档，能够工程方式编码(实现就是细节问题)；
d. 提醒本身反复思考，提高理解，寻求更好的实现方式。

六、设计文档最怕的就是设计遗漏了场景，及时地把发出来后，可以尽早发现问题，你们看了能够提出建议，好比本身设计漏了哪些场景。

七、设计文档是用于指导本身下一步的工做，包括编码、接口文档和测试用例的全程指导，而不是写给领导看的。

八、设计文档写得详细了，让别人可以看得懂，才能给本身提意见，才可使得本身作的事更好，设计存在的异常和漏洞就更少。

九、记得在设计文档里面列出一个提纲(包括文档中设计的各大功能点)，由提纲深刻架构。

十、写设计文档没有用吗？文档能够保证你开发点不漏，思路清晰，水平高的人，写设计文档水平也高，最高的就是去写标准，如HTTP、RFC等。

十一、为何要研究标准呢？好比两个系统对接出了问题怎么办，谁改，改的依据是啥？经过浏览协议，发现协议上是这么定义的，某个字段定义了不能透传，传了那你就要改。

十二、写设计文档对于写做的功底仍是有要求的，表达条理清晰，让本身和他人看得懂，也不要觉得存在错别字并不重要，影响我的形象只是其一(假如某天你和Boss一块儿编写一个设计文档)。

1三、实际上设计文档对应着就是一个分解的步骤，再难的事情，均可以分解成一件件小事去完成，对应着正常和异常的场景去设计。

1四、要有机会去写设计文档，大胆地发出分享本身的设计文档，同时再简单的开发也要先完成设计文档后编码。

1五、设计文档中要配上原型图(低保真界面图)，手段不重要，不会画图也不是关键，有如下几个方式：
a. 使用原型设计软件
下载地址：https://www.mockplus.cn/，须要用邮箱注册我的免费版；
b. 使用Excel表格画原型图；
c. 手笔草稿画图，手机拍照上传。

 

经验分享&意见建议
一、经验从何而来，一切都顺利是不是好事呢？
并不是好事，由于若是一切都很顺利，那么成长值将为0；若是你老是在作增删改查，发现本身老是在重复劳动，那么成长就是零；应该像海绵同样去吸取相关的附加点，且遇到的问题越多越好。

二、知识技能体系，成长体系？
这些知识体系并不会由于你没有掌握和注意，该体系就不存在，体系实际是重要的成长目标牵引；好比MySQL这个体系，你也许会安装和简单的使用Mysql，可是好比Mysql优化和高级搜索里面的某些东西你不必定懂，而他确实是存在的，确实也是有开发人员掌握了的，此时本身要想办法覆盖这整个体系，完善本身的知识技能树。

三、问题处理是练兵的利器？
问题单处理流程其实是处理问题的通用流程；问题单处理多了，你天然就会思考，这个问题为何要这样子处理，为什么是这个流程呢？而后，慢慢的这个东西就会融入了你的血液，成为你身体的一部分。

四、对于我的成长，当下最重要的是什么？
最重要的是结合当前本身的工做，填充本身欠缺的知识技能，出色的完成上级安排的任务；由于若是连上班8小时，本职的工做都作很差，还能在其余的领域有杰出突破贡献吗？工做的思考：不要重复工做，对于那些必不得已得重复的工做要搞出花来，好比很快地完成或是搞个工具自带完成等待；一些优秀的书籍会限制你认识事物的上限；刚刚毕业1~2年的小伙子，最重要的是本身要学会思考，多上上心；开发人员的基本功最为重要，同时要覆盖本身的知识技能体系，你的对手永远都只是你本身。

五、事务分解能力？
包括问题处理和需求开发，再难的任务均可以分解成一件件小事去完成。

六、做为后台开发人员，要怎么解决问题呢？
首先是问题描述，该问题必定是能够复现的，现象出来后你的定位思路是如何，而后你的定位过程是如何，最终你解决的问题必定是你定位出来的并且是能重现的问题。

开发人员面对问题时有两种态度：
一、遇到问题直接面对他，解决他；
二、遇到问题绕过去，绕过去就是上面所提到的顺不顺利的问题，若是绕过去了，就失去了一个成长的机会。

处理问题：
最重要的一点就是要先把问题复现，而后根据它的现象推测，有多是哪些问题，再经过日志打印判断大概问题出在哪里，或是根据消息，查看消息里面携带的参数，看书在哪一步出的问题，正常的流程是怎样的，异常的又是怎样的，有多是几种流程，大胆的猜想验证。

复现--->定界(先后端问题、哪一个模块问题)--->推测--->打印、消息、日志、参数--->99%的问题都是能够经过Debug(本地Dubug和远程Debug)和日志解决。
杨总给个人建议是：性格调整下，多与人沟通交流。