编程与软件工程johndcook.com
组织复杂性是软件开发中最重要的技能
Organizing complexity is the most important skill in software development
2015 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
John D. Cook 引述 James Hague 的观点：软件开发中最重要的技能不是算法奇技，而是组织能力——防止一堆功能在自身复杂度下崩塌。真实的大型系统里很少有什么高深的数据结构或算法主导一切，更多的是状态跟踪、特殊分支处理、以及让各部分正确交互；而组织能力难以在一小时课程或博文里展示，所以大家转而教授和写作算法。
为什么经久不衰：它点破了多数真实项目的痛点所在：难的不是写出巧妙算法，而是控制复杂度；这一判断在十年后的今天依然适用，也解释了为什么面试和教学仍偏重算法。
HN 评论精选
亲身经历佐证：重整复杂度能带来数量级的效率提升，但这种能力难以面试考察。
这太对了。我曾把 6 万行 VBScript 的经典 ASP 代码改写成约 2 万行 Python/Django（含模板），还加了一堆旧代码库根本不可能实现的功能。工作从地狱般（新功能都加不了）变得几乎无聊（没多少事可做了）。于是我做了些机器来自动化数据录入，事情更无聊了。可惜似乎没有办法在面试中考察这种能力，我们只能继续用“白板写算法”这种完全不能反映真实能力的题。
msandford查看英文原文
This is incredibly true. I once turned 60kLoC of classic ASP in VBScript into about 20kLoC of python/django including templates. And added a bunch of features that would have been impossible on the old code-base. It turned the job from hellish (features were impossible to add) to very nearly boring (there wasn't much to do anymore). So with this newfound freedom I built some machines to automate the data entry and once that got rolling the job got even more boring. Because it was a small company with a very long learning curve the owner didn't let people go, but instead kept them on so that he didn't have to hire and train new people as growth accelerated. But with all the automation some slack found its way into the system and problems that had normally required me to stop working on my normal job and help put out fires now got handled by people who weren't stretched a little too thin. Sadly there's (seemingly) no way to interview people for this ability so we're stuck with the standard "write some algorithm on a whiteboard" type problems that are in no way indicative of real world capabilities.
组织与巧妙并非对立，而是在可读性和精简之间反复寻找平衡。
“最重要的技能是防止一堆功能在自身复杂度下崩塌”——同意。“很少有什么棘手的数据结构或算法笼罩一切”——同意，但是……为了做好组织，你迟早还是得变得聪明（用上棘手的数据结构或算法）。我构建大型复杂系统的方式一直是：1. 加代码；2. 加代码；3. 加代码；4. 天啊，我干了什么；5. 重构；6. 合并相似部分；7. 用参数驱动模块泛化；8. 代码还是太多！用点巧妙手法优化第 7 步；9. 回到第 1 步。两年后：这套巧妙的参数驱动多层嵌套流程到底是干嘛的？我为什么不直接写？对我来说，组织复杂代码始终是可读性与巧妙性之间的微妙平衡：删得不够，代码难以导航；删得太多，难以理解。组织 + 巧妙 + 平衡 = 长期可维护性。
edw519查看英文原文
the number one most important skill is how to keep a tangle of features from collapsing under the weight of its own complexity Agreed. very rarely is there some tricky data structure or algorithm that casts a looming shadow over everything else Agreed, BUT... In order to organize, sooner or later, you will have to get clever (with tricky data structures or algorithms). How I have always built something big and/or complex: 1. Add lines of code. 2. Add lines of code. 3. Add lines of code. 4. Holy shit! What have I done? 5. Refactor. 6. Combine similar sections. 7. Genericize with parameter-driven modules. 8. Still too many lines of code! Optimize Step #7 with something clever. 9. Go to Step 1. 2 years later: What the hell was this clever parameter-driven multi-nested process for? Why didn't I just code it straight up? For me, organizing complex code has always been a delicate balance between readibility and cleverness. Don't remove enough lines of code and it's too much to navigate. Remove too many and it's too much to comprehend. Organization + Cleverness + Balance = Long Term Maintainability
微观编码能力很快见顶，而宏观的组织与整合能力可以长期持续提升。
我最近也在想类似的事：我作为开发者到底有没有进步？我用的语言和框架大多只有几年历史，或者被大幅改动重造，早期职业生涯的陈述性知识大多没用了。但我的能力提升了吗？结论是：我在微观层面（单个方法或算法）的编码能力大概在职业头两三年后就停止进步了，把 24 岁的我叫来处理一个狭窄问题，表现大概和现在差不多。但 24 岁的我在宏观层面很挣扎：不知道怎么把零件组合成整体，只会退回单例之类的少数模式，常有痛苦的日子在理自己的代码、搞不清组件 X 怎么和 Y 通信。这种宏观能力确实会随时间持续提升，随着你接触更多更好的组件集成与依赖管理范式。
stupidcar查看英文原文
I was thinking along similar lines the other day. I was thinking about whether I've actually improved as a software developer over my career. It occurred to me that most of the languages and frameworks I use are either less than a few years old, or have been changed or reinvented in substantial ways. As such, not much of the declarative knowledge from my early career is of much use. But have my skills improved? I came to conclusion that my ability to code on the micro scale, e.g. at the level of an individual method or algorithm, probably stopped improving after 2-3 years of professional experience. I think you could take the 24-year-old me, ask him to work on a narrow problem, and he'd do about as well as I would now. But where the 24-year-old me struggled a lot was at the macro scale. He didn't know how to compose those individual pieces into a cohesive hole, and instead fell back on a handful of patterns like singletons. I remember horrible days trying to unravel my own code and figure out how component X was going to communicate with component Y, and the result was often a mess. I think this macro-scale ability really does improve continuously over time, as you are exposed to more and better patterns for integrating components and managing dependencies.
即使在算法为重的领域，代码组织的重要性也不亚于算法本身。
我做数学密集的工程软件，搞懂某个巧妙算法怎么工作可能要花一个月，但我觉得组织代码的重要性和它不相上下。我曾把一些庞大巧妙的算法整个丢弃，因为找到了替我实现、而且比我写得更好的库。
lopmotr查看英文原文
I work on math-heavy engineering software where it can take a month to learn how some clever algorithm works and I'd say organizing the code is still equally as important as that. I've thrown away big clever algorithms when I found libraries that did it for me and did it better than I could.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选