……我一开始，用汇编语言编写自己的操作系统。我甚至还有1987年我第一个工程项目的手册（包括操作系统代码）[0]。它能运行，但非常原始。我现在无法想象用汇编语言写操作系统。我很高兴有人用C语言（或者其他语言）替我做了这件事。所以，我现在的“起点”是拥有一个高质量的并行操作系统，带有开发者SDK（再次强调，是其他人完成了这些工作），编译器和链接器（感谢克里斯·拉特纳等人），等等。对于我自己的项目，我使用了很多依赖项。不同之处在于，我大部分的依赖项都是自己编写的。这些是独立的模块，每个模块都有自己的项目生命周期、文档、测试等。即使没有人会使用它们，我仍然会将它们发布在GitHub上，作为支持的开源项目，因为这意味着当我在我自己的聚合项目中使用它们时，我不需要担心它们。基本上是“分而治之”。大的东西是由小的东西组成的。……
源讨论被代码淹没：日益增长的代码库问题原帖 73 条评论 · 导入时统计把你的经验，加入这段讨论。
基本上就是「分而治之」。大的东西是由小的东西组成的。 我认为这并不是有争议的部分，也不是困难的结论，困难之处在于如何具体实现。
完整原文> 事实上，Jared Diamond 认为我们其实有点笨。 请不要让这个人得逞，因为实际上有数以百万计的受过训练的历史学家你可以去咨询。
完整原文据我了解，这是苹果公司进行开发的方式。所有的东西都是自己开发的，而不是依赖于公司外部的各种依赖。 我喜欢苹果的产品，但就是无法接受他们的封闭生态系统。不过，为了达到他们那样的质量，可能确实需要这个花园。 我个人很喜欢几乎没有外部依赖、有扎实测试和完整、最新文档的想法。我需要努力提高自己的纪律性和动力去做到这一点。
完整原文> 大型代码库是不可避免的。 我强烈不同意。新的代码库可能建立在大型框架和基础设施代码之上，但源代码仓库应该比以前更紧密、更专注于业务。 但它们往往是臃肿的怪物，充满了为了简历而写的架构师式废话，或者为了适应最新流行框架的要求而扭曲的代码。 提前为这篇冗长的抱怨道歉，但这个问题已经让我愤怒了好几个星期，因为我一直在处理客户制造的深陷其中的混乱，比如为一个网页表单手写了一惊人的三兆字节的源代码。只有一个！ 尤其是在现代网络框架的时代，我们可以避免大多数旧系统（如 C 或 C++）的「仪式」，比如仅仅调用数据库就需要几页的繁琐样板代码…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。