Django学习实战篇一（适合略有基础的新手小白学习）（从0开发项目）

前言：

   本系列博客将带大家从0开始做一个简单的博客管理系统。完整代码在github上。本项目将用django4.2版本和python3.11版本带大家实现完整开发过程。

   在学习django过程中，绝大部分的教学和讲解采用的都是老版本的django（1.x，2.x, 3.2）和python（3.6），目前最新django版本为5.1，python版本也到了3.12了。对于django版本而言，1.x 和2.x 都已经太旧了，3.x版本也有一些第三方插件不支持（有写插件只支持4.2及以上版本），所以这里干脆用4.2版本进行讲解（旧版本只要不涉及第三方插件也可以正常使用运行）。python也是有些第三方插件不支持3.8以前的版本，这里用3.8之后的版本都可以。

   网上绝大部分django讲解都是要收费的，视频讲解也都是录播课，听完后自己也是一知半解。之后自己再花钱买课学习，再阅读相关书籍并上手操作，总算是把django入了门。写本系列博客也是看网上没有相关完整的项目实战博客，那就自己搞一个，分享一下自己的学习经历、学习过程中遇到的问题和解决方案，降低学习Django时的心智负担，主要针对想学习Django但又无从下手，或者看了很久文档能完成新手教程，但想自己开发一套系统时却无从开始的人，也希望本系列博客能帮助到大家更好的学习django。

第1章：需求

   凡事都得有个来由，做软件开发也一样，总得有一个需求过来，启动一个项目，或者推动整个项目进行下一步迭代。这个需求可能是根据用户反馈增加的，可能是老板提出来的，也可能是产品经理提出来的，但是无论是什么样的需求，重要程度如何，最终到开发人员这里都需要转化为功能点——可以被量化的功能点。因为产品经理或者老板需要知道，这个需求多久能够开发完成，多久能够上线让大家使用。

   因此，就有了软件工程中的几个步骤------需求分析、软件设计和软件测试等。对于开发人员来说，需要对需求进行评审，这是为了避免产品经理提出无法实现的需求，最终导致需求被迫变更或者项目“流产”。

   在需求评审之后，开发人员把需求转换为系统的功能点，然后评估开发时长。最终需要评估出来一个可把控的开发周期给产品经理或者项目经理，同时也给开发团队定下截止时间，避免出现无效的开发行为，比如某开发同学觉得时间还长，就开始在一些小的问题上死磕，力求得到一个完美的答案等。

1.1 需求文档

   需求文档是产品经理跟开发人员交流的必不可少的东西，很多东西如果不落实到文档上，出了问题很难追溯。尤其是对于企业中长期开发的项目来说，一个项目可能由无数个开发人员参与，所谓“铁打的项目，流水的开发”，文档是新人在接手项目时必须阅读的。另外，交流基本靠吼的方式也很容易丢失信息，还会出现开发后期不知道需求是谁提出的这种尴尬的问题。所以，无论是什么需求，无论是需求变更还是追加，都应尽量落实到文档上。
接下来，我们说说博客开发的需求。

1. 介绍

      博客（英语：Blog，为WebLog的混成词)，意指logon the web，即在网络上记录,是一种由个人管理的网站或在线日记，可以张贴新的文章、图片或视频，用来记录、抒发情感或分享信息。博客上的文章通常根据张贴时间，以倒序方式由新到旧排列。
      许多博客作者专注评论特定的课题或新闻，其他则作为个人日记。一个典型的博客结合了文字、图像、其他博客或网站的超链接以及其他与主题相关的媒体，能够让读者以互动的方式留下意见，这些是许多博客的重要要素。大部分的博客内容以文字为主，也有一些博客专注艺术、摄影、视频、音乐和播客等主题。博客是社会媒体网络的一部分。

      博客也是一个与他人分享和交流的平台，通过书写自己的想法、学习技巧和工作经验，来结识不同领域的读者，交流和探讨技术、思想、文化或公司等话题。

2. 需求描述

      简单来说，博客系统分为两部分：读者访问部分（用户端）和作者创作部分、作者端）。

   用户端的需求如下：

   • 要能够通过搜索引整授索到博客内容)进而来到博客;□可在博客中进行关键词搜索，然后展示出文章列表；
   • 能够根据某个分类查看所有关于这一分类的文章；
   • 访问首页时，需要能看到由新到旧的文章列表，以便于查看最新的文章；
   • 要能够通过RSS阅读器订阅博主的文章；
   • 要能够对某一篇文章进行评论；
   • 能够配置友链，方便与网友进行链接。
        

   作者端的需求如下：

   • 博客后台需要登录方可进入；
   • 能够创建分类和标签；
   • 能够以Markdown格式编写文章；
   • 能够上传文章配图，要有版权声明；
   • 能够配置导航，以便引导读者；
   • 作者更新后，订阅读者能够收到通知。
        

   这就是一个简单的需求描述。从这个需求描述上来看，无法确定需要做出什么样的东西，因为很多细节没有说到。这时如果技术人员尝试以自己的理解去开发一个博客系统，可能会导致跟产品经理或者用户想要的结果不一样，从而进行无谓的返工。
   下一节中，我们进入需求评审和分析阶段，帮助产品经理整理清楚需求，让技术人员在开发时能够知晓具体的需求点是什么，需要开发哪些功能，如何设计系统、建立模型等。

