处理大型项目时保持一致
可能有点偏离主题，但我真的很想从具有不同经验和背景的其他人那里了解这一点。
您如何跟踪您的大型项目？ 你使用颠覆吗？ EER 模型？ 你写笔记吗？ 您所有的信心都在于 phpdoc 吗？ 您使用哪种框架，遵循哪种设计模式？ 我知道有很多问题，我不希望您回答所有问题，只需总结您最想强调的内容即可。
就我个人而言，我使用 subversion 进行源代码控制、phpdoc、为每个模型/控制器等写下个人注释，并且我几乎总是遵循 MVC 模式。
祝你度过美好而神奇的一天！ ;-)
Probably a bit off topic question, but it's something I'm really interested in getting to know from other people with different experience and backgrounds.
How do you keep track of your huge projects? Do you use subversion? EER-models? Do you write notes? Does all your faith lie in phpdoc? Which framework do you use, and which design pattern do you follow? A lot of questions, I know, and I don't expect you to answer ALL of them, just summarize whatever you want to emphasize the most.
Personally, I use subversion for source control, phpdoc, writing down personal notes for each model/controller etc and I'm almost always following the MVC-pattern.
Have a fantastic and automagic day! ;-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议使用最适合您现有人员的工具，以及可能最难管理的部分。
如果您有很多需求，请使用可以很好地跟踪需求的工具。
如果您有很多简单的一次性项目，也许简单的项目跟踪效果很好。
I would recommend on using the tools that work best for the people that you have, and the parts that are likely to be the most difficult to manage.
If you have a lot of requirements, use a tool which tracks requirements well.
If you have a lot of simple one-off projects, maybe simple project tracking works well.
记录项目（尤其是高级项目）的一个好方法是拥有一个 wiki。 显然，成功完全取决于你的队友。 如果他们讨厌写散文，那么整个想法从一开始就基本上注定要失败。
但如果有合适的人，它确实可以得到回报。 几个带有几个图表的 wiki 页面可以发挥很大的作用，并且通常比任何 UML 图和现有的东西更具表现力（当然，两者的组合甚至更好:-) 如果您可以让您的测试人员以及其他人的加入，你就有了一个良好的开端。 多多益善。
您在帖子中忘记提及的一件事是错误跟踪器。 这绝对是必备的，我相信乔尔有一些很好的建议，告诉你哪个是最好的软件选择；）
A great way to document your project (especially the high level stuff) is to have a wiki. The success of that obviously depends entirely on your teammates. If they hate writing prose then the whole idea is basically doomed from the start.
But given the right people it can really pay off. A few wiki pages with a couple of diagrams can go a long way and oftentimes be way more expressive than any UML diagram and what-have-you (of course, the combination of both is even better :-) If you can get your testers and other people to join in, you're off to a good start. The more, the merrier.
One thing you forgot to mention in your post is a bug tracker. That is an absolute must-have, I am sure Joel has some good tips on which is the best software choice there ;)
您应该使用错误跟踪软件来记录每个问题的解决方式并将其与您的 Subversion 存储库联系起来，以便您可以看到生成签入的问题，反之亦然。 我们自己使用Fogbugz。
You should a bug tracking software to record how each issue was resolve and tie it to your Subversion Repository so that you can see the issue that generated the check-in and the vice-versa. We use Fogbugz ourselves.