- 2019-02-181：首先会校验用户名，可能是为了检测当前用户登录环境是否安全；
2：通过先检测登录环境是否安全会减少密码泄露风险；
3：从接口设计，第一步用户检测服务端接口应该会返回检测成功与否标识和唯一的会话 标识，客户端待用户输入密码，会将 用户名 密码 会话唯一标识 提交到服务端，服务端会将三者一起作为校验；作者回复: 安全是这个流程改进最大的好处之一。
8 - 2019-03-05文中的问题想到一点，可以防止撞库式的外部冲击对最底层的用户名密码验证模块产生直接冲击，如果100次尝试，第一道就拦掉了90次就产生了直接受益，这种时候还可以在第一道拦截用户名校验处对这种ip进行黑名单处理
作者回复: 我一直想在留言区看到有人讨论这个方案的安全改进。 谢谢你分享了这个想法！
4 
2019-02-18文中的问题：
1、先检验用户名是否存在，其一会让输错的用户省去输入密码的时间，尤其是密码复杂的。其二可以帮用户定位出错位置，用户名错误或密码错误。输入用户名后，输入密码前这段时间里用户能直接了当的看到用户名是否错误。输入密码后再报错，就能知道是密码错误，直接帮用户进行了校验，定位了出错的位置。带来的收益就是直观和简洁，与第一种方式相比，在输错用户名的前提下，避免了无效操作。
2、前后端代码结构，肯定是采用Ajax，当输入框监听到失去焦点，前端就立即将输入内容发送到后端进行验证，后端检验后将结果返给前端，当用户名不存在的时候前端可以在输入框下用醒目颜色提示。展开作者回复: 定位错误是其中的收益之一。如果1/10的用户输入用户名错误，你可以简单估算、揣摩一下实现得当的服务器的性能提升比例以及用户的体验提升程度。
现在的界面，也有的不显示密码输入框，直到用户名校验通过，才显示密码输入框。 也有的使用两个页面，第一个页面用户名，第二个页面密码。 4
2019-02-20像京东架构那样，他们最小单位是模块，基础模块的话，很多模块都会调用，以垂直划分的话，这类模块放在最下面，比如数据库模块，有一说法“基础模块下沉”……
几个最基础的模块又组成一个大一点的基础模块，放在中间位置…
最顶的是复用最少的，但由中间层的几个基础模块组成……
一句话:复用越多的模块越放下面，复用越多越是基础模块……那不是“基础模块下沉，独立模块上升”？作者回复: 看起来像是说依赖关系，上层依赖下一层，复用模块不依赖上一层的，可以考虑放到下层的模块，这样复用更方便更多。
3
2019-02-18想问下怎么通过用户名检测登录环境是否安全的？作者回复: 确实有空间来检测登陆环境。比如说，通过检查该用户名是否正在使用常用的设备，来决定是否启用更多的校验，比如验证码、检查是否人工操作等。
3- 2019-05-23分离用户名和密码的验证：
1. 从产品层面模块化，如果有问题能清晰指出哪里的问题
2. 用户体验升级，如果用户名不存在不需要输入密码
3. 服务端更灵活，如果用户量巨大，可以做一个用户名的缓存，而不用每次登陆都必须连接数据库验证用户密码正误
4. 用户名是公开信息，但密码是敏感信息，先发送用户名能检查网络安全，避免直接一起发送时网络不安全带来的隐患 1 
2019-04-02代码块越小，越容易复用，这个和“重构改善即有代码设计”里的观点一致 1- 2019-02-19一个项目有n多的代码，一个代码块只做一件事情的话，那么很多重复用的代码，是不是可以变成基础模块？
我看到有人说“基础模块下沉，方便复用”，那在中间层和上层的模块呢？有什么原则之类吗？作者回复: 每一层的代码，都要考虑复用。也许，“下沉”说的是复用代码剥离出来，当作通用的类库？我不太了解这个说法。
1 
2019-02-19重新阅读了一遍文章，发现设计成两个接口的还有一个好处是接口细分了更容易复用，比如修改密码的时候可以复用登录时密码检验的接口作者回复: 嗯，这也是一个优点。
1
2019-02-19只有持续不断的重构review才能将代码改进到最好，很多写代码的完成业务功能就完事，具有精益思维是简单的前提作者回复: 你说的精益思维是持续改进的意思吗？我比较倾向于一开始就选择简单的方案，最核心的需求，然后再把这些简单的东西做好，持续改进。
1- 2019-02-18除了用户体验和安全性的好处，想不到还有哪些性能上的提升了。分不分两个接口，总的处理逻辑都是不变的，挺想知道对性能上有哪些提升，求大神们指点一二。
作者回复: 分不分两个接口，总体逻辑可以不变，也可以改变。性能提升不太容易想的到，理一理客户端和服务端的代码的什么样，想一想可以怎么变化，意外情况怎么处理。
1 
2019-12-08最近刚换工作，第一次接需求，需要在已有的代码上做修改。这块代码历经不同人员的维护，参杂了许多需求。很多逻辑参杂在了一起，已经很复杂了。在开始动手之前，我先花时间理清代码处理的逻辑，搞明白了为什么。和他人讨论了如何梳理流程，先把代码按清晰的流程改造好，再往里面添加新的需求。在项目没有很紧急的情况下，作为新人，我觉得花这些时间把流程梳理清晰，做一下设计，把代码先改的简单清晰，还是很值得的。然后再在上面添加新需求，可以减少错误发生的概率。 当然，做了设计还需要多跟老同事讨论，防止遗漏。除此之外，代码编写规范，主动邀请他人对代码进行检视（之前他们没这方面的要求），写好文档存底，认真测试。我觉得这样才过得去。作者回复: 都是好习惯！
2019-04-30有的代码是一个独立的功能，但是只在一个地方使用，没有其他地方需要复用它，这种时候就会失去把它拆成一个单独方法的动力。想请教下这种只用一次的“功能”还需要写成独立的代码块吗？作者回复: 看代码逻辑和长度吧。 如果长度段，写在使用它的方法内就好了；如果长度长，逻辑独立，拆解成一个内部私有的方法，更容易理解和阅读。