如何构建大型应用程序 [英] How to build large applications

问题描述

我想我已经成为基本的编程（用于各种语言）相当不错。我可以写code的* **好线。我可以写的好的方法。我可以写的好的类。我可以写的好的组类。我可以写的好的小型或中型的应用程序。

我不知道但是如何建立一个的好的大型应用程序。特别是在多种技术涉及更可能参与与时间的情况下。说有一个大的web前端的一个项目，一个大型服务器后端连接到其他一些整合后端的最后一个庞大而复杂的数据库。哦，我已经参与了其中的一些应用程序，我可以建立一个我敢肯定。我不太确定但是，它可以有资格作为好。

我的问题是这样的一本书或阅读其他良好来源在那里我可以学到如何分配和组织code和数据一般大型项目的参考。例如，我会想的东西层非常严格的，或我会想封装它独立的单元来代替。我想尽量保持大部分的逻辑在同一个池中，还是应该为它添加我加入什么功能时，似乎是最合乎逻辑的只是分发。

我见过很多一般原理对这些问题（例如没有意大利面条code，肉丸code ...）并阅读讨论此事少数优秀的文章，但我从来没有遇到过一个源这将导致我到具体的实际知识。我意识到了问题的困难，所以我很高兴，只是听到其他人已经发现，以帮助他们在寻求此类知识的读物。

和往常一样，感谢您的答复。

  

****鉴于好code，这个词在这方面的好会不会被定义的界定的辩论性质（这意味着无论你认为它应该意味着）。

解决方案

作为程序员，我们愿意相信，我们都是聪明人，所以这是很难承认的东西太大和复杂，甚至想一次全部。但是对于一个大型的软件项目这是真的，你承认越早您的有限的脑容量并开始想出各种办法来简化问题，更好你会。

要实现的另一个主要的事情是，你会花大部分时间的更改现有code 。构建初始codeBase的仅仅是蜜月期 - 你需要在头脑里的想法来设计你的code是，6个月后你会坐在它前面试图解决一些问题，而无需线索如何这个特殊的模块工作，即使你自己写的。

那么，我们能做些什么？

最小耦合您的code的不相关的部分之间。 code会在你无法预见的方式随时间而改变 - 将有不熟悉的产品整合搅局者的问题，需求的变化 - 那些会引起纹波上的变化。如果你已经建立了稳定的接口和coded到他们，你可以让你在不影响使用的接口code那些改变的执行需要任何更改。你需要的花费时间和精力开发将经得起时间的考验接口 - 如果接口需要改变太多，你又回到了起点。

建立自动化测试，您可以使用进行回归测试。是的，这是一个很大的工作了前面。但是，这将在未来还清时，你可以做出改变，运行测试，并建立的它仍然有效的不知道那焦急的感觉，如果你提交你的最新的变化一切都会摔倒源代码控制。

裁员棘手的东西。时不时地，我看到一些聪明的C ++模板招，并认为，哇！这正是我的code的需求！但事实是，在下降的是如何阅读和容易理解的code成为经常不值得增加的通用性。如果你像我这样的自然倾向是尽量在一般的方式，尽可能地解决所有问题，你需要学会克制它，直到你真正跨越的需求的针对通用的解决方案来。如果的需求的出现，则可能需要重写一些code - 这没什么大不了的。

I think I've become quite good at the basics of programming (for a variety of languages). I can write a *good** line of code. I can write a good method. I can write a good class. I can write a good group of classes. I can write good small or medium application.

I do not however know how to build a good large application. Particularly in the case where multiple technologies are involved and more are likely to become involved with time. Say a project with a large web front-end, a large server back-end that connects to some other integration back-end and finally a large and complex database. Oh, I've been involved in a few of these applications and I could build one I'm sure. I'm not so sure however that it could qualify as "good".

My question is thus for a reference to a book or other good source of reading where I could learn how to distribute and organize code and data for general large projects. For example, would I want to layer things very strictly or would I want to encapsulate it independent units instead. Would I want to try to keep most of the logic in the same pool, or should it just be distributed as it seems most logical when adding whatever feature I'm adding.

I've seen lots of general principals on these issues (e.g. No spaghetti code, meatball code...) and read a few excellent articles that discuss the matter but I've never encountered a source which would lead me to concrete practical knowledge. I realize the difficultly of the question and so I'd be happy to just hear about the readings that others have found to help them in their quest for such knowledge.

As always, thank you for your replies.

****Given the debated nature of the definition of "good" code, the term "good" in this context won't be defined (it means whatever you think it ought to mean).

解决方案

As programmers, we like to believe we are smart people, so it's hard to admit that something is too big and complex to even think about all at once. But for a large-scale software project it's true, and the sooner you acknowledge your finite brain capacity and start coming up with ways to simplify the problem, the better off you'll be.

The other main thing to realise is that you will spend most of your time changing existing code. Building the initial codebase is just the honeymoon period -- you need to design your code with the idea in mind that, 6 months later you will be sitting in front of it trying to solve some problem without a clue how this particular module works, even though you wrote it yourself.

So, what can we do?

Minimise coupling between unrelated parts of your code. Code is going to change over time in ways you can't anticipate -- there will be showstopper problems integrating with unfamiliar products, requirements changes -- and those will cause ripple-on changes. If you have established stable interfaces and coded to them, you can make any changes you need in the implementation without those changes affecting code that uses the interface. You need to spend time and effort developing interfaces that will stand the test of time -- if an interface needs to change too, you're back to square one.

Establish automated tests that you can use for regression testing. Yes, it's a lot of work up front. But it will pay off in the future when you can make a change, run the tests, and establish that it still works without that anxious feeling of wondering if everything will fall over if you commit your latest change to source control.

Lay off the tricky stuff. Every now and then I see some clever C++ template trick and think, "Wow! That's just what my code needs!" But the truth is, the decrease in how readable and readily understandable the code becomes is often simply not worth the increased genericity. If you're someone like me whose natural inclination is to try to solve every problem in as general a manner as possible, you need to learn to restrain it until you actually come across the need for that general solution. If that need arises, you might have to rewrite some code -- it's no big deal.

这篇关于如何构建大型应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！