这里没有写清楚是 flask-sqlalchemy 还是 sqlalchemy。flask-sqlalchemy 的文档写的是 Model.query，它会返回一个 BaseQuery 的类，继承 sqlalchemy 的 Query 类，实现了一些额外的东西，比如 paginate 的方法。但看看上面方法 2 就知道，Model 和 session 一点关系都没有，这是因为在 app 里面封装了，不然 session.commit()怎么会知道上面那个 Model 做了什么。这也造成，当你只想使用 sqlalchemy 而不是 flask app 时，你会发现用不了，因为没有共享上下文，因此在调试和写测试时耦合度会比较高，那些喜欢自己写代码而不是学习一整套方案的人就不喜欢 flask-sqlalchemy 的，比如我。同时从代码看，sqlalchemy 的方案更加直接，session 可以简单理解成用于建立连接，session 传参去 query 模型，最后还要 add 一下加入事务，commit 提交，虽然代码多一点，但逻辑很清洗。而 class 只是映射 sql 逻辑成一个面向对象的 object，通过操作 object 来操作 sql。

session 是抽象出来的概念，实质关键是用来处理链接问题。建议用 sqlalcehmy 而不是 flask-sqlalchemy，因为解耦方便，组件化复用也可行，而不是跟 flask 耦合在一起。sqlalchemy 可以用 session_scope，create_engine 自己写个连接方法来处理，虽然入手肯定是没 flask-sqlalchemy 那么方便，但也是一次编写多几行代码，终身使用了。另外 peewee 是没有处理这个问题的，看起来更简单但不懂用埋了坑。peewee 和 flask-sqlalchemy 一样，也是 Model.select 这种形式的，但没有自动关闭连接。因此，对于长期运行的任务，队列等，某些数据库由于太长时间接受到请求就会直接中断，因此 peewee 在这种情况会出现 client 报错的原因，因为 timeout 了。peewee 的 issues 的官方给出解决方案竟然是 conn.close()这种东西，这在涉及 import/复杂业务容易出现单个 instance 里过早关闭的问题，感觉就像一不小心就变野指针，是个 bad design。

@shimomiaizo #25 原来如此，的确想想我们的整体设计水平是在人家之下。定居那个不重要，其实我怕定居这种玩意，我只想出去找一下工作机会，如果有的话，我是单纯喜欢到处跑接触不同东西的。虽说我现在做后端这一块，现在已经是我第二个领域了。不过哪怕还年轻，不过去念书拿学位代价的确太高了，考虑到放弃目前工作腾空几年，将丧失目前职位这几年可能是最快的发展阶段，可能念完了设计从 0 开始，而在现在的领域也归 0 了。

我所在公司里面的设计屈指可数。不过我一般是把大部分产品当傻子看，哈哈……那些名牌大学硕士毕业出来做产品，画个流程图都乱七八糟，组织能力也不行，逻辑也不慎密，尤其在 IT 公司，在尝试结合科技和产品两个方面时，听那些负责产品的说话会感到非常尴尬，因为他们并不懂得技术，设计上缺乏实际得表达能力（出稿原型图，交互方面得组织），只有一张嘴，所以实际一个项目流程十分颠簸。而项目经理则通常是一个经验丰富，技术和管理都出色的人担任，所以通常出篓子都是设计，产品那边上游出问题。具体设计给我的印象是，非常忙，感觉就是很惨，通常做技术的 6 点多的就下班走人了，而设计还在不停地做。不过设计往前端发展其实也是条路，前端 + 设计 + 产品其实是一条路。而后端这边一般所谓全栈则是后端 + 前端，不过经验上觉得，设计 + 产品 配 前端 + 后端是最节省沟通成本的。

snapshot 技术不会耗费很多硬盘，第一次完整备份之后它只会保存增量部分。但秒级备份用的不是 snapshot，它用的是日志，通过还原点 + 日志方式恢复。参考数据库。这种技术存在很久了。如有错请指出。

@parkcg 学 AI 是个人兴趣还是工作？工作尽快找家第一梯队公司进入，现在已经开始落地了。设计嘛，你也看到，虽然看起来一片惨淡，但 AI 算法和工程两个层面裂缝很大，现在行业还没到弥补这个裂缝的时候，目前几乎每个客户都需要大量人力物力支撑才可以发挥出 AI 的威力。相比之下设计所见即所得。

