编程与软件工程teamten.com
Norris 数：程序规模会撞上的墙
Norris Numbers – Walls you hit in program size (2014)
2014 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章提出“Norris 数字”的概念：程序员能驾驭的代码规模存在一系列天花板（约 1K、10K、50K、100K 行等），每突破一档都需要新的组织技巧和纪律。作者总结了多年编程中撞墙与突破的经验，并强调“绝不添加现在不需要的功能”等原则。
为什么经久不衰：代码规模增长带来的复杂度墙是每个程序员的必经之路，这些经验性数字和应对方法多年来反复被验证，至今仍是软件组织能力的实用指南。
HN 评论精选
这些规模墙早已是行业共识，突破每一档都需要相应的工程技巧，GitHub 上大量项目正死在这些临界点上。
如果他在 2011 年才有这个认识，那已经算晚的了——新手程序员 1K 到 2K 行的上限早已是公认的事实。要突破它需要一些行业技巧：结构化编程和避免全局作用域能让你到 1 万行以上；超过 5 万行就需要版本控制、命名规范、模块化，最好还有高层文档；到了几十万行，要么是单个程序员一生的成就，要么就是团队协作，需要更多基础设施支撑。在 GitHub 上浏览开源项目就能看到这些临界点——很多项目正是在这些规模上被放弃，原因往往是不懂如何组织更大的项目，或者因无人使用而失去动力。
jacquesm查看英文原文
If he had that insight in 2011 then he was pretty late to the party. By then the 1K to 2K line limit for 'beginner programmers' was very well established. To go beyond that you need a few tricks of the trade, mostly structured programming and avoiding global scope will get you to 10K and up. After 50K or so you will need even more tricks: version control will become a must, naming conventions matter and you're probably well into modularization territory. Some actual high level documentation would also not be a bad idea. By the time you hit 100's of thousands of lines you are probably looking at a life-time's worth of achievement by a single programmer, or more likely you are looking at teamwork. And so you'll need yet more infrastructure around your project to keep it afloat. You can see quite a bit of this at work when you browse through open source repositories at github, those are roughly the points at which plenty of projects and up being abandoned, as often as not through lack of insight in how to organize a larger project as through the demotivation that comes from lack of adoption.
好开发者的核心是代码组织能力，但行业对它的重视远不及算法，面试导向也加剧了这种偏差。
我觉得这个观点有些天真，虽然作者也略有提及。新手往往用单体方式写代码，这种做法在大型代码库上会严重失效。作为资深开发者，我认识到成为好开发者最重要的能力之一是组织能力。遗憾的是，代码库的组织方法——命名、可变状态、模块化、内聚与耦合等——在行业中的发展和理解程度远不如应有的水平。虽然掌握算法很重要，但我有时怀疑我们那种考察现场背算法的面试流程，是否把软件开发的重点带偏了。
gmoes查看英文原文
I feel that there is some naiveté in this perspective, although the OP does touch on it somewhat. A novice most likely would write their code in a very monolithic fashion. That same approach fails significantly with larger code bases. As a seasoned developer I have come to realize that one of the most important things to be a good developer is organizational skills. Unfortunately it seems that ways to organize code bases, including things like naming, mutable state, modularization, cohesion/coupling, etc., are not as well developed or understood in general in our industry as they should be. While understanding and knowing the right algorithms is important. I sometimes wonder if our emphasis on the knowing algorithms off the top of your head interviewing process contributes to putting the emphasis on the wrong things in software development.
克制地拒绝添加非必需代码，反而能带来近乎天才的效果。
“绝对拒绝添加任何功能或任何一行代码，除非你现在就需要它，而且非常需要。”随着年纪增长，我越来越看到这条规则的价值。虽然听起来只是消极的克制，但它能产生近乎天才般的效果。
montrose查看英文原文
"Absolutely refuse to add any feature or line of code unless you need it right now, and need it badly." As I've gotten older I've seen the value of this rule. Though it sounds merely negative, it can produce effects that seem little short of genius.
用更强大的语言和库，可以用更少的代码做更多的事，从而推迟撞墙。
这里真正有趣的推论是：无论你处于哪个水平，都应该尽量使用表达能力最强的语言，因为能用更少的代码完成更多的事。几个月前我对 Google Maps 不再支持显示其他服务器的 KMZ 感到失望，打算自己做一个替代品。最后我发现一个 JS 库（加一个插件）让我用大约 10 行 JS 就实现了所需功能。这更多是善用库和公共瓦片服务器的力量，但仍然印证了我的观点。
npsimons查看英文原文
The real interesting corollary here is that no matter what level you are at, you will probably want to leverage a language that's as powerful as possible, since you will be able to accomplish more with less lines of code[1]. A few months back, I expressed disappointment with Google Maps' dropping of support for displaying KMZs from other servers, and my intent to put together a replacement. When I finally got around to it, I found a JS library[2] (plus plugin[3]) that allowed me to replicate what I needed in about 10 lines of JS[4]. Of course, this is more the power of leveraging a library (and public tile servers), but I think it's still instructive to my point. [1] - http://www.paulgraham.com/power.html [2] - http://leafletjs.com/ [3] - https://github.com/mpetazzoni/leaflet-gpx [4] - http://hardcorehackers.com/~npsimons/photos/2014/07-13:%20Owens%20Point/gpstrack.html
历次讨论
同类还值得读
开源应用架构
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编辑精选