本文主要是介绍为什么我很用力，可还是学不好，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
图自网络
1、为什么我很用力，可还是学不好
我上中学的时候经常被班上的女生“围攻”，原因是她们说我都没有努力过，凭什么学习成绩那么好。
这些女同学的每本书都记满了笔记，还用各种颜色的荧光笔画满了重点，可是她们的成绩并不突出。
为什么靠记笔记和画线不能取得好成绩？
那些方法并没有给大脑带来挑战，没法起到巩固的作用，只会让人误以为自己已经掌握了。
用今天流行的话讲就是：你只是假装很努力！
人们都不喜欢挑战自己，也不喜欢挫败感。相比较而言，一遍一遍地画线要轻松得多。
可惜，轻松的学习是无效的。
以上是《认知天性》这本书的开篇，樊登为之写的一篇序言。
当我读到这几句话的时候，就想起来我曾经上学的年代，我也是有记录笔记的习惯，恰好上大学的时候，就有个很能记笔记的女同学。巧的是我们的成绩都不是那么突出。
现在，我开会的时候比较多，有时候一开两个多少小时的会常常有。比如，在正常的周会、月会上，拿出boox，我现在的习惯是还是会记录，但是，我记录的是，我听到之后思考和联想到的事情。
让大脑用力。
基本上这样的会议我能吸收到很多跟自己工作职责相关的内容，也便于了更好的展开后续的进展。
学习是挑战天性的必修课。
想省劲，就留不下脚印。
2、程序员的测试和测试人员的测试有什么不同
最近，我在极客时间上看郑晔老师的两篇专栏《代码之丑》和《程序员的测试课》。
这周的一天，在我读完上面两个专栏的相关内容后，我在【架构基础知识学习群】里抛了下面这个问题。
伙伴们的发言如下。
红线标注的同学的发言的观点跟《程序员的测试课》这篇专栏中的观点基本吻合。
程序员的出发点是实现，而测试人员的出发点是业务。
只要二者的出发点不同，对于同样的事物，总会看到不同的东西。不然的话，人类社会哪有那么多的争论。
那程序员也从业务的角度去思考，程序员的测试能替代测试人员的测试吗？
不能，因为人的注意力是有限的。
在发现问题上的训练强度是远远不够的。所以，人们常说，别用你的业余爱好去挑战别人吃饭的本事。
程序员和测试人员的出发点不同，一个从实现出发，一个从业务出发。
3、单元测试的威力
（1）它是最容易保证代码覆盖率达到100%的测试。
（2）可以⼤幅降低上线时的紧张指数。
（3）单元测试能更快地发现问题（见下图左）。
（4）单元测试的性价比最高，因为错误发现的越晚，修复它的成本就越高，而且难度呈指数式
（5）增长，所以我们要尽早地进行测试（见下图右）。
（6）编码人员，一般也是单元测试的主要执行者，是唯一能够做到生产出无缺陷程序的人，其他任何人都无法做到这一点。
（7）有助于源码的优化，使之更加规范，快速反馈，可以放心进行重构。
4、为什么系统压测既要单压又要混压
现在的很多公司里面的系统的服务都是微服务部署环境，每个服务都对应着一个自己的数据库。
现在的数据库都是容器环境部署，至少我们公司3年前都是了。
三个服务对应三个数据库服务。
每次压测一个服务，每个服务和数据库服务都没有问题，压测报告上写着性能达标，通过。
但是。
这三个数据库会很有可能在一个物理机器上。
图自吴俊龙
不可以只见树木，不见森林。
如果你同时压测这三个服务呢，结果再看看。
可能，那台物理机器的数据库服务器，就会有性能问题，比如cpu，比如io等。
5、如何能评估出我需要多少机器
那要先看三个跟用户请求相关的概念。
什么是QPS
QPS：Queries Per Second（查询量/秒），是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
它是衡量系统吞吐量的一个常用指标，也就是服务器在一秒的时间内处理了多少个请求。QPS的值越大表示服务器的吞吐量越大，同时服务器的负荷往往也会越高。
什么是TPS
TPS：Transactions Per Second（每秒事务处理数），是一台服务器在每秒内处理的事务的个数。这个完整的事务包括用户请求服务器、服务器内部处理、服务器返回信息给用户三个过程。它一般用于评估数据库、交易系统的基准性能。
TPS与QPS之间的对比
（1）TPS每秒处理事务数量。
l 用户请求服务器；
l 服务器内部处理；
l 服务器返回信息给用户。
（2）QPS基本类似于TPS，但不同的是，举个例子，访问一个订单详情页面产生一次TPS，但可能产生多次对服务器的请求，比如查询用户信息、查询商品信息、查询订单信息。服务器的这些请求可以计入QPS，也就是产生3次QPS。
什么是RT
RT：Response Time（响应时间），从客户端发送一个请求开始计时，到客户端收到从服务器端返回的响应结果结束所经历的时间。响应时间由请求发送时间、网络传输时间和服务器处理时间三部分组成。我们在使用的时候一般用平均响应时间。
什么是并发数
指系统能够同时处理的查询请求数量或事务数量。当并发数为查询请求数量的时候，QPS = 并发数/平均响应时间；当并发数为事务处理数的时候，TPS = 并发数/平均响应时间。
QPS、响应时间、并发数三者之间的关系如下图所示。
从图中可以看出，随着并发数的增加，CPU使用率会上升，同时QPS也会增加，平均响应时间也会增加。当并发数增加到一定数量的时候，线程切换会带来很大开销，这个时候处理请求的时间片减少，每秒能够处理的请求数量也开始下降，用户请求等待的时间肯定也变长了。
理解了以上三个参数对我们有什么帮助呢？大多数事物都遵循二八法则，系统流量也不例外，20%的时间承载了80%的流量。我们可以利用这一点来评估系统扩容的时候需要增加多少台机器。线上系统每天80%的访问集中在20%的时间里，这20%时间叫作峰值时间。
公式如下：
（总PV数×80% ） / （每天秒数×20%）= 峰值时间内每秒请求数（QPS）
峰值时间内每秒请求数（QPS）/ 单台机器的QPS = 需要的机器
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
与爱学习、爱思考、爱记录的你共勉。
参考资料：
1.Spock美团实践总结：https://tech.meituan.com/2021/08/06/spock-practice-in-meituan.html 文中第3小节参考此文
2.郑晔.极客专栏.《程序员的测试课》，文中第2小节参考此文
3.《架构修炼之道》,文中第5小节参考本书
这篇关于为什么我很用力，可还是学不好的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
