一些想法
一些想法
都是些有的没的，脑袋不大疑问不少，还不成体系，先随便看着
学东西的时候多想想
- 这是什么(定义)
- 他做了什么(功能，输入输出)
- 如果你来做，你会怎么做
- 他怎么做的(内部功能实现)
- 为什么这么做，和你得想法优劣在哪些方面
- 还能怎么做
- 查看同类竞品的特点
- 他的特性和使用场景
- 他处在哪一层以及可能涉及到的依赖
写代码看代码时多想想，think twice，code once。
- 编码标准
- 命名约定
- 设计模式
- 注释
- 用到的测试脚本和测试用例等
- 为什么使用特定的设计模式？
- 为什么使用特定的语言？
- 缺点是什么？它可以与你的代码一起使用吗？
- 这些代码是否易于维护？
工具层面能解决的安全问题，不要写到手册里。
Logistic regerssion 有一定的复杂度。对新人来说，最好有一个完整的推导指南，然后反复推导N（N>=5）,直至能独立推导，再用python或者java实现这个推导，然后用这个实现解决一个实际应用，这样差不多算是掌握Logistic regression了，上述过程缺一不可而且是成本最小的学习方案。
想拥有自由就必须时刻保持警惕。
要有与时间战斗的感觉
凡是能说的，都能够说清楚 凡是无法言说的，应当保持沉默
在有关事实、思维和语言关系的概念阐释中，维特根斯坦很少给出精准的界定，结果造成了一些彼此歧异的理解和译读，他也经常抱怨自己的见解被误解或歪曲了，却没有意识到，即便他的经典结论“对于不能言说的东西必须保持沉默”，也经不起严格的语义分析，因为对于人们“不能”言说的东西，原本就没有必要命令人们“必须”保持沉默。实际上，这个结论只是以用词不当的方式，表述了学术研究的一条原则：对于那些能够言说、自己却说不清楚的东西，身为学者必须保持沉默。--刘清平
对于框架
对于框架和工具，我们不可能完全的把握，而且完全的把握一个框架的API是没有意义的。
首先在使用工具的过程中把握这个框架设计的理念和模式，自己设计程序的时候配合的更好
对与API的使用，整理自己碰到的和常用的，然后还有一些坑，默认已知的和普通的就不用复制进去了，可以放文档。
关注系统的一致性，稳定性，产品思比如12306存储压力很大，没有死磕而是通过分时段售票，候补票，验证码等过滤流量减小负载
选型和解决问题
项目背景
需要记录什么样的数据，库表怎么设计
项目架构
- 数据源从哪里来的，经过哪些中间件，做了哪些大致处理
- 一致性，实时性,粒度原子性，存or查的有序性，有速度要求的冷热节点or缓存选择
当前问题
- 对数据的高频操作，分析各个环节的瓶颈，一般三方面IO网络计算。
方案选择
别人解决类似的问题有哪些方案，场景和自己遇到的异同
- 确定的方案优势，通过怎样的原理解决了哪个问题
- 确定的方案劣势，把瓶颈转移到了哪里，这模块有多少能够资源能承载此瓶颈
迁移过程
动了哪些环节，为解决什么问题而动
效果对比
改变前后QPS对比：
- 数据存储IO压力测试
- 相关中间件压力测试
- 系统总的压力测试
- 监控 经验总结