汉得数字平台上海汉得信息技术股份有限公司
07/06 09:49
点赞点赞
06/24 09:29
现状 != 原因。
复杂不是问题,建100层楼对于建筑师也不简单。但建筑的成熟度和结果可见度,比(当前)的软件好得多。建筑多少年历史多少人力参与过,软件才多少年,前近空间大得多。
So,目标方向很明确,“成熟度”和”结果可度量性“。
06/24 09:17
这么好的文章,必须点赞+关注
06/23 14:19
写得好😀
06/21 16:26
深度好文,例子很形象。
06/21 02:33
“复杂度高的代码一定不是好代码”不见得:快速排序和冒泡排序算法都能实现完全相同的功能,而快速排序复杂度远高于冒泡排序。但在很多(甚至是大多数)场景下,快速排序明显比冒泡排序更好——如今基本所有 C/C++ 标注库里的 sort 实现均使用快速排序。
06/20 15:21
说了等于没说
06/20 11:22
写得真好。《人月神话》里也有类似的观点。复杂度不会减少,但可以转移。比如微服务架构其实是更复杂了,但如果微服务平台是现成的,代码开发人员只管自己的业务代码,则在他的局部视角来看,DevOps的复杂度下降了;但如果他只管开发不管运维,则运用微服务造成复杂度上升了。
06/19 17:02
我们知道是这样,确无法改变
回复 @
{{emojiItem.symbol}}
返回顶部
顶部