1.2 需求评审/分析

   对于有经验的产品经理来说，在做任何需求的时候，都会计划得足够细致，落实到一个功能点。更好的情况是能够出原型稿，之后可以通过原型来对每一个功能点进行逐一核对。对技术来说，评审的目的有如下三个：

• 明确所有的需求点，避免出现理解上的歧义；
• 确认技术可行性，避免延期或者后面再修改需求；
• 确认工期，是否需要分期开发。

1.2.1 博客需求评审

   针对产品经理提出的每个需求，我们都需要仔细核对，尽量避免歧义或者沟通不畅。下面我们逐条来分析。

1. 用户端部分

   • 要能够通过搜索引擎搜索到博客内容，进而来到博客。从技术上来说，这个属于SEO的部分，只需要提供sitemap（网站地图）到搜索引擎即可。同时，远面需要对爬虫友好，需要跟产品经理明确的事情是，技术上无法保证一定能够通过搜索引擎搜索到博客，这最终取决于搜索引擎。
   • 可在博客中进行关键词搜索，然后展示出文章列表。需要明确搜索哪些字段，比如标题、标签和分类等。如果需要全文搜索，就要考虑数据量的问题。如果数据量大，就不能直接使用MySQL的LIKE语句，需要增加全文搜索相关的技术栈，比如引入Whoosh、Solr或者Elasticsearch这样的瘦索引擎。
   • 能够根据某个分类查看所有关于这一分类的文章。对于分类，要明确的是有没有子分类这样的需求，如果有子分类，那么于分类的文章要不要在父分类下展示，以及子分类的层级有没有限制。
   • 访问首页时，需要能看到由新到旧的文章列表，以便于查看最新的文章。首页排序从新到旧没问题，是否有特例，比如某些文章必须置顶。另外，是通过分页的方式展示列表,还是页面可以不断下拉加载的方式。每个页面/每次加载多少条数据。
   • 要能够通过片RSS 阅读器力阅博主的文章。需要提供RSS格式数据的页面。
   • 要能够对某一篇文章进行评论。是否需要前台（用户端）查看所有评论的页面。
   • 能够配置友链，方便与网友进行链接。友链在前台如何展示，是单独的页面还是一个列表页。
        

2. 作者端需求

   • 博客后台需要登录方可进入。是否有多用户登录的需求？如果有，那么用户之间的权限如何划分？
   • 能够创建分类和标签。跟上面的问题一样，是否有多级分类和标签的情况，如果有，需要明确父级分类或者标签是否包含子级所关联的内容。
   • 能够以Markdown 格式编写文章。作者编写文章时，有哪些是必填的，在网页上编写是否需要实时保存。
   • 能够上传文章配图，要有版权声明。版权声明具体表现为什么？
   • 能够配置导航，以便引导读者。导航是否是指分类？是否包含标签？需要产品经理给出明确的需求。
   • 作者更新后，订阅读者能够收到通知。在博客的整个需求中，并没有需要读者登录的账号系统，无法对读者进行实时通知。但是可以考虑增加邮件订阅功能，通过邮件的方式通知读者。此时需要明确邮件的内容格式，以及作者是否需要控制发送邮件的开关。

1.2.2 评审之后

    其实在实际的需求评审中，不需要每个需求点都抛出问题来确认，因为大部分都是专业的产品经理，知道用户想要什么的同时，也知道技术能实现什么。这主要是基于过往的经验。所以，这类产品经理会给出很明确的需求，配合起来会比较默契。但是无论对于什么样的产品经理，所有的需求都需要当场讲解一下，对于不太理解的需求，需要反复讨论确认。
    所有开发人员都有必要理解产品经理的需求、这个需求点的作用及背景，通过消化需求点来进行开发，而不是单纯地把需求文档翻译为可执行的代码。
   经过这么一轮的问答，产品经理也会在产品文档上更加明确自己的需求点，最终的描述应该是包含了开发人员对所提问题的解答。
   另外有一点需要注意的是，对于产品经理自己也不是特别明确的功能点，比如技术方面的，开发人员应该能够根据以往的开发经验以及技术积累，给出合适的建议，在满足同等功能的情况下，让技术上实现起来更加容易。但是，记住一点，用户需求是第一位的，技术复杂度是第二位的。
在这之后，我们应该能得到一份详细的需求列表。下一节中，我们对需求进行拆分，把需求转为技术上需要实现的功能点/技术点。

1.3 功能分析

   上一节中，我们对需求进行了评审，经过对细节的沟通之后，产品经理对需求进行了修改和明确。

1.3.1 需求列表

