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.