题记想写这篇文章，是因为在某平台看某用户的一篇文章，想了解一下作者的背景，进而看到其在一些回答中与评论者争吵的情况。其实技术水平高低本身是受很多情况影响的，评价一个人也不是一维的。事实上，没有任何标准可以真正的评价一个人。技术讨论和技术辩论是受欢迎的，因为大家技术水平不在一个等级而无法正常的讨论进而主动拒绝讨论本身也是可以接受的。黑一门技术，则显得狭隘了。
为了调解自己的思想，再一次阅读了《黑客与画家》“守口如瓶”这一章，并分享一些感悟。
自由的思考自由的思考，强调的是，不要轻易的被各种论断影响。我们需要去思考一个论点的论证逻辑，了解其论据是否足够充分。信息时代，我们每天都会从各种渠道接...
什么是广度与深度想要想做一名架构师的同学，大都会听到一句话：“一名架构师要有技术的广度与深度”。很多同学在跟hr交流的时候，或者跟领导、行业大佬交流的时候，也经常会听到这样的建议：“要做一名T/π型人才”。
那么，广度要怎么理解，深度又要怎么理解呢。我们掌握了一些知识或者信息，需要达到一个什么程度，算是覆盖了广度，或是达到了深度。
我个人的感受是，当我们对知识、信息达到了，
能够理解其中的原理与逻辑，同时能够自己进行复述，则算是达到了广度的覆盖
能够机遇已有的信息，思考其深层次的逻辑，举一反三的实践或思考总结，并能达到一定效果，则算是深度的掌握。
我们每天会浏览五花八门的信...
前言架构设计与编码，是为了解决问题，是一套解决方案。当我们在设计架构和代码开发的时候，有一份相对应的设计文档，可以有效且快速的让团队更好的理解在解决的问题，以及方案的设计思路。
为什么要写设计文档
要解决的问题是什么需要用文档先介绍清楚
有些问题使用一份设计文档描述思路已经足够
解决方案的选择（decision）是权衡的结果，我们不仅需要了解结果，也需要知道结果产生的原因，即权衡的过程。只有记录下权衡的过程，在后续偿还技术债的时候，才可以更方便的理解产生的原因或初衷，并有更充分的执行架构演进的依据
让团队成员对问题和设计有一个共识
设计文档核心内容基于以上原因，我们也可以推论出，设计文...
10倍的产品改进《从0到1》介绍了一款产品的推出，如果只是2-3倍的改进，可能可以在一开始吸引用户去使用。如果产品所属的市场价值极大，2-3倍的改进会引来一大群竞争者轻易的介入，这将使得产品在后续的迭代中疲于与其他竞争者斡旋，而丢失了让产品变得更好的目标。如果产品的市场价值有限，那么产品能带来的收益也有限，投入的成本也将有限，并很难再继续做大。事实上，有相当一部分产品的推出，比原来的产品带来的改进少于其带来的麻烦。这样的产品，基本很难吸引到用户。俞军提出的产品价值公式可以很好诠释这一点，即新产品价值 > 旧产品价值 + 迁移成本，这样的新产品才有可能成功。
一款产品想要在推出的时候...
持续更新关于python并行计算与异步计算的包，后续再根据篇章拆分。
Python 并行并行库threadingmultiprocessing
multiprocessing 中的一些问题问题
开启子进程的方法与问题 spawn相比fork会更耗时，但是fork在处理一个多线程的进程时可能会陷入死锁等问题。这是由于fork本身的机制造成的。这也使得在使用包的过程中常常遇到一些问题。
IO问题 fork本身会继承打开文件的描述符，所以对于多进程的处理，要留意IO处理带来的不良影响建议由于使用多进程更多是因为，CPython本身的GIL造成无法使用多个CPU核，而使用多进程的方式进行处理...
框架报错源码解析
exception 处理器
1234567891011121314151617181920212223242526272829303132# rest_framework.views 71-101def exception_handler(exc, context): """ Returns the response that should be used for any given exception. By default we handle the REST framework `APIException`, and...
在DRF业务逻辑实现篇中，提到关于使用Django框架编写业务逻辑的一些局限性以及可能的解决方案。当业务开始扩展的时候，渐渐发现，框架对复杂业务的支持能力明显不足，已经超出了使用service来处理的能力了。
当开始尝试使用DDD来进行模块与架构设计时，不仅要理解DDD是什么，同时需要去理解DDD在Django中应用的困难^1
一种有效的方法是，从serializers中封装domail_serializers，用来承担view中的业务逻辑执行，担任一个实体。view作为一个bounded context的存在，绑定多个serializers，完成一个业务逻辑的执行。
显然，DRF已经基...
本篇为阅读《敏捷软件开发：原则，模式与实践》后的读后感。主要阅读的是第二部分：敏捷设计。这本书的第一部分，关于敏捷开发中的测试驱动开发与重构，可以阅读其他专门的书籍。我阅读的是《重构，改善既有代码设计》。本书第三部分的案例，可自由选择是否阅读以加深理解。我自己更多的是结合自己遇到的问题，从书中描述找到问题的解决方案。
什么是敏捷设计软件越来越难维护软件在第一版本发布的时候，是软件设计最干净清晰的时候。随着复杂的需求与软件持续迭代，软件代码往往会在原来的设计上做各种hack以满足新的需求。
这系列的破坏设计的操作，会在后续的需求增加的过程中逐渐变得难以维护，而后的需求迭代速率将越来越慢。
...
Django Restful Framework Business LogicDjango Restful Framework
Restful APIDjango Restful Framework 提供了非常便利的方法序列化Restful API，并且提供了统一的数据返回格式（包括错误返回）。
SerializerSerializer 提供了数据序列化反序列的操作，并承担了validation的工作，validator有内置，也可以自主添加。
局限性我们在使用中也发现了一些局限性。这些局限，根本上是因为框架是基于Model去设计的。当我们遇到API由多个不同的Django Model...
GraphQL 与 RESTfulGraphQL
数据一次获取数据返回被封装在一个入口，一次请求
所见及所得想要获取什么数据，就定义相应的查询字段。
RESTful
明确资源间的关系
HTTP verb定义对资源的行为
API设计对于前后端分离架构，API成为了前后端间数据通信协议。当一个产品经理列出需求之后之后，前后端工程师设计领域模型，抽象需求与原型成为代码可以描述的对象。在实践中发现，大多数前端工程师会对页面进行建模，而后端工程师则对资源进行建模。于是会发现，前后端工程师对模型的定义会有些差别，即使我们在设计阶段有领域模型设计，我们也无法保障前端工程师能按照领域模型设计组件，这...
