一些思考与随笔

2019-07

1. 当产品遇到问题、遇到BUG时，自己能独立地分析问题、解决问题、协调问题，及时地为用户提供技术支持，收到用户的感谢，感觉自己的价值得到了初步的体现。工作的内容非常充实，让我们更快地找到了工作的状态。从第三周开始我真正的参与到了项目的编码当中，重新见到我熟悉的Java语言，感觉工作内容和自己所学还算契合。同时也感到，在项目中应该统一每个人的编码规范，如果规范不统一、或者有人不遵守，就会加大人与人之间的沟通和协调的效率。
2. 代码质量中质大于量，在编写代码时必须严格遵循代码规范，编写出容易阅读、好维护的代码。设计比编码重要，一个不好的设计会导致在代码量不断扩充的过程中不断地拖编码的后腿，永远也无法挣脱。一个程序员的学习能力、信息搜集能力、信息甄别能力，对编码的热情和兴趣、逻辑思维能力及其表达是最重要的。当我们学习一件事情时，一定要有目标地去学，要知道自己学这个是为了什么东西，不能盲目的学。
3. 持续学习，敢于质疑、敢于提问，不断地在工作中提升自己，再用更优秀的自己去回馈工作！

2019-08

1. 想要在技术路线上成长，设计、原理、业务三方面缺一不可，没有好的设计，就不可能写出优秀的代码，不懂原理，就不可能写出高效的代码，不懂业务，就不可能写出实用的代码
2. 从业务的层面去看代码，很多逻辑就会变得简单很多，也更有利于在宏观层面去修改和优化代码、理解代码
3. 用好开发工具、调试功能也是开发过程中一门很重要的技能，它切切实实地影响着我们的开发效率，并能帮助我们检测我们写的代码中潜在的BUG
4. 批处理技术常用来创建索引、推荐系统、定时任务以及数据分析，而流处理技术常用于监控系统、生产者/消费者模式等；
5. “流”是指随着时间的推移而持续可用的数据，而流处理是一种无界的、持续增量处理的方式；
6. 在代码里想要捕获NoSuchMethodError或者OutOfMemoryError可以通过catch Throwable的方式来捕获处理
7. 当代码冗余消除后再去修改代码逻辑能减少BUG的产生，并提升代码优化的效果。当熟悉业务之后再去修改业务逻辑，能在一定程度上预防重大功能性漏洞的产生。
8. 用好开发工具、用好调试功能也是开发过程中一门很重要的技能，它切切实实地影响着我们的开发效率，和检测我们写的代码中潜在的BUG。所以我找代码优化点，和找BUG缘由的时候，刻意去充分的运用工具，熟悉工具，发现工具确实能减少很多人的重复工作，甚至能帮人发现一些肉眼难以发现的问题。
9. 即使非常细心，在修改代码的过程中仍旧产生了不少BUG，有的BUG虽然自己觉得很牵强，但不能不称之为BUG，越来越体会到，开发人员在开发过程中的修改记录的重要，每次修改可以看到当时修改的缘由，思路，这有助于后面的开发人员，甚至是他自己发现他自己以前挖的坑。更能帮助新员工熟悉产品演进的过程，如何从一个青涩的产品，演进到一个成熟、如城墙般坚固的、信息安全的产品。
10. 高内聚、低耦合、少造轮子，这样能大大降低代码维护的成本、减少代码量、提升代码质量。想达到这样的效果，最好的办法还是做好前期设计，而不是后期改进
11. 思维再严谨也终究会有出BUG的时候，在代码大面积重构的时候更是如此，不能过分信任自己的改动，必须在改动的同时不断进行单元测试和回归测试才能保证尽量少引入新的BUG
12. 一个成型的产品并不是看上去那么完美无瑕，仍然会有很多BUG和需要改进的地方

2019-09

1. 日志的合理性、有效性很重要，日志代码贯穿整套系统之中，需要统一的，完整的设计，才能起到合适的作用，才能在避免日志冗余的同时提供充分的、合适的信息
2. 应该针对日志的格式，打印的内容以及信息制定一套更具体的实施规范 – 方法论，仅仅用效果和目的来规范日志代码是不够的

