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などのWebサーバーなどのソフトウェアの基礎は、機能が満載されているため、すべて理解して読むのが困難です。木々の森は見えません。
優れたドキュメントがないオープンソースライブラリの使用は避けています。READMEまたはドキュメントに各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.
それは複雑さについてです。どんな複雑なシステムにもこれらの問題があります。ソリューションは、モジュール性、共通性、構成可能性、再利用性です。私たちは共通の基準を必要としています。それらの基準と共通性の基礎となるためには、真の試行錯誤されたソリューションが必要です。これは段階的なプロセスです。 しかし、イモ、コインの別の側面があります。それは人々と彼らの労働文化についてです。軍団は私たちを非常に狭い役割に駆り立てており、それがソフトウェアを高度にモジュール化するように駆り立てています。極端な場合、それも健康的ではありません。より多くの建築家、部門を超えて見ることができるより多くの先見者が必要です。重要なのは幸せなバランスですが、今のところすべての取引のジャックが十分ではなく、多くの人にとって古いパターンタイプの人々に従います。自分のイメージでソフトウェアを書くのは人々です。
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.
複雑さが大きな要因であることに同意します。
ほとんどのコードベースは単純なものから始まりますが、その後、多くの混乱に悩まされ、スパゲッティになります。
擬似コードやリファレンス実装のようにすべてを読んでもらいたい。言い換えれば、それはとてもシンプルで読みやすいです。
問題は、コードが機能を追加し、それらの機能がコアアルゴリズムから名前空間化されていないことです。
Bツリーは実際には非常に単純です！しかし、データベースには、ロックやセキュリティなどを処理する必要があるため、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.