代码精进之路
范学雷
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讲)
结束语|如何成为一个编程好手?
代码精进之路
登录|注册

12丨组织好代码文件,要有“用户思维”

范学雷 2019-01-30
上一讲中,我们讲了如何组织代码段,今天我来讲下,如何组织代码文件。
最开始接触一个项目代码时,我们最渴望的,就是快速揭开项目的面纱。这个项目是干什么的?是怎么做的?该怎么使用?
有很多这样的问题,排着队等我们处理。我们需要从一个点开始,先撕破一点点皮,然后,像剥洋葱一样,一层一层地阅读,一层一层地了解。
刚拿到一个项目的代码时,你最想找哪一个文件?面对大量的文件,该从哪里入手?创建一个项目时,各式各样的文件该怎么规整?
如果一个项目很小,只有三五个文件,我们不用担心上述的问题。
但事实上,一个典型的软件项目,拥有上百个文件是寻常的事情。如果这些文件组织混乱,就会让整个项目乱糟糟的,我们很难入手去查找、阅读和测试。
其实文件的组织是一个简单的事情,但这些简单的事情如果不能做得清晰、明了,就会变成一个效率的黑洞。
文件的组织要层次分明、易于检索、一目了然。要做到这一点,我们可以从用户思考问题的逻辑入手。

逻辑之一:软件是干什么的?

