代码精进之路
范学雷
Oracle首席软件工程师,Java SE安全组成员,OpenJDK评审成员
立即订阅
6350 人已学习
课程目录
已完结 47 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 你写的每一行代码,都是你的名片
免费
第一模块:代码“规范”篇 (16讲)
01 | 从条件运算符说起,反思什么是好代码
02 | 把错误关在笼子里的五道关卡
03 | 优秀程序员的六个关键特质
04 | 代码规范的价值:复盘苹果公司的GoToFail漏洞
05 | 经验总结:如何给你的代码起好名字?
06 | 代码整理的关键逻辑和最佳案例
07 | 写好注释,真的是小菜一碟吗?
08 | 写好声明的“八项纪律”
09 | 怎么用好Java注解?
10 | 异常处理都有哪些陷阱?
11 | 组织好代码段,让人对它“一见钟情”
12丨组织好代码文件,要有“用户思维”
13 | 接口规范,是协作的合约
14 | 怎么写好用户指南?
15 | 编写规范代码的检查清单
16丨代码“规范”篇用户答疑
第二模块:代码“经济”篇 (14讲)
17 | 为什么需要经济的代码?
18丨思考框架:什么样的代码才是高效的代码?
19 | 怎么避免过度设计?
20 | 简单和直观,是永恒的解决方案
21 | 怎么设计一个简单又直观的接口?
22丨高效率,从超越线程同步开始!
23 | 怎么减少内存使用,减轻内存管理负担?
24 | 黑白灰,理解延迟分配的两面性
25 | 使用有序的代码,调动异步的事件
26 | 有哪些招惹麻烦的性能陷阱?
27 | 怎么编写可持续发展的代码?
28 | 怎么尽量“不写”代码?
29 | 编写经济代码的检查清单
30丨“代码经济篇”答疑汇总
第三模块:代码“安全”篇 (14讲)
31 | 为什么安全的代码这么重要?
32 | 如何评估代码的安全缺陷?
33 | 整数的运算有哪些安全威胁?
34 | 数组和集合,可变量的安全陷阱
35 | 怎么处理敏感信息?
36 | 继承有什么安全缺陷?
37 | 边界,信任的分水岭
38 | 对象序列化的危害有多大?
39 | 怎么控制好代码的权力?
40 | 规范,代码长治久安的基础
41 | 预案,代码的主动风险管理
42 | 纵深,代码安全的深度防御
43 | 编写安全代码的最佳实践清单
44 | “代码安全篇”答疑汇总
加餐 (1讲)
Q&A加餐丨关于代码质量,你关心的那些事儿
结束语 (1讲)
结束语|如何成为一个编程好手?
代码精进之路
登录|注册

20 | 简单和直观,是永恒的解决方案

范学雷 2019-02-18
上一次,我们聊了影响代码效率的两个最重要的因素,需求膨胀和过度设计。简单地说,就是找到要做的事情,做的事情要少。接下来,我们来聊聊怎么做这些事情。其中,我认为最重要的原则就是选择最简单、最直观的做法。反过来说,就是不要把事情做复杂了。
要想简单直观,我们要解决两个问题。 第一个问题是,为什么要简单直观?第二个问题是,该怎么做到简单直观?

为什么需要简单直观?

