这一周的工作推进的不甚理想。首先表设计方面，可能是受到框架自带的系统相关的表的命名影响，我们领导在设计表的时候没有很好的做好命名规范，有些字段用的拼音全拼，有些用的字的首字母，有些完全小写，有些用的小驼峰如userName，还有些用的大驼峰如UserName，有些字段用的单词，这些不同风格的命名出现在一个数据表的时候，往往给人一种很杂乱的感觉，比如有些词你不知道是什么意思，全拼的还好说，但全小写的英文字段就蒙蔽了，因为不清楚一个词到底尾字母是哪个，多个单词组成字段时，这就是问题了。还有一点，字段在MSSM里是可以设置字段说明的，但有些字段在设计的时候就没有将字段说明写清楚，比如一个int型的表示某状态或者类型的字段，说明只写上“**状态”或“**类型”，这是很笼统地，不能说清楚这个字段的具体用处，应该将已知的信息放进来，比如UserType:用户类型【0：用户、1：业务员、2：其它……】。
还有就是项目目标框架的问题，现在我也不清楚老板是怎么想的，老板是懂技术的，但是框架让我们用的却是webform，而且这是一个奇葩框架，可以做后台管理系统，可以写接口返回json，更奇葩的是，用户使用的后台以及接口是通过一个框架里的一个叫开发者平台的东西，通过配置搞出来的，总之就是一切都靠配置就可以解决。目前给我的感觉是，我有基础的sql语句编写能力，有c#基础能力和一些前端知识，但我现在的尴尬是不清楚代码该写在哪里？跑偏了……这个框架的目标框架是.net framework2，框架上一些组件在目标框架2.0或3.5上都可以正常运行，但是到了4.0，有些组件就不工作了，虽然不报错。而问题恰恰就是我之前在写二维码海报生成功能和调用阿里云短信功能时，将项目目标框架改成4.0了，改后编译项目不报错，也没发现框架使用时的问题。所以就提交了，知道两天后有人注意到有些组件有bug，我们这才意识到目标框架的问题，最后定下最高3.5没问题。这意味这我写的或叫整理的那两个方法要改动以适应这个低版本，真的是很不爽，另外3.5上，很多习惯的语法都用不了了，真的是够了。我现在不方便丢掉工作，只能选择慢慢适应这个破框架。
由于对这个框架的不熟悉，而且框架在使用上的例子很少，框架维护或研发者跟我们异地。所以在理清业务逻辑基本确定一些表设计且效果图出来后，我先将一些基础功能的逻辑通过存储过程的方式写出来。再后来确定项目就用这个框架写并且不允许使用存储过程的情况下，我将之前写的存储过程在程序中通过拼接sql的方式进行转换。这么说吧，原来一个逻辑访问一次数据库就行，现在可能需要访问不止三次数据库才行。真的好不习惯，老板喜欢就行，功能能搞出来就行。多说一点，现在微软都官宣.net core 是.net的替代品，且官方明确指出asp.net core在性能上比asp.net更高，依附在微软旗下的互联网公司或开发者应该很清楚以后的路了。
周五的时候，客户来了，可能难以想象，客户签合同前，是没有见到自己想要的产品的原型和效果图的，甚至连需求文档都没给。周五可以想象，在客户走后的结果。大部分功能都是砍掉的，或者说是当前不需要以后可能需要的。所以说，这是流程上的重大问题，但考虑到这是这家刚成立的分公司，所以也可以理解。总结一下教训就是，在做原型的时候，原型知识经过领导的同意，技术领导的同意，但少了客户的同意。效果图是看着原型做的，前端是看着效果图做的。原型出了问题，那么后面工作白做不是很正常吗？我们的技术领导，或者说是项目负责人，在效果图和前端都已做完的时候才跟客户第一次交流，进而进行较大的变动。所以说，没更早和客户进行技术层面的交流也是个问题，以后得注意。以我当前的经验或者认知，互联网公司给别人做产品的流程大致应该是这这样的：
业务经理谈客户、技术人员或业务人员做原型、业务人员和技术人员对原型达成共识、原型交由客户进行查看复审，然后提出修改意见、技术有选择的修改原型并跟用户达成共识、确定原型设计数据库选择技术实现方式做出效果图、用户确认效果图（仅涉及视觉效果变动）、效果图达成共识、前后端开发。
以上，最重要的是多和客户沟通，有选择地遵从客户意愿，原型/效果图出来首先找客户确认达成共识。