After Submit 01
后记
将近一年以后回头看，这篇文章的工作实际没有那么困难。脚本主体是kpl师兄完成的，实际也是他的AI-Cat做数据集的脚本。甚至他交给我时，CO加氢的路径已经跑通了。我后来跟老师说，现在没人做CO加氢了，得做CO2加氢，没多久也做出来了。后来折腾了很久的都是一些边边角角的问题，比方说怎么从基元反应里连路径；怎么加Gibbs校正；如何数据处理，展示数据集，搞一些好看的图，等等。大量的时间耗费在写文章、改文章、改不动文章emo。大概率emo完了还是不想改文章，就跑去做其他一些奇奇怪怪的东西。
后来很多事情有一些不真实感。
比方说当时投稿非常顺利，8 June 2022 reveived, 7 July 2022 accepted, 30天就接收了，18 July 2022 online。编辑只找了两个审稿人，我很纳闷，刘老师说“因为编辑喜欢”，而处理稿件的副主编Aron Walsh也确实是做理论的。两个审稿人中，一个做理论的一个做实验的，没有特别麻烦的问题。稍许有些苦恼的是第二个审稿人，他可能是Beck2021NatCatal的作者，是站在ZnOx/Cu的立场上的。所幸，这篇工作本来就引到了(确实是我有很深印象也很喜欢的工作)，于是解释了一下，加了一段讨论。reply完没几天就接收了。
收到accept的消息以后就开始喝酒，倒头大睡。
之后写过几篇新闻稿，投到小柯化学和科学网等，在化学系主页上挂了几天，后来又上了复旦大学官方微信的7月科研速递。
几个月以后(13 Nov 2022)又收到了JACS主编Erick M. Carreira教授的邮件，恭喜文章的发表，说“I thoroughly enjoyed reading it and reflecting on the results.”我有点受宠若惊，不太确定这是套话、还是他真的读过了、还是别的什么，实在是没什么真实感。
元旦聚餐，刘老师酒后盛赞说什么“这是今年最重要的一篇工作”，我自己听得木木楞楞的。总觉得那是一些我够不上的一些夸奖。
将近一年过去，google scholar显示已经17次被引用了。至少没有拖JACS影响因子的后腿（笑）
比较切实的成就感，其实是自己制作的一些脚本，有幸能被同门继续利用。比如CV contour图、微观动力学求解等。重构的laspy代码也被师弟师妹们用起来了，也有了一些二次开发。
但是批判的话，还是有很多错误。
比方说周期实在拖得太长了。接收以后刘老师在群里说：“这个工作搞了2年？3年？真的是我都要搞抑郁了。现在有解脱的轻松。”我确信我是搞自闭了，抑郁也有可能（笑）。
比方说很多学术规范确实不行。比方说开始时，正文里放了一张图，但文字上没有提到它、提到了图但没描述；又或者在Method里让读者越级打怪去看我的Figure 4；又或者语言的逻辑不对，绕来绕去。最近组会里听见老师批评师弟类似的低级问题在，不禁莞尔。事实上，文章几乎是刘老师重写的。如果和出版版本对照着看，我的初稿着实惨不忍睹。
比方说，后来两次在奖学金评定里，我实际都吃了亏。最大的问题是，讲自己的工作没有讲清楚。两次都是5min的短报告，第一次我对着做实验的评委老师狂暴输出计算方法和理论结果，最后老师问我“你这个工作的创新点在哪里”，老师懵，我也懵。做报告，不考虑观众能否接受，属实是神经病行为。而且这种评奖的报告，不同于对同行讲的学术报告，更不同于组会，况且只有5分钟，是没办法讲细节的。要想办法让外行人听明白故事的轮廓，讲工作的影响，收获的评价。
第二次报告，我吸取了部分教训，砍了大半的内容。还是那位老师，他说他看过这篇文章了（很荣幸），很好的工作，但对实验上甲醇合成的生产能提供什么指导吗？我脑子又卡住了，回答的大体意思说：对于那些做表征研究活性位的实验，我们的计算结果能提供一些印证；但和工业生产实在差得太远，好像不能提供什么指导。
天呐，我是脑残吧。
刘老师锐评：“报告做成这样就是因为文章不是自己写的”，也确实如此。
希望以后能够顺利一些吧。
写于改不出文章的日子
2023年5月
折腾了这么久，总算先把文章投出去了。
后面必然还有很多折腾的问题，但尚可小小开心一会儿。
在此，把三年间的一些感想、经验整理成文，以飨来者。
我个人的想法，必非最佳的解决方案，只是期许部分内容能有一些帮助。请有选择性地看待。
最后，感谢刘老师的指导和帮助。
2022年6月9日
shiyf
Coding
文件不要超过1000行
- 文件太长，意味着这个文件一定是可以分割的
- 在一个长文件里，光是找一个函数都会非常痛苦（鼠标滚轮或者PageUp&Down），只能全靠搜索(ctrl+F或者:xx)
函数不要超过200行
- 函数太长，意味着这个函数一定是可以分割的；或者一些代码段没有很好地复用
- 大函数出错不方便找问题，难以测试
- 大函数多半有复杂的逻辑嵌套，也会使得可读性下降、可维护性下降
- 有几段代码太屎山了，甚至我不想修改他们，只想推倒重写，我很后悔。
命名(函数名/变量名/参数名/文件名)多费一些心思
- 一个正常的命名，应该能让人直接理解其功能和类型。
- 这能帮助别人看懂代码
- 这能帮助你自己一段时间之后，回忆起代码
- 你遇到难以解决的问题时，别人更方便debug
- 避免使用意义不明的
aa,11作为命名 - 不要惧怕使用长的变量名，尤其是使用IDE的选手，因为现在的IDE普遍有代码自动补全插件。
- 多敲点字不费事儿；因为，敲代码的时间往往没有读懂自己一个月前写了什么的时间长
命名(函数名/变量名/参数名/文件名)最好有统一的风格
- 要驼全驼，要蛇全蛇
- 驼里混下划线，或蛇里混大小写，或者半驼不驼，或者半蛇不蛇，会成为你一个月以后的噩梦
- 举个例子：“我记得这个函数，但这里是
abctolat还是abcToLat还是Abc2Lat还是Abc2lat还是abc_lat?”
我自己习惯的风格，大致如下，虽然我也没有很严格地遵守：
- 变量、参数：驼式命名，小写开头
- 函数、类：驼式命名，大写开头
- 静态变量：蛇形命名，全大写
文档和测试
- 对大项目，给每个文件、每个功能建议写单元测试。
- 项目后期，有时不得不修改底层代码，但这些底层代码可能引起其他代码的问题。有测试，你会对这些改动更加自信。
- 不要吝啬写注释和文档。尤其是用IDE的选手，注释写中文都不要紧，有注释就比没有好。
- 对于一些大型项目，项目有1/3甚至更多的内容，是文档or测试，是很正常的
验证原型还是五年计划？
-
实际上我们大部分为了发表而写的code，都只是写个prototype罢了。
- 写proprotototype时设计的架构，未必是合理的。往往开发到后半程时，处处掣肘，非常难受
- 不过，假使没有写过prototype：
- 你不知道自己真实的需求
- 你不知道怎样的架构是合理的，以及优秀的架构为何优秀
- 你不知道会在什么奇怪的角落，遇到什么奇怪的问题
- 实现基本的功能，说明自己的想法可行
- 踩坑并寻找解决方案；下次看到坑会有心理准备
-
如果验证说明想法很好，是未来可以传5年的代码
- 如果原有框架一团糟，设计好结构，重写一版程序
- 在合适的时间点重构。相比之下，肯定是写文章和毕业要紧。
- 跑路前留好注释和文档，方便师弟师妹看懂
- 事实上对于稍大的项目，强烈建议在项目伊始，就做好注释、文档，并使用规范统一的命名
- 单元测试是个好概念，大家可以了解一下
- 当然对于测试原型，
- 如果原有框架一团糟，设计好结构，重写一版程序
Debug 代价
- python脚本运行慢，其实不是大问题。但debug速度慢，是很难受的
- 比如debug的时候，改了两行代码，一次debug运行10分钟，遭不住的
- 这种情形下，建议：
- 优化代码，提升速度
- 制作快捷、独立的单元测试，而非直接运行main()
- 缓存部分数据，参见
pickle.dump,pickle.load
使用程序包
- 网上的程序包，没有文档的，建议直接ban了，别用
- 不同文档对开发者帮助的大小：教程 > 示例 » API Reference » 源代码
- 源码里对开发帮助的大小：函数名 > 注释 > 源码
Plot
Matplotlib制图
- matplotlib的函数和参数很容易记不清楚，多查官方文档&Google，cheatsheet建议开着随时备查
- 画图的脚本，务必保证可读性，可修改性。因为每一张图片，都可能反复修改数十次。
- 一张图片，对应一个脚本；一类图片，对应一个目录。别把自己搞晕！
- 保存图片分辨率高一些，我习惯写
plt.save_fig("xxx.png", dpi=300) - 不要怕文件太大，那是投稿前再考虑的事
PPT制图
- 不要觉得ppt土。有时在ppt/photoshop里改一改，远远比用matplotlib实现更加简单
- 文字标注、箭头、框，建议用ppt实现。如果底图需要修改，其他元素位置不变，替换底图即可。
Writing
- 我太过失败，不能给出什么建议。和初稿相比，刘老师几乎重写了一遍。
- 写作和修改的周期，不要像我这样拖得这么这么长。
- 动笔前想一想，需要画哪几张图，哪几张图值得放在正文。
- 所有图片放在一个ppt及文件夹中；所有脚本和绘图数据放在一个目录下。
- 建议初稿闭关一周速速写就
- 刘老师改完一稿以后，尽可能快地改好，回给刘老师。
其他的话
- 不要自闭，自闭没用，遇到问题，找人帮忙才会比较高效。
- 找不到人帮忙，及时跟老板
摆烂反映问题 - 不想做下去的课题，大不了就不做了，没事儿的