简单直观,看似是一条每个人都能清楚明白的原则。事实上,这是一个非常容易被忽略的原则。如果我们没有对简单直观这个原则有一个基本的认识,就不太可能遵循这样的原则。
我们都喜欢原创和挑战,来展示我们的聪明才智。而简单直观的事情,显而易见的解决办法,似乎不足以展示我们的智慧和解决问题的能力。
遗憾的是,在软件世界里,一旦我们脱离了简单直接的原则,就会陷入行动迟缓、问题倍出的艰难境地。简洁是智慧的灵魂,我们要充分理解这一点。
简单直观是快速行动的唯一办法
我们真正要的不是简单直观的代码,而是轻松快速的行动。编写简单直观的代码只是我们为了快速行动而不得不采取的手段。有一个说法,如果面条代码能够让我们行动更快,我们就会写出面条代码,不管是刀削面还是担担面。
我见过的优秀的程序员,无一例外,都对简洁代码有着偏执般的执着。甚至小到缩进空格该使用几个空格这样细枝末节的问题,都会严格地遵守编码的规范。乍一看,纠缠于缩进空格不是浪费时间吗?可是真相是,把小问题解决好,事实上节省了大量的时间。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《代码精进之路》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(13)

  • 唐名之
    1:首先会校验用户名,可能是为了检测当前用户登录环境是否安全;
    2:通过先检测登录环境是否安全会减少密码泄露风险;
    3:从接口设计,第一步用户检测服务端接口应该会返回检测成功与否标识和唯一的会话 标识,客户端待用户输入密码,会将 用户名 密码 会话唯一标识 提交到服务端,服务端会将三者一起作为校验;

    作者回复: 安全是这个流程改进最大的好处之一。

    2019-02-18
    7
  • IamNigel
    文中的问题想到一点,可以防止撞库式的外部冲击对最底层的用户名密码验证模块产生直接冲击,如果100次尝试,第一道就拦掉了90次就产生了直接受益,这种时候还可以在第一道拦截用户名校验处对这种ip进行黑名单处理

    作者回复: 我一直想在留言区看到有人讨论这个方案的安全改进。 谢谢你分享了这个想法!

    2019-03-05
    3
  • hua168
    像京东架构那样,他们最小单位是模块,基础模块的话,很多模块都会调用,以垂直划分的话,这类模块放在最下面,比如数据库模块,有一说法“基础模块下沉”……
    几个最基础的模块又组成一个大一点的基础模块,放在中间位置…
    最顶的是复用最少的,但由中间层的几个基础模块组成……
    一句话:复用越多的模块越放下面,复用越多越是基础模块……那不是“基础模块下沉,独立模块上升”?

    作者回复: 看起来像是说依赖关系,上层依赖下一层,复用模块不依赖上一层的,可以考虑放到下层的模块,这样复用更方便更多。

    2019-02-20
    3
  • Junix
    文中的问题:
    1、先检验用户名是否存在,其一会让输错的用户省去输入密码的时间,尤其是密码复杂的。其二可以帮用户定位出错位置,用户名错误或密码错误。输入用户名后,输入密码前这段时间里用户能直接了当的看到用户名是否错误。输入密码后再报错,就能知道是密码错误,直接帮用户进行了校验,定位了出错的位置。带来的收益就是直观和简洁,与第一种方式相比,在输错用户名的前提下,避免了无效操作。
    2、前后端代码结构,肯定是采用Ajax,当输入框监听到失去焦点,前端就立即将输入内容发送到后端进行验证,后端检验后将结果返给前端,当用户名不存在的时候前端可以在输入框下用醒目颜色提示。

    作者回复: 定位错误是其中的收益之一。如果1/10的用户输入用户名错误,你可以简单估算、揣摩一下实现得当的服务器的性能提升比例以及用户的体验提升程度。

    现在的界面,也有的不显示密码输入框,直到用户名校验通过,才显示密码输入框。 也有的使用两个页面,第一个页面用户名,第二个页面密码。

    2019-02-18
    3
  • 空知
    想问下怎么通过用户名检测登录环境是否安全的?

    作者回复: 确实有空间来检测登陆环境。比如说,通过检查该用户名是否正在使用常用的设备,来决定是否启用更多的校验,比如验证码、检查是否人工操作等。

    2019-02-18
    2
  • Sisyphus235
    分离用户名和密码的验证:
    1. 从产品层面模块化,如果有问题能清晰指出哪里的问题
    2. 用户体验升级,如果用户名不存在不需要输入密码
    3. 服务端更灵活,如果用户量巨大,可以做一个用户名的缓存,而不用每次登陆都必须连接数据库验证用户密码正误
    4. 用户名是公开信息,但密码是敏感信息,先发送用户名能检查网络安全,避免直接一起发送时网络不安全带来的隐患
    2019-05-23
    1
  • 北风一叶
    代码块越小,越容易复用,这个和“重构改善即有代码设计”里的观点一致
    2019-04-02
    1
  • hua168
    一个项目有n多的代码,一个代码块只做一件事情的话,那么很多重复用的代码,是不是可以变成基础模块?
    我看到有人说“基础模块下沉,方便复用”,那在中间层和上层的模块呢?有什么原则之类吗?

    作者回复: 每一层的代码,都要考虑复用。也许,“下沉”说的是复用代码剥离出来,当作通用的类库?我不太了解这个说法。

    2019-02-19
    1
  • aguan(^・ェ・^)
    重新阅读了一遍文章,发现设计成两个接口的还有一个好处是接口细分了更容易复用,比如修改密码的时候可以复用登录时密码检验的接口

    作者回复: 嗯,这也是一个优点。

    2019-02-19
    1
  • 苦行僧
    只有持续不断的重构review才能将代码改进到最好,很多写代码的完成业务功能就完事,具有精益思维是简单的前提

    作者回复: 你说的精益思维是持续改进的意思吗?我比较倾向于一开始就选择简单的方案,最核心的需求,然后再把这些简单的东西做好,持续改进。

    2019-02-19
    1
  • aguan(^・ェ・^)
    除了用户体验和安全性的好处,想不到还有哪些性能上的提升了。分不分两个接口,总的处理逻辑都是不变的,挺想知道对性能上有哪些提升,求大神们指点一二。

    作者回复: 分不分两个接口,总体逻辑可以不变,也可以改变。性能提升不太容易想的到,理一理客户端和服务端的代码的什么样,想一想可以怎么变化,意外情况怎么处理。

    2019-02-18
    1
  • sovran
    最近刚换工作,第一次接需求,需要在已有的代码上做修改。这块代码历经不同人员的维护,参杂了许多需求。很多逻辑参杂在了一起,已经很复杂了。在开始动手之前,我先花时间理清代码处理的逻辑,搞明白了为什么。和他人讨论了如何梳理流程,先把代码按清晰的流程改造好,再往里面添加新的需求。在项目没有很紧急的情况下,作为新人,我觉得花这些时间把流程梳理清晰,做一下设计,把代码先改的简单清晰,还是很值得的。然后再在上面添加新需求,可以减少错误发生的概率。 当然,做了设计还需要多跟老同事讨论,防止遗漏。除此之外,代码编写规范,主动邀请他人对代码进行检视(之前他们没这方面的要求),写好文档存底,认真测试。我觉得这样才过得去。
    2019-12-08
  • 木白
    有的代码是一个独立的功能,但是只在一个地方使用,没有其他地方需要复用它,这种时候就会失去把它拆成一个单独方法的动力。想请教下这种只用一次的“功能”还需要写成独立的代码块吗?

    作者回复: 看代码逻辑和长度吧。 如果长度段,写在使用它的方法内就好了;如果长度长,逻辑独立,拆解成一个内部私有的方法,更容易理解和阅读。

    2019-04-30
收起评论
13
返回
顶部