@IvanID 谢谢分享，这够详细的。我身边也见过一些前端 X 设计的，也经常和产品打交道。我在想设计师往产品和前端扩展应该是很不错的方向，每次看到产品、设计和前端在各自指点江山经常搞得一团糟。产品不懂设计，拿 axure 画个丑陋的设计稿出来，然后告诉设计，你把它转换成设计吧。设计画好稿后，经常不是完整的图，而是不同组件都画一个，然后前端做出来后，产品说不是这种感觉，或者说还要让后端写个程序跑起来先看看。而且交互方案一般由产品出，然而实际上很多产品缺乏文档能力，也缺乏设计能力，结果出来效果很笨拙。那些懂设计能用工具快速表达自己观念，并且画出交互设计图的产品根本不会存在这种问题。哪怕那个产品沟通能力比较好，也常常会如此。

@learnshare @rabbbit 谢谢两位，你们的方法我都做个 demo 试一下，我惊讶地发现现在的绘画板是配纸的，然后直接录入电脑。

@learnshare 交互设计可能迟点，不过说到 => 排版 /布局 /颜色，这方面我打算是上教材或课程看。我的理解是设计出图，给前端，然后就轮到组件库部分了，不过代码部分不担心。Good，我有思路了，所以 1. 先看这方面的设计理论，2. 然后配合 rabbit 所说的设计软件 ，3. 最后是前端实现就能构成最小完整单元了。Thanks。

@rabbbit 是的，那就是属于 UI 设计。那绘画板买得有点鲁莽了，我先试试。谢谢这么仔细的回答。

@rabbbit 谢谢！公司 UI 也是拿 dribble 的，好像大家都在用它做自己的作品集，二次元貌似是 pixel 的比较多。我比较喜欢欧美类的，二次元不是我的菜，不过实用层面上，我想首要是拿来做设计。画板买了个影拓 PTH660KTF，已经再路上了。之前尝试过用铅笔和纸，发现笔的选择，纸的不同对画出来的效果影响太大了（德国那种忘了什么牌子蓝色的铅笔，纸是复印纸，但好像还有好多其他要求，自己画的效果不理想，也找不到人指点一下，所以就暂时搁置了），现在是直接入个画板先乱画一番。

@fiht #5 你好，我并不需要鸡血，需要的是建议。我的行动力一点都不差。可能你去找个迷茫的学生，说就是干，他们还会谢谢你，然而我不会。因为你除了第一点之外，其余都是都在 judge 我，下面再质问我，最后再来一个 wild guess，你是不是学生？我建议去学学现代礼仪课程。你有什么想法是你的自由，但我提个问题不是让你来点评我的。我的提问不欢迎你，不管你什么水平是设计菜鸟还是大师，一律 blocked。

@boa2005 #4 你是对的，所以我不打算如你所言那样切入设计。现在编程工作很轻松，而且自己写代码收入大概比设计高多了（如果我现在是做设计而不是程序员）。不过我相对于天天看论文研究算法，我还是对设计更感兴趣，或许人人都往机器学习和区块链跑，但身在其中，却倒觉得并不是那么有吸引力。

@2Go #3 Me too! 那种男性逻辑动物，女性感性得要死得刻板印象真要不得。

@govizlora 谢谢这么深入的思考和回答。

1.2.我拿起工具完全没有思路。我找过一些外国的教程看，看起来很浅显，一开始让你自由发挥去尝试用不用的方法和风格创作，跑遍各个应用领域，然后再深入到底是什么造成了差别，为什么效果不一样。然后会从线条各个细分方面深入该如何表现。手绘完全是个人意愿吧，设计之外我对绘画很感兴趣，同时对于设计也算一个基础。目前不急着等它吃饭，所以可以慢慢深入。
3.4.技能学会了，我是想探索一下使用场景。不过还没丧失理智，最好是跨界结合两者，想看一下有没有现有的方案。比如有些人会分享出国做程序员，有的人会分享自己做外包，有的人远程，或者有的人把自己的作品挂到素材网站上买，记得我第一个博客就是购买一个设计然后自己加代码改造的。这都是些现成的方案，如果没有，还需探索探索。
5. 这是一个有趣的方向，让我再想想。

@cfans1993 #1 Thanks，你的回答让我找到了相关的基础课。

感觉 UI 好乱，还弹自家广告 “你写书单，雨雀买单”

谢谢！ + 1

很好很好，谢谢楼主，老早在愿望单了，+1 成功

一股欧洲要垮的样子......真的一日不如一日

按照经验, 测试是必须的, 但可以后面写。然而文档是最重要的, 文档驱动能很好地限制产品, 可靠地传达产品设计思路。那才是消耗最大的地方。现实中 TDD 带来的一点优点, 远远不如项目管理的重要性。我宁愿代码是避免多重继承的, 或是糟糕变量名又多重封装的, 这些比测试更重要。不然协作成本远远高出质量成本。有少量的质量问题通常也可以接受。