Software development doesn't scale
Adding more people to a software project doesn't necessarily improve productivity this is from the mythical man month or known as Brook's Law
–
Adding people to a project makes it later or slower due to the communication needed to get up to speed.
This category is for ideas on making software development scale from 1 person to a couple. To a couple to many.
Reading code is harder than writing code. Starting from blank is easier than modifying an existing code base. This category is to explore ideas that scale software development so large teams can be formed that work on the same software system.
Imagine we could define behaviour or code about an attribute of a large system in isolation from other concerns and have them tied together automatically into a whole.
实际上是一个非常重要的类别。在我的脑海里，有几种方法：
(A) 编写小的高度可重用和经过测试的模块（当它们很小时，其他人很容易理解）
(B) 与团队一起重写（复杂的概念系统完成后，一起从头重写）
还有其他启发式方法，例如 SOLID，我从朋友那里听说的，在这里绝对可以提供帮助，但无助于促进开发遗留代码，正如它所暗示的那样，遗留代码必须被重构为许多小的位（库），然后再次组合，这不是一个小壮举。
A very important category, actually. Off-top of my head, there are a few approaches:
(A) writing small highly reusable and tested modules (when they are small, others can easily understand)
(B) rewriting with a team (after the complex concept system is done, rewrite from scratch together)
There are other heuristics, like the SOLID, that I've heard of from a friend, can definitely help here, but it doesn't help with boosting development of legacy code, as what it implies is that the legacy code would have to be refactored into lots of small bits (libraries), and then combined again, which is not a small feat.
在大多数开源项目中，有人做大部分工作，理解代码并做出最大贡献。
然后是一群小的贡献者，他们贡献了很少的修复。
我认为问题的一部分是使代码易于理解。 Ruby on Rails 和 Django 提供了一种机制来完成大多数事情，从而使您达到目标。
我的问题是成熟的代码库很难理解和阅读。参考实现或快乐路径被各种异常或添加的功能问题所污染
Postgres、Linux 和 nginx 等网络服务器的基石都很难理解和阅读，因为它们的功能非常丰富。只见树木不见森林。
我避免使用没有良好文档的开源库 - 我希望在自述文件或文档中提供每个 API 和示例代码的示例。
In most open source projects there is someone who does most of the work, understands the code and contributes the most.
Then there are a group of small contributors who contribute little fixes.
I think part of the problem is making code understandable. Ruby on Rails and Django get you part way there by providing a mechanism to accomplish most things.
The problem I have is that mature codebases are very hard to understand and read. The reference implementation or happy path is polluted by all sorts of exceptions or added feature concerns
The cornerstones of software such as Postgres, Linux and web servers like nginx are all hard to understand and read because they are so feature packed. You cannot see the forest for the trees.
I avoid using open source libraries that dont have good documentation - I expect examples of each API and example code in the README or in the documentation.
这是关于复杂性。任何复杂的系统都有这些问题。解决方案是模块化、通用性、可组合性、可重用性。我们需要共同的标准，我们需要真实且经过验证的解决方案来成为这些标准和共同性的基础。这是一个渐进的过程。 但是，imo，硬币还有另一面。这是关于人和他们的工作文化。军团将我们推向了非常狭窄的角色，这促使软件高度模块化。在极端情况下，它也不健康。需要有更多的架构师，更多的有远见的人可以跨部门看到。这是一个重要的快乐平衡，但现在所有行业的千斤顶都不够，而且许多人都遵循旧模式类型的人。是以他们自己的形象编写软件的人。
It's about complexity. Any complex system has those problems. Solution is modularity, commonality, composability, reusability. We need common standards, we need true and tried solutions to become basis for those standards and commonality. It's an incremental process. But, imo, there's another side of the coin. It's about people and about their work culture. The corps are driving us into very narrow roles, and that is driving software to be highly modularized. At extreme, it's not healthy either. There needs to be more architects, more visionaries that can see across divisions. It's a happy Ballance that matters, but right now there's not enough of jacks of all trades and to many of the follow the old pattern type of people. It's the people that write software, in their own image.
我同意你的观点，复杂性是一个很大的因素。
大多数代码库一开始很简单，但后来变得混乱不堪，变成了意大利面条。
我希望一切都读起来像伪代码或参考实现。换句话说，它是如此简单，它是可读的。
问题在于代码增加了特征，而这些特征在核心算法中的命名空间很差。
一个btree其实很简单！但是数据库需要许多使 btree 变得复杂的功能，因为它必须处理锁定、安全性等。
我对分层问题语言的想法是将功能彼此分开并自动将代码分层在一起。就像一个智能的子类化。但是对于自动代码增加。
I agree with you complexity is a huge factor.
Most codebases start simple but then become over encumbered with lots of mess and become spaghetti.
I want everything to read like psuedocode or a reference implementation. In other words it is so simple it is readable.
The problem is that code accretes features and those features are poorly namespaced from the core algorithm.
A btree is actually quite simple! But a database needs lots of features that make a btree complicated because it has to handle locking, security etc.
My idea for a layered problem language is to separate features from each other and layer the code together automatically. Like an intelligent subclassing. But for automatic code accretion.