无论我们开始一个软件项目,还是阅读一个软件的代码,第一个遇到的问题就是,这个软件是干什么的?
可以回答这个问题的文件叫做 README,它的命名全部使用大写字母。需要被放在一个软件工程的根目录里,方便人或者机器第一时间找到,从而轻而易举地找到并进行阅读。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《代码精进之路》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • MOV AX,0
    公司项目模块的大致结构:
    build/
    src/
         main/
                  java/domain.parent.module/
                                                             constants/
                                                             entity/
                                                             dao/
                                                             mapper/
                                                             service/impl/
                                                             facade/impl/
                                                             job/
                                                             utils/
                  resources/
                                  META-INF/
                                                   dubbo/
                                                   spring/
                                                   app.properties
                                  log4j.properties
        /test/java/domain.parent.module/
                                                            dao/
                                                            service/
                                                            facade/
                                                            job/
                                                            utils/
                                                            TestBase.java
    deploy.properties
    jenkinsfile
    pom.xml
    不经意间已经习惯这种结构了。很多东西用的时候很顺,以致于都察觉不到它的好处。看老师的文章感觉非常亲切,也收获了很多!

    作者回复: 谢谢你分享这个典型的代码文件组织结构。

    2019-01-31
    4
  • Being
    doc/
          需求文档(按功能模块分子目录)、各成员的日志记录(按项目节点分子目录)、UI设计
    Source/
         VS工程下的多个项目相关Project工程目录、基础库、test工程、Tools工程 ,.sln文件一般放在该目录,主要是VS IDE的组织方式
         每个工程下就是会细分像老师说的src
    Product/
         一般还要分Debug/Release Win32/x64, 存放相应的exe生成文件以及依赖库
         主要方便发布与测试
    Versions/
         就是每个节点后发布的版本了,并记录依赖的相关部署环境等

             

    作者回复: 嗯,看起来像是代码的上一层的组织方式,不仅包括代码,还包括编译后的文件,以及支持文件。

    2019-01-30
    3
  • 极客不落🐒
    作为 Javaer,分享一些自己接触到东西。目前很多都有脚手架工具,可以帮你快速初始化/规划项目代码组织,比如:Java 里面的 Maven,可以帮你快速初始化一个项目(Maven 生成的工程目录划分,具体细节移步官方文档:https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html)。

    利用脚手架初始化完一个项目之后,涉及到了分层,一般会有类别(controller/web、service、dao 等)、业务模块(user、order 等)两个维度,看是先按照类别再按业务分层(如:controller/user、controller/order;service/user,service/order),还是先按照业务再按照类别分层(user/controller,user/service;order/controller,order/service),但一定不要两种风格混合。

    作者回复: 好经验,谢谢分享!

    类似于Maven的脚手架工具很有价值,我也建议大家了解了解。我个人特别喜欢它对代码依赖关系的自动化处理。第二部分,我们会使用一下这个小工具(不会讲,就是用一下)。

    2019-01-31
    2
  • Lindroid
    总结:
    README:命名大写字母,放在根目录下,用于介绍软件的使用;
    COPYRIGHT:命名大写字母,放在根目录下,用于解释软件的版权;
    源代码文件:src目录下,可再细分目录;
    测试代码:需要和功能代码分开存放,可放在根目录的test目录下,一个测试文件最好执行一个独立任务;
    文档:可以放在根目录的docs 或者 doc 的目录下。
    2019-04-19
    1
  • 老吴
    说到这个,老师能否加开一篇领域驱动的课

    作者回复: 这是一个好话题,但是我现在真的不懂领域驱动。要加油学习了!

    2019-02-26
    1
  • pyhhou
    自己使用的就是最简单的 MVC 的代码结构,写的是 node JS,不需要编译结构也是一些个工具帮忙生成的:
    bin/
    node_modules/
    public/
    scripts/
    src/
         controllers/
         helpers/
         models/
         routes/
    tests/
    .env
    app.js
    package.json
    package-lock.json

    这里比较不好的是 tests 很难和 src 里面的东西一一对应,有时写着写着会把自己绕进去,不知老师有没有什么好的建议。还想请问老师的就是即便是在一个好的文件框架下,很多子文件的层级结构也还是得由我们程序员自己来设定,就比如一个功能可以由一个文件实现,也可以由多个文件协同实现,这里面有没有一些个比较好的实践,或者是可以借鉴的思想方法,使得即便是不看半句代码,光看文件名加文件结构就可以把设计思想以及代码功能看出个十之八九?

    作者回复: 对应好源代码和测试案例,是一个省时省力的思路。JDK一般按照源代码的目录结构组织测试。比如,测试接口规范javax.net.ssl.SSLSocket的代码,放在test/jdk/javax/net/ssl/SSLSocket目录下。测试接口实现sun.security.ssl.SSLSocketImpl的代码,放在test/jdk/sun/security/ssl/SSLSocketImpl目录下。我们经常需要翻找测试用例,来检查测试覆盖是不是足够,这种对应的组织方式的确省了不少时间。

    文件的安排,首先要做好模块的划分,功能类似的、目标类似的放到一个命名空间里(比如Java的包);然后,分割接口规范和内部实现;接口规范和内部实现放到不同的命名空间里;然后,再划分依赖关系,公开接口的文件,一个类一个文件;内部实现的代码,尽量减少文件间的依赖关系,只被一个类依赖的代码,都放到那个类里去。

    比如,javax.net.ssl是TLS协议的公开接口规范,单独使用一个公开的包。sun.security.ssl是TLS接口规范的一个实现,单独使用另外一个包。sun.security.ssl.ClientHello类里,还包含了支撑这个类实现的其他几个内部类。

    package sun.security.ssl;
    final class ClientHello {
        static final class ClientHelloMessage extends HandshakeMessage {
            // snipped
        }

        private static final
                class ClientHelloKickstartProducer implements SSLProducer {
            // snipped
        }
        // snipped
    }

    另外,就是做好命名空间和类的命名,名字清晰了,从文件名和文件结构的确可以看到更多的东西。

    2019-02-24
    1
  • 苦行僧
    一般使用maven的工程结构
    2019-02-07
    1
  • Robic
    上文图中那个make/是什么含义

    作者回复: 放置makefile的目录

    2019-01-30
    1
  • Sisyphus235
    软件组织都应该有背后逻辑,知道软件功能能更好的看源码,如果能跑起来在使用中了解速度更快,阅读源码能逐步了解代码实现原理,测例能进一步帮助开发者了解软件的边界
    2019-05-22
  • 彩色的沙漠
    请问老师,我经常看到的github项目还是自己的项目都是把软件是干什么的和怎么使用放到了README文件,没有区分放到README和软件文档doc两个文件维护。

    作者回复: 一些小的项目,README就能够承担这些责任了。

    2019-05-07
  • 小文
    很多网上的代码都没有版权说明,那也会受法律保护吗?

    作者回复: 是的。这种代码的版权风险很大的,不知期限,不知版权归属,不知许可方式。有些法律默认没有版权说明,就是作者保留所有权利。

    2019-02-18
收起评论
11
返回
顶部