2019-10

再严密的防火墙也防不住叛徒，SSRF（Server Side Request Forgery）漏洞就是叛徒，其危害有如下四种：

1. 加载外部的恶意木马文件或脚本文件并执行
2. 泄露内网中的敏感文件或程序自身的敏感文件
3. 来访问内网进行内网端口扫描、获取内网设备信息、枚举内网服务等
4. 作为信任域跳板、攻击运行在内网或本地的应用程序（比如溢出）

2019-11

 最近接触到很多新东西、新工具，但万变不离其宗；工具要熟悉其使用，但是不能只关注工具，更要思考工具背后的设计理念、工具给我们带来的价值以及不足，最佳实践如何做；还要思考，当我们在做一件事、在用一门技术时，本质上是在干什么？

 例如：当我们用消息队列时，本质上我们是在解决一个流处理任务，从流处理和批处理的基本理念去思考问题，将会更有助于我们理解何时、何处来使用消息队列，以及如何最佳实践；当我们设计数据库时，从数据结构化角度看，实际上是在把数据的结构化部分和非结构化部分分离开来，而结构化设计（给系统设计钉铆钉）往往能比非结构化设计带来更好的性能，这就需要我们精确分析每个业务场景，针对每个场景，最大限度地分离出数据的结构化部分，并作为设计铆钉；还有一个类似的理念是，尽量在需求细节提出前的架构设计阶段就从设计层面能考虑性能，这要远胜于后期的性能优化，一个经常性的规律是：“越灵活的设计往往带来越差的性能”；可以从这个角度去考虑：在性能要求极高并且满足业务需求场景的情况下，尽量为设计多钉铆钉，减少灵活性，这样能获得较大幅度上的性能提升；

 身份证号的分段设计就是一个很好的例子，身份证号里钉了很多“铆钉”，几位到几位代表地区编码、几位到几位代表生日，对于这些定死的东西，我们就可以称之为“铆钉”；“铆钉”并不是随意定的，它本身包含有自己的意义，它是作为一种数据而存在，和数据库里的数据一样，只是数据库里的数据是动态的，而“铆钉”通常是属于静态数据（通常以“协议”的方式来体现，这里的“协议”指的是数据系统的设计定义，例如，几位到几位代表生日，这个协定，是大家都公认的，大家都能理解、都能读懂，那么就可以称之为“协议”，这和我们通常所说的网络协议实际上是有异曲同工之妙的，再次引用上一段的观点，越灵活的协议往往带来越差的性能，例如HTTP协议，支持各种请求头、各种Content-Type类型，性能很差；而越严格、越简单、越定制化（设计）的协议则能带来更好的性能），这实际上也是一种数据动静分离思想的体现，通过将静态数据和动态数据分离开，最大限度利用静态数据的优势，能获得较大的性能提升；从动静数据的角度看，关系型数据库实际上也包含动态和静态两种数据，表结构数据是“相对静态”的数据，而表行数据则是“相对动态的数据”；还有一点，如果一门技术使用简单，那么它一定会屏蔽很多细节，同时也会带来较多限制，技术选型时需要考虑诸多方面；
在身份证号的例子中，我们去查询一个身份证号户籍所在地时，就不再需要联表查询，不需要JOIN，直接截取身份证号字符串，获取户籍编码（静态数据、利用铆钉），然后查询编码到户籍所在地的映射即可；相当于在设计层面将JOIN操作优化为了String的substring操作+HashMap的GET操作；大大提升了性能，特别是在大数据量场景；

 最后一句话，其实哲学、设计、技术、工具都是相通的，即使是在不同的领域，都有很多惊人相似的理念，只要你站的够高，眼光放得够远，你会发现相通的地方会越来越多；我们既要懂设计，又要懂原理、技术，还要能懂业务，针对业务去设计，针对原理去编码，并最终服务于业务；找到对的方向、方法、努力的目标去努力，学习之前一定要知道自己学习这个有什么用，解决什么问题！