虽然这是一个类似于api形式的项目，每个api里面只有固定的get,post,之类的才能成为方法。如果我在这个现有的风格上做一些修改，应用一些诸如《代码大全》中定义的“最合适7”的规则，或者一个函数的篇幅最好是一个屏幕那么高的规则，那么会在现有的代码中显得格格不入。我还是把自己的心得记录下来，作为自己的一种追求和努力的方向吧！如果以后有机会，还是需要在一个能够提升代码风格的项目组锻炼下。
- 一个函数本应该只完成一个功能。
现在的系统中，很多地方做一些必要的参数合法性校验，也一股脑写到了函数体中。这导致可能需要阅读几十行代码才能真正进入到核心功能部分的代码。 - 写了setters,getters的类，却堂而皇之地将变量写成了类变量，而且丝毫没有用到private,protect。那在类外可以随便直接调用这些类变量，还用setters和getters作甚？
- 分层混乱。下层操作和上层操作经常混在一起。例如，明明可以实例化类的时候，传入一个构造函数的参数，就可以完成一些初始化操作，却用了一个函数成员去专门进行了类操作。然后在定义了对象之后，先调用初始化操作的函数成员，然后再调用真正需要的操作。
- 类方法和普通的方法并没有加以区分。一个类里面，有的方法在外部不需要访问，只在类的内部进行访问，却也被写成了成员函数。
- 函数的命名不太有解释性。这一点和第一点有交叉的地方。如果一个函数将很多毫无联系的操作揉在一个函数里，那么这也仅仅只是一种毫无意义的强硬做法。就是因为它完成了很多功能，导致在起名字的时候不能有一个很好的答案。既做了大篇幅的合法性校验，又去读取了文件，还实例化了类变量，还对变量进行了修改。那么最终这个函数应该叫什么呢，这真的是一个让人头痛的问题。
- 在python深究中的“赋值引用问题”是我在读代码时，发现了不能理解的地方，然后进行的实践。我不明白为什么原作者要给一个要操作的变量起了一个名字，然后对它做了一些修改，然后并没有把这个修改过的新变量赋给原来的变量，结果运行结果却还是正确的！如果说写这些代码的人明白其中的真理，那还好。如果是误打误撞，碰到了python这门语言的特性，那么下一次呢？
Ps.如果是python的特性，倒是值得了解一下。所以我在知乎上提问，希望有高人指点我。 - 变量名非常ugly.在使用flask_restful的时候，需要定一些用于解析参数的变量，当一个api有多个参数时，就用了parser1, parser2, parser3这样的命名方式。非常没有意义，以及容易带来迷惑。
- 代码逻辑混乱。《代码大全》里面提到，一个好的做法是花更多的时间去想实现的具体细节，在还没有想清楚自己怎么实现的时候，还不是动手写代码的时候。现在的项目中很多代码明显没有经过谨慎的思考就动手写了。一个例子是，一个用于自动化获取数据的线程中，包含了三个部分。提取数据部分的代码，和线程的控制部分的代码，混在一起，可读性非常差。更好的做法是将获取数据的部分，也就是业务部分，定义为函数，将代码放在里面。然后控制线程运行的部分，只写这部分逻辑的代码。另外一个不好的例子，从数据库中删除数据，同时再从本地删除。实际上，不管数据库删没删数据，本地删没删，这个删除的api都应该是成功的。区别就是删除了数据，和没有数据可删。这个区别也只是为了给程序员debug使用，但是代码里却将这两个删除操作的结果组合起来写了4条分支用于处理不同的情况。例如：删除数据库成功，本地数据没有可删。或者两者都成功。因为我后来加的代码还要多删一个数据库的数据，那岂不是得写8个分支了，用这么多的代码就为了处理这么简单的逻辑，不是浪费资源吗。明明只要将不同的删除结果作为参数返回就好了。一句if else都不需要。
===============
感觉现在呆的项目组一点东西都学不到了。
虽然svn也是版本控制系统，它不如git好用（个人观点）。但是，svn也有branch呀！现在的svn仓库中，基于不同的开发需求，不同的开发者，有很多个源代码库！在这样的环境中，如果我做了正确的事，其实会被当成另类。
关于技术虽然没有学习到，但关于工作态度还是学到很多。现在的leader是一个非常有责任心的人，也非常的上进。总是很积极主动地去做一些项目上的事情。真的很佩服他。如果让我带一个项目，如何跟客户沟通，如何统筹成员的工作任务，这些都是我不太擅长的。
在这样的环境中，以及当前的局势下，我还是好好想想如何保持我的鸡头不动吧。
希望这篇流水账式学习心得能够给你哪怕一丝帮助~祝好！