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

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

 

今天下午公司内部召开了个后台开发人员技术分享会,总共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)和日志解决。
杨总给我的建议是:性格调整下,多与人沟通交流。

 

 

 

你可能感兴趣的:(公司技术大咖分享会--后记)