代码熟练度、过度设计与工程哲学
今天和朋友们聊了很多关于编程风格、熟练度和工程实践的话题，记录一些思考。
熟练度也是能力的重要一环
逐渐感觉"熟练度"本身也是能力的重要一环，一个需求查半天API和拿来就写差别还是挺大的，前者会懒癌发作直接开摆（，并且时间成本也是很大的成本。
但除非只关注一个小领域，熟练某个东西还蛮难的，感觉必须得代码量喂出来，上下文切换多了每次都忘得干净，对于Web类还好，反正试错和纠错成本极低，对于其他的就经常因为一些小错误浪费很多时间。
比如我是真记不住算法（）
这多少也是我机考翻车王的原因。LC刷了hot100，但很快忘光了。
过度设计的倾向
说实话我感觉自己是有过度设计的倾向的，快速糊一些代码会非常别扭难受，然后改来改去改来改去，经常为了"这个字段该放在这个类里面吗"、"这个函数是不是应该再做一次抽象"、"API的参数怎么设计"这种事情整半天。
一个例子：QBasic作业
今天看同学的文章讲到QBasic写了15个小时感觉实在太久了，有同学写了10个小时就写完了。
但我作为一个"老登"写的C++比他们多不少的情况下，却写了40个小时（）。先是想要多类型支持，后面想要完整BNF，再是尝试一切Modern C++化，再是做Qt Signal的中间层，再是测试（测试还想玩玩新框架），再玩模板和编译期检查，再引入其他的……
确实写Java写的了这下。虽然感觉写得可维护性很高，但实际上并没有人会来维护（跑）。就像我的QLink也写了40h，战线拉太长导致机考翻车了都不知道这个API哪发癫了，上次用这个API还是两三个月前.jpg。
设计哲学的影响
曾经刷的公开课的某个逻辑对我影响还是蛮深的：通过API设计、类设计、测试等，来用各种类型检查、名字确认等来避免自己写错的代码，而不是用人脑来避免自己写错。
这其实也是诸如DDD（领域驱动设计）之类的精髓。
好处是能轻松完成小项目到中大型项目的过渡，但坏处是让人在熟练度不够的时候写得更慢了。但我感觉有点太依赖这个了，导致我其实没有"糊出一个东西"的能力——例如没有类型就非常难受，API写的中途之中一补不全，这个逻辑就并不是很直观，就感觉API可以继续重构，然后继续折腾。
这辈子就是被Clean Code和设计模式害了（bushi）。我感觉我性能上的优化也不是很认真做，天天折腾这个代码优不优雅，这辈子有了。
过程导向 vs 结果导向
感觉我这样的整法就是很不利于考场的，因为你把重心放到过程而非结果的时候，自然就会淡化非过程的记忆。
之前有人讲他在学OS的时候在记一个"概念"是怎么被"推导"出来的，但不知道自己这样整到底重要还是不重要。anyway，我在学的时候也是：算法/机制的具体细节和代码是记不清的，就记得个思想/推导作为索引，到时候真用到了就依赖AI现查。
所以没有AI、补全和网络就大废功力（）
Go语言的慰藉
所以有些时候我真挺喜欢Go的：语法突出一个简洁，又有GC和goroutine解放大脑，引入外接库简单，编译还快，net、log之类的标准库在API设计上比C++ std不知道高哪里去了，defer之类的关键字也令人心情愉悦。
C++ API这么多细节这么杂真记不住啦。
SE同学的码量分布
有人觉得SE的同学码量应该很大所以算法没问题，但我觉得并非如此——SE的同学的码量是集中在系统上的。架构、文件、并发、加速这些可以给你很快的看，但算法属实是"数据集不够，欠拟合了"。
工程和算法完全是两个东西。OI里面你只需要靠cout和瞪眼检查就行了，因为dev的debug和CLion等相比差远了。
该规范规范，该潦草潦草——真正的工程智慧可能就在于知道什么时候该追求完美，什么时候该快速迭代。感觉糊业务代码还是可以的，这下上班圣体了。