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 и пример кода будут в README или в документации.
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.
Я согласен с вами, что сложность - огромный фактор.
Большинство кодовых баз сначала становятся простыми, но затем становятся перегруженными большим количеством беспорядка и превращаются в спагетти.
Я хочу, чтобы все читалось как псевдокод или эталонная реализация. Другими словами, он настолько прост, что его можно читать.
Проблема в том, что код наращивает функции, и эти функции плохо отделены пространством имен от основного алгоритма.
На самом деле 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.