A

考虑到单纯的分析如果又不透彻的话，很像作弊，这周Pandas对于我来说可能会花点时间，这个还是选个题做一下的靠谱

选了最长回文那个

image.png

内存确实吸取了之前的教训，那就是字符串除了最终返回，不要substring，运行时间第一次超出限制是因为找到对称的那个时候没有及时中止，第二次是因为特么忘了写return结果也没中止

第一次执行出错是空字符串没错卫语句校验

时间的消耗长，找时间再分析下吧

R

上周超喜爱的那篇，逐字带节奏复述一下

Development Conventions

Efficient team work that produces high-quality software requires a common set of rules.

生产高品质软件的高效团队工作需要一组统一的规则

Consistent Source Tree

（一致性）

Follow the existing coding style and formatting rules. The projects contain auto-formatting rules for the Eclipse IDE.

遵循已有的代码风格和格式化规则。这个工程包含一个Eclipse IDE用的自动格式化的规则（但我其实没找到在哪儿）

Update your local branches and run the build locally before every push. Push only if the build succeeds and the configured compiler settings do not show any warnings in the Eclipse IDE.

每次推送前，更新你本地的分支并且本地执行构建。只在本地构建成功并且Eclipse IDE的编译设置中配置的警告都不显示了再推送

Documentation is part of the product. Whenever you implement a new feature or change existing behavior make sure to update all corresponding JavaDoc as well as other documentation with the same change set. The product should always be in a consistent state. For every change the following items should be checked:

  • Corresponding JavaDoc, every public type and member requires JavaDoc.
  • Documentation referring to the modified concepts, interfaces or implementation.
  • New features, bug fixes and modified behavior should be enlisted in the org.jacoco.doc/docroot/doc/changes.html file together with the corresponding issue tracker id.

文档是产品的一部分。无论是实现一个新特性还是改变已有代码行为，都要确保更新了所有相应的JavaDoc及其他文档也做了相同的变更。产品应该永远保持一致的状态。每一个变更，都要检查以下的项目：

  • 相对应的JavaDoc，每一个public的类型和成员都要有JavaDoc
  • 文档要涉及变更的概念、接口、实现
  • 新特性，bug修复和调整过的行为应当同相应的问题跟总系统的idy一起列入文档org.jacoco.doc/docroot/doc/changes.html

    Design for Integration

    The primary focus of the JaCoCo project is to provide a code coverage library. Integrators may want to embed JaCoCo in different tools and environments with very different usage scenarios. Therefore following aspects should be considered: Documentation: All APIs should be properly documented on different levels of granularity:

    • General usage
    • Bundle summary
    • Package summary
    • Type description
    • Member description

    Proper Units: All APIs and internal implementation classes should form proper units with well defined responsibilities and dependencies. Each class and method should focus on a single concept. It should be possible to use different aspects separately. Abstraction: All APIs must use the most general abstractions possible. For instance reading binary data should rely on the java.io.InputStream interface, not on a java.io.File object. System Dependencies: Avoid any dependencies to the local file system, network resources, threads, processes etc.

JaCoCo工程主要聚焦在提供一个代码覆盖率的依赖库。集成者可能要在非常不同的使用场景下将JaCoCo嵌入到不同的工具和环境当中。因此考虑遵循以下的几个方面：
文档：所有的APIs都应当在不同的粒度级别恰当的文档化：

  • 于半的使用
  • 捆绑的摘要
  • 打包的摘要
  • 类型描述
  • 成员的描述

恰当的单元：所有的APIs和内部实现应当组织成定义良好的行为及依赖的恰当单位。每个类和方法应当聚焦在单一的概念上，它应当能够被不同分离的方面所使用
抽象：所有的APIs应当使用尽可能通用的抽象，例如读取儿禁止数据应当依赖于InputStream而不是File对象
系统依赖：避免任何对本地文件系统、网络资源、线程、进程等等的依赖

Test Driven Development

All code added to JaCoCo should have corresponding JUnit test cases. Ideally tests are developed before or along with the actual implementation:

  • Every new feature should be verified by test cases.
  • Modified behavior should also be reflected by test cases.
  • Ideally for every reported bug a reproducer is added to the unit tests.

