Start by defining the scope. Write a paragraph to a page and try to describe your website. A top-down approach would be to start thinking of functionality you'd like to implement and refining it by adding more detail.
A top-down approach (is also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes", these make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model. http://en.wikipedia.org/wiki/Top-down_and_bottom-up_design.
Again, the most important step is to be able to put your idea in words; before you can adequately do that, I wouldn't even consider starting to write one line of code.
A brief guide for a MVC architecture. The idea is tho help you remember ideas (while your brain is steaming code) and have documents for future programmers.
Design the database. Make an ER diagram. Put it in a document. Briefly describe reasons behind the design for the important issues (why you choose a polymorphic relation, why use this view, what selects you expect that are more trickey etc.). This will change as you code (and there is nothing you can do). Document the changes. To cope with the changes, use a versioning system for the database like rails migrations.
Design the structure of your website (sections, pages, links, page-flows etc.). Document it. (like: "the site 2 sections, this section is made of ..." etc.) Based on this make a document describing your controllers and views. ( "a controller for articles, with a list view, and article view, also edit and create views but just for admins" etc). Describe how you are going to enforce authentication and authorization (on controller and view level). Who is allowed where. Describe how you protect against the main web-attacks (xss, csrf) where required. (example: "i escape all my view variables using htmlentities for xss protection and ...")
Design your models and side functionality (sending emails, background jobs etc.). These will be the bulk of code. Document each and describe the main issues (for example how timezones are to be handled, how this certain model is to connect to the currency service, how that model is to parse and manipulate some crone file, what algoritm you shall use to decide top 5 articles, depending on your app.) Describe what libraries you use, how, and for what purposes (example: "we are to use curl to scrap SO and make rss feed") Describe how you protect against the main web-attacks where required (sql-injection, xss).
As you code, things change. Your knowledge about the discrete works of your system evolves and you start to improve the design based on the new found enlightenment. Document your changes.
A few thoughts from someone who loves abstractions.
Figure out what your websites will have in common. Once you have identified the main commonalities, look for frameworks or libraries that deal with as many of them as possible (besides filling your other criteria), such as the boilerplate DB code.
For the common features that you can't find any ready-to-use code (they always exist in customized websites) you'll have a chance to write a common library to be used across your websites yourself. This could be a template for your markup, a JavaScript library or a reusable server-side component, or all together.
Based on your description it sounds like you are enjoying great freedom in the creative process (versus getting a requirements spec handed to you and asked to implement it). I'd say don't over plan either, "just starting to code right away" is a lot of fun and not all bad. Experience will be your best friend, and by the time you reach website #100, you'll have lots of it. When building your second website, your experiences with the first one will help you avoid making some of the mistakes you made, and you'll discover new similarities that you did not anticipate in the planning phase. Just make sure to take the time, move the common code to a single library, and go back and edit your first website to use it. Do this a few times over and you will have learned lessons that are worth a lot.
发布评论
评论（3）
首先定义范围。在页面上写一个段落并尝试描述您的网站。自上而下的方法是开始考虑您想要实现的功能，并通过添加更多细节来完善它。
然而，还有许多其他方法。
http://en.wikipedia.org/wiki/Software_project_management#Software_development_process
再次，最重要的一步是能够用语言表达你的想法；在你能够充分做到这一点之前，我什至不会考虑开始编写一行代码。
Start by defining the scope. Write a paragraph to a page and try to describe your website. A top-down approach would be to start thinking of functionality you'd like to implement and refining it by adding more detail.
There are many other approaches, however.
http://en.wikipedia.org/wiki/Software_project_management#Software_development_process
Again, the most important step is to be able to put your idea in words; before you can adequately do that, I wouldn't even consider starting to write one line of code.
关于编码标准/结构/框架我推荐zend框架编码标准， MVC 结构，以及Zend 框架。
MVC 架构的简要指南。这个想法是帮助你记住想法（当你的大脑正在编写代码时）并为未来的程序员提供文档。
设计数据库。制作 ER 图。将其放入文档中。
简要描述重要问题的设计背后的原因（为什么选择多态关系，为什么使用这个视图，选择什么是你期望的更棘手的等等）。这会随着您编码而改变（并且您无能为力）。记录更改。为了应对这些变化，请使用数据库版本控制系统，例如 rails 迁移。
设计网站的结构（部分、页面、链接、页面流等）。记录下来。 （例如：“网站 2 个部分，此部分由...组成”等）
在此基础上制作一个描述您的控制器和视图的文档。 （“文章控制器，具有列表视图和文章视图，还可以编辑和创建视图，但仅供管理员使用”等）。
描述您将如何强制执行身份验证和授权（在控制器和视图级别）。谁被允许在哪里。
描述您如何在需要时防范主要网络攻击（xss、csrf）。 （例如：“我使用 htmlentities 转义所有视图变量以进行 xss 保护和...”）
设计您的模型和辅助功能（发送电子邮件、后台作业等）。这些将是大部分代码。记录每个问题并描述主要问题（例如如何处理时区、这个特定模型如何连接到货币服务、该模型如何解析和操作某些 crone 文件、您应使用什么算法来决定前 5 个问题）文章，具体取决于您的应用程序。）描述您使用哪些库、如何使用以及用于什么目的（例如：“我们将使用curl来废弃SO并制作rss feed”）
描述如何在需要时防范主要 Web 攻击（sql 注入、xss）。
当你编码时，事情就会发生变化。您对系统离散工作的了解不断发展，并且您开始根据新发现的启示改进设计。记录您的更改。
Regarding coding standard/structure/frameworks I recommend zend framework coding standard, MVC structure, and Zend Framework.
A brief guide for a MVC architecture. The idea is tho help you remember ideas (while your brain is steaming code) and have documents for future programmers.
Design the database. Make an ER diagram. Put it in a document.
Briefly describe reasons behind the design for the important issues (why you choose a polymorphic relation, why use this view, what selects you expect that are more trickey etc.). This will change as you code (and there is nothing you can do). Document the changes. To cope with the changes, use a versioning system for the database like rails migrations.
Design the structure of your website (sections, pages, links, page-flows etc.). Document it. (like: "the site 2 sections, this section is made of ..." etc.)
Based on this make a document describing your controllers and views. ( "a controller for articles, with a list view, and article view, also edit and create views but just for admins" etc).
Describe how you are going to enforce authentication and authorization (on controller and view level). Who is allowed where.
Describe how you protect against the main web-attacks (xss, csrf) where required. (example: "i escape all my view variables using htmlentities for xss protection and ...")
Design your models and side functionality (sending emails, background jobs etc.). These will be the bulk of code. Document each and describe the main issues (for example how timezones are to be handled, how this certain model is to connect to the currency service, how that model is to parse and manipulate some crone file, what algoritm you shall use to decide top 5 articles, depending on your app.) Describe what libraries you use, how, and for what purposes (example: "we are to use curl to scrap SO and make rss feed")
Describe how you protect against the main web-attacks where required (sql-injection, xss).
As you code, things change. Your knowledge about the discrete works of your system evolves and you start to improve the design based on the new found enlightenment. Document your changes.
来自热爱抽象的人的一些想法。
找出您的网站的共同点。一旦确定了主要的共性，就寻找能够处理尽可能多的共性的框架或库（除了满足其他标准之外），例如样板数据库代码。
对于您找不到任何现成代码的常见功能（它们始终存在于定制网站中），您将有机会自己编写一个可在您的网站上使用的通用库。这可以是标记的模板、JavaScript 库或可重用的服务器端组件，或全部。
根据您的描述，听起来您在创作过程中享受着很大的自由（而不是向您提交需求规范并要求实施它）。我想说也不要过度计划，“立即开始编码”很有趣，而且也不全是坏事。经验将是你最好的朋友，当你到达网站 #100 时，你将拥有很多经验。在构建第二个网站时，您在第一个网站上的经验将帮助您避免犯一些错误，并且您会发现在规划阶段没有预料到的新相似之处。只需确保花时间，将通用代码移至单个库，然后返回并编辑您的第一个网站以使用它。多做几次，你就会学到很有价值的教训。
A few thoughts from someone who loves abstractions.
Figure out what your websites will have in common. Once you have identified the main commonalities, look for frameworks or libraries that deal with as many of them as possible (besides filling your other criteria), such as the boilerplate DB code.
For the common features that you can't find any ready-to-use code (they always exist in customized websites) you'll have a chance to write a common library to be used across your websites yourself. This could be a template for your markup, a JavaScript library or a reusable server-side component, or all together.
Based on your description it sounds like you are enjoying great freedom in the creative process (versus getting a requirements spec handed to you and asked to implement it). I'd say don't over plan either, "just starting to code right away" is a lot of fun and not all bad. Experience will be your best friend, and by the time you reach website #100, you'll have lots of it. When building your second website, your experiences with the first one will help you avoid making some of the mistakes you made, and you'll discover new similarities that you did not anticipate in the planning phase. Just make sure to take the time, move the common code to a single library, and go back and edit your first website to use it. Do this a few times over and you will have learned lessons that are worth a lot.