anonymous256

你这个问题，也是过去历代计算机科学家想要攻克的问题。你可以读一读 Dijkstra 1972 年的图灵演讲。
英文版： https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html
中译版： https://www.ituring.com.cn/article/71467

他提到了：
“论据三是建立在程序正确性问题的建设性方法上的。今天，一项普通的技术就是写一个程序，然后去测试。 尽管，程序测试是一种非常有效的方法去暴露 bugs ，但对证明不存在 bugs 几乎是完全没用的。显著提高程序可信度唯一有效的方法是给出一个令人信服的关于正确性的证据。但是我们不应该首先写出程序，然后去证明它的正确性，因为要求证明只会增加苦逼程序员的负担。相反，程序员应该让正确性证明和程序相互验证，发展。论据三本质上是从以下的观察得来的。如果一个人问自己一个令人信服的证据应该具备什么，他了解后，写了一个很好的满足了证明要求的程序，然后这些关于正确性的担心变成一种有效的启发式的指导。当我们把自己限制在智能可控程序时，按照定义，只有这种方法是可行，但这种方法也提供许多有效的方法，让我们从中挑选一个满意的。”

他的思想是测试驱动开发（ TDD ）：先写好验证的测试，把所有可能的情况考虑到，再写程序。你只需要说明你写用于测试的程序是有效的（基于合理正确的思维逻辑），只要能测试通过，那么你写的被测试的程序必然是正确的。

但这个毫无疑问会增加程序员的工作量和负担。对足够优秀的程序员来说，我觉得一定是不必要的负担。

我通常只对不稳定的函数和接口添加测试。有些函数的参数来源于不可控的外部数据源，比如要读取一个文本，读取到的数据各种可能性都有，这个时候就要添加测试程序，只是用来验证和保证被测试程序的正确性。

聊聊天啊，让他自立。
不愿意找工作，可能是找工作受了挫折，没有信心，多鼓励鼓励。
强硬点就扫地出门了，让他自己成长。

错误：“很可能也解决和发现什么问题”
修正：“很可能也发现和解决不了什么问题。”

一般说来，web 服务不涉及 CPU 密集型的任务。比较依赖 CPU 资源的主要在于解码或数学计算类的任务。所以即便你找到了好工具，很可能也解决和发现什么问题。

大多数程序性能的障碍在于：内存数据的写读依赖，不必要的计算和循环，算法的选择，不必要的 I/O 操作，多进程的数据竞争。你可以在程序内用通过日志输出高精度的时间，直接来捕捉到影响性能关键的代码区域，重新看代码逻辑分析具体是什么原因。

以「不必要的计算和循环」为例，我就遇到这样的代码，比如明明一个 for 循环就可以直接完成 AB 操作。但是有的程序员，会先写一个 for 循环执行 A 操作，再来一次 for 循环执行 B 操作。就导致了无谓的双倍内存访问。在比如明明一次 SQL 查询就能解决问题，他要查询两次，然后对数据进行关联和处理。就是不必要的操作和计算。

通常情况，性能的问题是人的问题。

国内就没有不卷的公司，只是程度的差异不同。
有些公司迭代的节奏相对慢一点。

@wenzhonghu 看起来是那样。
我的看法不同：匆忙是原罪。强调速度，必然牺牲的是质量。

https://norvig.com/21-days.html

以及，敏捷开发太累了，牺牲了开发人员的健康。我记得有几次我凌晨还在赶着给项目打补丁和改 bug ，就只是为了按时发布产品。快速迭代，是谁在快速呢？还不是人在快速。这样做下去，有多少年轻的程序员熬过 40 岁还能有工作热情？

透支未来的开发模式不可取。

现在的安卓早已不是性能问题了，而是缺乏统一的应用市场和严格的审核机制。
由此导致了良莠不齐的 APP——各种广告，索取权限和侵犯隐私，无底线的唤醒和消息通知。

@tktk #23 没有要求团队迎合自己，只是寻求价值观相同的团队。
@hz2019 #24 也许走的人多了，也就成了路吧。有很多那样优秀的小而美的产品，但是可惜没多少是我们中国人开发的。
@penguinWWY #25 继续读下去，很可能不是出路。我一个宿舍的舍友，有两个博士，有一个在计划读博；从我的观察，读博也不能做自己想做的学术自由和科研。而且，给导师打工与给老板打工，很可能都没什么两样。对于 research ，我认为每个有耐心、热衷理性思考、不断尝试的人都可以初步胜任。只是，只有少数人会取得成功。就像博士学历的人千千万，然而真正对人类知识有贡献的人只是极少数，大多数人终其一生仍然是劳无所获。