1NF：属性不可再分2NF：表中不存在部分依赖3NF：不存在传递依赖三范式很重要，但不一定非要满足这个看查询频率，如果在多表联查A表经常用到B表这一列，可以直接将B表这一列存到A表里，用一点点冗余换取时间效率，我觉得也不是不可以的
需求是会变的（这是很头疼的）客户不清楚他想要什么，我们就需要边做边思考，当我们做出来了之后，客户会发现，这个是不是他想要的，如果不是，他会说：我想要的事什么什么样子需求一变，后面的全都得跟着变，这个时候如果你的软件扩展性设计的非常好，后续需求变更修改时就不会那么麻烦，如果设计的不好，耦合性太高，后续修改代码的时候就会非常难受，所以如何应对需求变更，这个也是我们在写代码之前需要思考的问题，万一将来客户不想要这个需求怎么办
实施（出差）去甲方部署培训答疑
后端开发业务开发
数据库设计（极其重要：要根据需求、根据实际情况、查询检索修改的频率去综合考虑如何设计）难点：表与表之间的关系，怎么样能够最大的满足客户需求该如何设计冗余
SVN集中式版本管理系统Git
设计接口文档面向接口编程
产品经理和甲方对接需求
运维服务器产品维护工作
用PS作一张大图后续需要切片按钮、背景、前景等
前端开发安卓iosH5
脚手架 若依规避重复性的工作（基础版，没有实际的业务）每个公司、企业都有自己的脚手架，自己研发的一套东西我不能每次都搭一套SSM，每次都重新写一套登录注册，企业开发讲求效率
需求分析会分析需求分析这个需求是不是客户想要的、是不是我们想要的（理解客户的需求是很难的，客户未必能够将自己的需求说清楚，他自己可能不清楚自己想要什么，这时候就需要我们替客户来思考需求）做需求拆解，将大的需求拆解成一个个小的需求逐步完成
测试bug
立项设计产品（思考你的产品，或者和甲方沟通，你的甲方有需求，获取甲方的需求，当你有了自己的产品的，了解了要做什么）
UI
面向业务编程语言只是工具服务于业务需要从CRUD中Get到东西，业务中包含的业务逻辑、业务能力，写过几个相似类型的产品后，对应类型的业务要烂熟于心，这也是程序员能够转成项目经理的原因之一随着年龄、工作时长、阅历的增长，不同的人有不同的发展如果从事于互联网公司，就需要考虑超高的并发、产品的不断迭代、不断升级，技术就会显得更重要
PowerDesigner
根据产品和甲方需求设计需求需求文档
画原型图
