闲谈软件开发
前言
从计算机入门到入坑，一眨眼8年过去，这些年踩过很多坑，也有很多收获，简单记录下，希望大家能有所收获，水平有限，一家之言，估且听之。
计算机 科学（理论）与 技术（工程实践）
科班出身的人，出来工作会有一个简单的想法，自己跟培训学校速成班出来的人有什么区别？计算机专业的学习计算机组成原理，汇编语言，编译原理，数据结构，C语言程序设计，模拟电路，数字电路，离散数学，线性代数，计算机网络，数据库原理，培训学校会讲JAVA基础，jdbc,java web(servlet,jsp),spring struts hiberna mybatis,xml,json，项目实战，Linux基础操作，mysql基础操作。很明显学校与培训着重点完全不一样，自从windows普及，大家都习惯直接上代码copy-past这种快餐式的方式，能干活，至于什么原理，思维，哲学，who care.学校的教育只专注课程本身，实际技术课程是成体系，有一个思维认知过程，每门课太过独立，学生将书本知识转化成实际工作，或者是积累项目经验，实际上个人感觉大学学习的基础很有用也很有意思，扎实的计算机知识，增加项目经验是很容易的事情，有项目经验反向学习基础知识也需要花费很多时间。学习，还有知识的积累，从无捷径。
五花八门的协议
软件开发这一行，各种技术层出不穷，刚工作可能会感觉自己啥都不会，一会学这，一会学那，很容易陷入技术迷城中去，不知道学什么。简单介绍下自己思维变化，工作中一定有某些东西会给你很大的启发,茅塞顿开那种感觉。
有一年去跟移动联调短信接口,调用webservice接口，当时用axis1.4,移动那边的接口版本更旧，一开始各种不通，对方提供了正确的报文格式给我的参考，上网在宾馆中找各种webservice相关的资料，因为没有全局的认知，wsdl，operation,xml,xsd乱七八糟的，后面代码怎么搞都不对，搞了个端口转发工具tcpdump，看下程序执行的webservice请求到底出什么问题，看了sop协议组装内容，有一个简单地想法就是，实在搞不定，我就自己按报文格式拼个xml，http发送给对方，收到对方的报文，搞个filter自己解析xml。webservice就是http+xml,soap协议就是自己定义了特定格式，wsdl描述发布了那些服务，协议其实很简单，就是某些人为了达成特定的目标，设计了一大堆规范标准，后面的人都按照这个套路去玩。协议其实很简单，设计了一种协议，相应地也就会搞出一大堆名词概念，后面的人如果要用，就得去理解。再之后我再看到什么其他以协议，心理上也就没什么压力了,如redis协议，dubbo协议等。
不是所有的东西都很重要
有一年看了effiect java,里面有一段提到了java某些类写得不好，stack,vector在集合框架中都重写了，不推荐使用。原来大神写的java类库也有不好的，并不是所有的类，或者方法都很重要，后学java的人，其实可以忘记java中有stack,vector之类的类，个人爱好学习除外。学习我们应该抓住重点,折住主线。
提炼核心思想，化繁为简
有段时间看了代码重构，核心思路是写出易懂，可扩展，好维护地代码，至于具体地点，1,2,3,4条都忘得差不多了，学习完提炼转化为自己对知识的理解，这就是收获，具体的那几条不是收获，因为，每一条都是自己地适应场景，我们开发软件环境也在变化，这就需要我们自己去判断，这样写代码，是否符合你自己提炼出来的核心思路。
性能测试，知识点全面，榨干机器性能
规范一点的软件开发团队应该都做过性能测试，或者引进其他技术方案时可能也会自己压测，以前测试过来要设定一个压测目标，比如查询qps,tp99毫秒数。然后搭建测试环境压测，应用程序的压测结果可能惨不妨睹，自己还在想qps不能这么低吧。分享一下以前经历，从来没有对tomcat调优过，默认线程数大概是150左右，压测怎么弄都上不去，线程池满了，对tomcat不熟悉，不了解线程知识，找出问题得看运气.再有一次用jmeter压也是怎么都压不上去，最后发现jmeter用的是默认的jvm内存设置，太小，并发跑不起来.再有也碰到过操作系统参数设置不合理，服务器网卡带宽足够，交换机带宽不够等等各种问题。压测跟环境，跟压测目标有很大的关系，从程序员的角度来看，压测一个是找出程序中的薄弱环节，哪些地方可以优化，再一个就是可以对很多参数设定做对比测试，看下基于特定软硬件环境，什么样的参数组合下有最佳地性能表现，压测的目标就是榨干机器性能，最好是cpu利用率，内存利用率，尽量都上去, io尽量降低。
阅读源码，站在巨人的肩膀上
写代码跟其他工种实际上也是差不多的，先模仿，多写，多思考，重复这个过程。阅读源码可以快速吸取前人的经验，源码阅读是个细致的工夫，可以找个市面上比较流行的，大家都在用的开源项目，如dubbo，rocketmq等（京东内部使用对应的是jsf,jmq,原理都差不多，不影响对事务本质的理解），网上有些热心的程序员已经分享了源码分析的文章，边看文章，边看代码，边理解，慢慢地就有感觉了，遇到不会地可以适当地去学习下，如完全不懂netty是没法看懂远程通信这一块的实现细节的，当然也可以跳过去，你只需要知道这个接口是走网络通信用的就可以了，不影响其他部分的代码阅读.NB轰轰的项目，不一定代码写得好，也可能是架构比较合理，使用比较方便，看什么学习什么都要加入自己的理解才是正道。
动手写代码吧
学习源码后，提供架构设计应该是有帮助的，分布式软件需要考虑各种情况，失败设计可能比正常功能更重要，软件不稳定，甚至数据不正确，直接会否定软件价值。假设你看过各种源码，开口就是高可用，谈高性能就讲缓存，无锁化，消息通信等等，没真正去自己去写过服务注册，序列化，动态调度等，远程通信的代码，可以尝试自己动手试试，可能会有新的收获，纸上得来终觉浅，绝知此事要躬行。
持续学习
看源码或者是看书，看技术博客，总会发现新的点，保持强烈地学习兴趣，了解下总没坏处，深入研究需要慎重思考，毕竟精力是有限的.说个段子，去年你们骗我搞深度学习，刚才坑今年又骗我去学习区块链。投资与市场环境确实会影响技术发展，技术还是有一段时间的积累，再暴发，找到合适地生长土壤，没长成可能还需要技术沉淀。
从机器和数学的角度思考程序
有空也可以想想，如程序是什么，进程又是什么，线程，协程之类的，电脑是怎么跑起来的，C语言编译器可以用C语言编写,网络连接是什么，真实地物理世界连接是什么，从机器和数学的角度思考程序，而不是我们应用角度。
传统与互联网
总有面试的人说互联网与传统软件的区别，真正在区别是工作文化与工作环境，纯粹地从技术上讲，个人感觉是一样的，只是你的程序能满足业务需求，完成业务功能，能做到高可用，7×24小时不停服，并发能满足线上用户访问请求,有一定地余量，有一定的防护安全攻击能力，你就达到了互联网的技术要求。
总结
前路漫漫，道阻且长，学无止境.