1. 用户端部分

   • 网站需要对SEO友好，具体可参考搜索引擎站长白皮书。另外，需要给搜索引擎提供XML格式的sitemap文件。
   • 博客需要提供搜索功能，拽索范围限定在标题、分类和标签上。博客每天的增量数据为10篇文章。
   • 能够根据美个分类看所有关于这一分类的文章，分类没有层级的关系，只有一级分类。一篇文章只能属于一个分类。
   • 访问首页时，需要能看到由新到旧的文章列表，以便于查看最新的文章。作者可以设置置顶某篇文章，也可以同时置顶多篇文章。多篇文章置顶时，排序规则为从新到旧。
   • 列表分页需求。针对首页、频道页和标签页，都需要提供分页需求，每页展示10篇文章。列表页展示文章时，需要展示摘要，默认为文章的前140个字。
   • 需要能够通过RSS阅读器订阅博主的文章，具体可参考RSS规范。
   • 要能够对某一篇文章进行评论。评论不需要支持盖楼的模式，只需要在文章页面展示评论。在页面侧边栏，也需要能展示最新评论。
   • 能够配置友链，方便与网友进行链接。这在一个页面中展示即可，不需要分类。但是需要能够指定某个友链的权重，权重高者在前面展示。

2. 作者端需求

   • 博客后台需要登录方可进入。目前没有多用户需求，以后可能会有，要考虑可扩展。
   • 能够创建分类和标签，一篇文章只能属于一个分类，但是可以属于多个标签。标签和分类都没有层级关系。
   • 作者在后台需要设置文章标题、摘要（如果为空，则展示文章前140个字）、正文、分类和标签。不需要实时保存。文章格式默认为Markdown。开发周期够的话，增加可视化编辑器。
   • 增加文章配图时，图片需要增加水印，其内容为网站网址。
   • 导航只是分类，默认展示在顶部。同时每篇文章都需要有浏览路径，以告知读者目前所处位置。浏览路径的组成为：首页>文章所属分类>正文。对于导航的顺序，作者可以设置权重，权重高者在前。顶部最多展示6个分类，多余的分类展示到底部。
   • 作者更新后，读者能够收到通知（暂时不开发）。

1.3.2 功能点梳理

   功能分析的目的是从产品经理所提的需求中提炼出这个系统有哪些功能点，最终落实为功能列表/清单（可以按照模块或者相关功能来划分），进而再进行任务分配。
   从上面最终确定过的需求列表中，我们可以逐条列出博客系统所需要的功能点有如下这些：

• 后端渲染页面，对SEO友好;
• 提供sitemap.xml文件，输出所有文章；
• 搜索功能，能够针对标题、分类和标签进行搜索；
• 根据分类和标签查看文章列表；
• 文章可以设置置顶，可以同时设置多篇文章置顶;
• 首页（列表页）需要展示文章摘要，140字以内，可以作者填写，或者自动展示文章前140个字：
• 首页（列表页）需要分页展示，每页10条；
• 提供RSS页面，根据RSS2.0规范输出内容；
• 文章页面支持评论，不需要盖楼，侧边栏能够展示最近评论；
• 评论模块需要增加验证码功能，避免被刷；
• 后台能够配置友链，所有友链在一个页面中展示；
• 用户可以通过用户名和密码登录后台，之后才能创建文章；
• 需要考虑多用户的扩展情况，多用户时需要对分类、标签、文章、友链的操作权限进行隔离；
• 分类增、删、改、查——需要字段id、名称、创建日期、创建人、是否置顶导航以及权重；
• 标签增、删、改、查——需要字段id、名称、创建日期和创建人;
• 文章增、删、改、查—需要字段id、标题、摘要、正文、所属分类、所属标签、状态（发布、草稿或删除）、创建日期和创建人；
• 侧栏模块用来展示侧边栏需要的数据，需要字段ia、类型、标题、内容、创建日期和创建人。

1.3.3 模块划分

   经过上面的分析，我们得到了足够细化的功能列表。有了这些细节的描述，开发人员就能够确定要做出什么样的功能来。不过这个时候，需要有人来做一个整体的梳理，把相关的功能整理为一个模块，同时抽象出实体。

   有了足够明确的需求之后，下一步需要做的就是建模。建模的意思就是建立系统模型以及数据模型，这里需要提到一门语言——UML（统一建模语言）。这是以前非常常用的一种建模方法，通过UML画出用例图，整理用户需求；然后画出序列图，整理出系统各模块的交互逻辑；最后会用这些模型来实现。另外，针对数据模型部分，一般会先画出ER图(Entity Relationship Diagram,实体关系图），理清楚每个数据模型之间的关系。好的ER工具可以直接帮你生成建表语句以及模型代码。

   理论上来讲，产品经理会整理出所有的用户需求，输出产品需求文档（PRD）给开发人员。开发人员需要从中提取出实体以及各模块之间的交互关系。

1.4 本章总结

   在这一章中，我们主要介绍了日常开发中接收到需求后应该如何处理，通过需求分析最终应该得到哪些产出，从而对后续的开发提供指导。下一章中开始带大家进入正式开发。