@ylzh156 #32 哇，兄弟，你这是最直接回答了我的问题的，虽然上面也有朋友大致表达了这个意思，我大概也猜到了，但你这个说法是最清晰的，太感谢了

@murmur #4 @byaiu #9 @kop1989 #12 @melkor #16 @yangyaofei #17 @scarleast #20

非常感谢几位的详细解答，我之后有空再消化一下。有意的话可以加我微信，发红包以表谢意。c3RlZnVfbmM=

@murmur #4
可是如果没有体现出来的话，它为何能算作大调式呢……
这就是让我很费解的一点，很多教学都非常统一地介绍了“全全半…”，如果是这个模式就算大调式。但回头举例的旋律却完全看不出来与大调式的关联。如果平时并非靠这个音程模式来判断调式的话，那么这个调式的定义有什么作用？

@murmur #1 谢谢，这些类似的判断方法我也有看到过。但是我目前最疑惑的点是，“全全半全全全半”在这首曲子里到底体现在哪里了，我完全看不出来……

我们用的是升降桌，平时基本都是站坐交替

如果因为没胃口才这么做，我觉得应该先考虑解决下没胃口的问题……如果是比较健康的状态应该不会经常没胃口……

就通过传值设置进去的啊，你的疑问点是在于闭包？

证明不了，在现代科技找到手段对自我意识进行观测之前，这个问题没有什么讨论的意义。

竞争激烈了，干啥都难

项目信息需要提炼重点，然后排下版，这样一大段话我是看不进去

差远了，光是一个主动推送消息就一堆限制

我以前就觉得对选手测谎应该挺有用的，但不清楚目前的测谎是基于什么工作原理，是否适用于这种场景。

@Mindjet #5
短函数这个实践，我觉得有个两个前提是，要保证命名的可读性（或者要有足够的文档和注释），还有低耦合，否则反而可能会比较坑。
最近维护前同事的旧代码，他就很喜欢封装大量的函数，实现功能的时候一层一层构造一条很长的调用链。总的来讲，代码重复率确实很低，但那个代码真的维护得想死，他的很多命名根本说不清楚这个函数干了什么（因为是自己实现的，所以他可能觉得命名已经说得够清楚了），为了搞明白这一点，不得不进去函数读具体实现，进去又是一堆不明不白的函数调用。这样导致在阅读的时候，到处跳转，逻辑割裂严重，为了搞明白一个业务，甚至不得不深入到非常低层级的代码中去。如果是这种，我宁愿他写一些长点的函数，好歹有一个连贯可读的逻辑。
当然这个问题本质上不是短函数造成的，只是说在这个情境下，受代码上其他问题的拖累，反而降低了可读性和可维护性。

面试，或者找别人的面经

用 Kindle 好一些，青春版就几百，墨水屏漫反射比手机光源直射对眼睛带来的伤害要低。
但最首要的还是，不要长时间看。

个人介绍多余了，提炼出技能清单，简化成几行就行了。
项目经验写得太范了，可以多写一些具体的技术要点，可以网上找些简历参考下别人的项目经验是怎么写（吹）的。
项目经验看起来还是比较丰富的，但你这个描述太减分了。

如果没有事先准备的话，一下子想不出来也算正常吧，但我觉得现在稍微认真点的都会刷下题了。

先把简历发出来大家看下，还有你的面试表现如何？另一方面是否有可能你待遇要高了