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

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

 

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

回想当时，分享的内容可以概括为三个大点：

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

 

关于设计文档那些事：

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

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

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

4、在设计文档之前可以有个可行性探索。

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

6、设计文档最怕的就是设计遗漏了场景，及时地把发出来后，能够尽早发现问题，大家看了可以提出建议，比如自己设计漏了哪些场景。

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

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

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

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

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

12、写设计文档对于写作的功底还是有要求的，表达条理清晰，让自己和他人看得懂，也不要以为存在错别字并不重要，影响个人形象只是其一(假如某天你和Boss一起编写一个设计文档)。

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

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

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

 

经验分享&意见建议
1、经验从何而来，一切都顺利是否是好事呢？
并非好事，因为如果一切都很顺利，那么成长值将为0；如果你总是在做增删改查，发现自己总是在重复劳动，那么成长就是零；应该像海绵一样去吸收相关的附加点，且遇到的问题越多越好。

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

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

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

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

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

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

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

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