作为一个程序员，我们平时关注的关于管理方面的知识，最初可能是设计模式，管理的是某一个需求的复杂度，慢慢的，我们会开始关注领域划分，DDD，业务建模等，这些管理的是系统的复杂度，再后来，事情的复杂度逐渐进化到我们个人无法处理了，我们就需要团队合作了，这里管理的就是项目复杂度。
其实这三者是自始至终都会存在且相互关联的，很多理念也很相似，只是我们需要逐渐的参与实际工作才会一步步认知到这种复杂度。
关于设计模式和领域驱动设计，我之前的博客都有总结过一些我看过的书和具体的实践，这次结合亲身的体验与《知行》这本书，总结一下项目管理中的一些方法论。
最近工作上需要实现一个关系图谱，其中图中的节点布局需要用到力导向布局，于是就对其中涉及到的力导向算法产生了兴趣，就去研究了一下。
力导向绘图 (Force-directed graph drawing)可以用于描述关系图的结点之间的关系，把结点分布到画布上合理的位置，比如描述企业之间的关系，社交网络中的人际关系等。
最近在搭建自己的微信公众号机器人后台，用户向公众号发送小消息后，会被微信的服务端转发到自己设置的服务器，一开始我们可以选择明文模式，但是为了安全考虑，还是会开启安全模式，此模式下，所有的消息会被整体加密，我们需要在服务端解密，而微信官方文档写的不好，也没有nodejs版本的示例代码，于是我结合实例代码做了一版express的插件，记录一下:
程序员掌握的技术叫做信息技术，目的是为了快速的收集和处理信息，那么为什么这个技术重要呢？了解这个问题，其实也能明白AI到底给我们带来了什么
最近尝试实现了下AVL树，发现这玩意写起来还是很多细节的，搞了半天，所以就在这里记录下。
AVL树就是平衡二叉检索树，一方面它是BST，即二叉检索树，一方面它是平衡的，也就是任何一个节点为根结点的子树的左子树和右子树的高度差不到1。
业务领域的划分也要做到高内聚，低耦合，最少知识原则，如果每个业务领域需要知道很多其他业务领域的知识，那么其实还是耦合的
接触到这个算法是因为看到了一个题目，叫做素数伴侣。就是说给你你串数字，从中选择两个数字相加，如果他们的和是个素数，那么这一对叫做素数伴侣。然后我们需要找到这串数字中最多能找到多少对素数伴侣。
这个问题的解法首先是把数字分为两部分，一部分是偶数，一部分是奇数，因为两个偶数相加或者两个奇数相加一定还是偶数，不可能是素数。
于是这个问题就变成了分别从偶数中选一个，然后从奇数中选一个，看看最多选出多少对相加为素数。这个问题就用到了匈牙利算法。
匈牙利算法主要用于解决一些与二分图匹配有关的问题，所以我们先来了解一下二分图。
之前一篇博客讲过React的更新过程，不过在那个博客中，任务调度使用的是浏览器的requestIdleCallback，而实际上React使用的自己实现的一个任务调度器，我们这次就开分析一下它的源码，以及React为什么要自己实现任务调度器。
本文基于React仓库中的16.18.6分支进行解读。
最近在leetcode上遇到了几个问题都是采用二分法来解决的，总结了一下其中的规律，简单来说，如果是要从有界区间中寻找符合条件的最大值或者最小值，可以考虑采用二分法，不过不是基础的二分法，而是不断寻找左侧边界或者右侧边界的二分法。