关于一次失败的项目开发的反思和总结

这次教训比较深刻，磨刀不误砍柴工也是这个道理，最大的体会就是： 相比较技术而言，解决问题的思想和方式更为重要 。

在开发一项公司活动产品的过程中，我因为建表太过肤浅，不规范，导致后期开发的过程中，代码越来越臃肿，各项判断循环嵌套，极难维护和再拓展。我下来请教了同事，咨询了几位朋友，最后得出以下四点心得，发出来，时刻提醒自己：

    1.根据实际需要解决的问题去分析该问题存在几个主体，一次来确定需要几个 表 ，表之间的关系是什么。

例子：邀请人，被邀请人，团队。

a通过分享链接，b点击链接注册参与活动。a是邀请人，b是被邀请人，a和b共同组成一个团队大A，该团队的负责人是a。

    这个例子中出现了3个主体：a、b、A，其中A是a和b组成的组织型主体，虽然在现实生活中不具有实体，但A也有自己独有的属性，所以也必须单独作为一个主体。

    2.根据这些主体具有的主要属性，以及实际问题需要对这些主体做哪些数据处理的操作（需求分析），这两点来判断这些主体（表）都需要哪些具备哪些 字段 。

    3.给每个字段设置 数据类型 和是否为空时，需要细化具体分析，预测做该字段的数据处理是，涉及到哪些操作，如何设置数据类型，才能实现更高效的开发。

第1、2、3步需要反复推敲，直至打通每一个环节，才能进行后续的代码开发。

    4.在后端代码的开发初期，时刻反思数据库设计是否合理，数据表是否合理，数据类型是否合理。如果改动，是否会影响到其他的逻辑操作。这一步需要兼顾数据库稳定和高效。