所有添加到JaCoCo中的代码应当具有相应的单元测试用例。比较理想的测试应当在开发完成之前或者同开发一起实现的：

  • 没个新的特性都应当有测试用例校验
  • 调整的行为也应当反映在测试用例中
  • 比较理想的是，每一个被复现的bug都应该添加一个单元测试

Keep an Eye on License Issues

All code included with JaCoCo must conform to the EPL license.

  • Every committer and contributor must agree that all code will be published under EPL. He or she must be the original author and must have the permission to contribute code to JaCoCo, for example if such a permission is required by the employer.
  • Every third party content must be enlisted in the corresponding about.html file along with its license.
  • Every third party content included with the JaCoCo distribution must be enlisted in the org.jacoco.doc/docroot/doc/license.html file and the corresponding about.html file along with its license.
  • Every source file (Java, Build Script, DTD) must have a EPL license notice. The initial contributor should be listed. In case of significant changes or additions additional contributors should also be listed.

所有包含在JaCoCo中的代码必须符合EPL license

  • 每个提交者和贡献者必须同意所有的代码将在EPL下发布。他或她必须是原始的作者并且必须有贡献代码给JaCoCo的权利，例如是需要被雇主认可有权贡献代码的
  • 每个第三方的内容必须列入到相应的about.html文件连同其license一起
  • 每个被JaCoCo发行包包含的第三方内容必须列入到balabala license.html文件并且有相应的about.html文件同其license一起
  • 每个源文件（Java，构建脚本，DTD）必须有一个EPL license notice。初始的贡献者应当列入其中。每当有重大的变更和附加内容，贡献者也应当列入其中

Contribution process

All changes on the JaCoCo code base are handled via GitHub pull requests and always reviewed by a second developer. This applies for external contributors as well as for project members. Beside functional correctness every pull request needs to fulfill the conventions above.

For external contributors the following recommendations will help the project to incorporate their precious work:

  • Get in touch: Before you start a bigger contribution please get in touch through our mailing list to make sure the JaCoCo project considers this in scope and the approach fits in the overall architecture.
  • Clear scope: We track and review every semantical change through a separate pull request. Pull requests handling various topics (“I fixed this and that”) are typically difficult in handling and are therefore declined.
  • No technical debt: We are committed to maintain JaCoCo in the long run with on a high quality level. Therefore we will not accept contributions as long as they add technical debt to the project (e.g. lack of tests or design issues).

JaCoCo所有的代码变更都通过Github的 PR并且永远都要经过第二个开发者审核。这既适用于外部的代码贡献者，也适合工程的成员。除了功能正确每个PR需要履行上述约定
对于外部的贡献者，以下的建议将帮助项目整合他们宝贵的工作：

  • 保持接触：在你开始一个大的贡献前，请通过我们的邮件列表联系我们，确保JaCoCo项目认可这个想法是适应整体架构的
  • 清晰的范围：我们通过分离的PR，跟进和审查每一个语义上的变更。PR通常很难处理多个主题（“我修复了这个和那个”）因此是被禁止的
  • 拒绝技术债务：我们承诺维护JaCoCo在长远方面保持一个高品质水平。因此只要贡献者会增加技术债务到项目，我们都不接受（例如：缺乏测试，或者有设计问题）

    T

image.png
关键是ctrl + Shift + I 这个快捷键组合，应该说就是再一个弹出窗口中显示定义它的（源码）位置，比如在一个new HashMap<>()的HashMap上停留光标，然后按Ctrl+Shift+I，会在弹出框中看到定义这个类相关部分的代码，这个还不是太明显，可以找一个自己写了单元测试的类型，在单元测试中试一下，比如找一个测试方法的位置放置光标，会在弹出窗口中显示这个方法实现的代码

如果光标放置的位置有一个抽象体系层次，那么所有的接口和实现类会形成一个下拉列表，供选择
image.png

S

俗务缠身啊，所以拿工作当中一篇凑数吧，因为涉及公司内敏感信息，就不public share了

补充：

其实，发现已经有几周没有在打卡群里面共享自己的ARTS地址了，但是自己还在坚持输出，并且确实有意识的提升一些质量，也不能老糊弄是不是，所以有那么一点欣慰，自己感觉自己习惯正在养成中

别人怎样看其实也就真的不是特别有所谓了，但是不能像乐夏2里面老白那样，不能嘴上假装不care，还是要听、想，放宽心境，然后决定自己怎么做，做真正有意义的事情，嘴炮什么的就没意义了