写程序---原理方面
1.解构的方法
当我们用分析的方法思考问题的时候，就需要对事物进行拆分。
而具体需要怎样拆分，是我在具体编程过程中常思考的问题。
最后我总是会发现，拆分的方法是由逻辑上下文的需要决定的。
逻辑上下文1：
长板凳，可以分三个区：左区，中区，右区。
当一个人，坐到左区时，会失去平衡。
坐到右区也会。
而坐到中区不会。
所以一个人要坐到中区。
完了。
逻辑上下文2：
长板凳分成：凳子面，两个凳子腿，这3部分。
把凳子腿插到凳子面上，就组装好了。
同样是长板凳这个东西。
第一个上下文里，需要分左中右，才能说清楚坐到哪里的问题。
第二个上下文里，需要分面和腿，才能说清楚怎么组装。
再举一个例子：
同样是一只鸡。
你要吃它的时候，你拆成鸡腿，鸡翅什么的很合理。
但若是你是在学习解剖，你就得一点一点，把xxx肌肉拆出来，把xxx血管拆出来。胡乱一刀下去可就废了。
明明是同一个东西，说不同的事情，需要不同的拆分方法。
有的时候感觉混乱的时候，我们往往是采用了错误的解构方法。
-------------------------------------------------------------
有的时候，我的解构方法已经很固定了。
但是可能因为我，写完很长时间了重新看代码。
结果就会找不到代码在哪里，然后又一点一点看代码。
后来就想起来了------我总是把数据加载的代码单独封装一个方法，客户让我多显示一个字段，我应该去改这个方法来着，这个方法的名字总是xxx开头的。
-------------------------------------------------------------
这是两个理解的过程。
1是，根据客户的描述，找到可靠的解构方式，把客户的描述变得逻辑清晰，便于编码。
2是，看代码，反过来想出，当时写代码的人是怎样解构一个大问题的。
2.对应关系
就是关系型数据库中常用的：【1:1，1:n，n:m】这种对应关系。
这个问题，也经常想。但是我一般不会乱。
把结构方法想好了，这个顺带着就想明白了。
写程序---代码整理方面
3.公共与非公共
当一段代码反复出现的时候，我们就会想着提取出公共方法来，多个地方调用就行了。
在提取方法的时候，会纠结这个【公共与非公共】的问题。
到底哪一部分是公用的，哪一部分是个性的呢？
这个问题，还是看具体情况，才知道到底哪里是公共的。
4.红苹果问题
红苹果是苹果的子类，还是颜色属性为红的苹果。
这个问题其实没有固定答案。
主要看个人习惯。
真要说依据什么规则的话，那就是：控制代码量在合理范围内。
如果说封装成属性，会让苹果类中代码量过大，就应该将红苹果单独一类了。
5.行为归谁
【狗咬了人】和【人被狗咬了】是一个意思。
用伪代码写就是
狗.咬(人)
人.被咬(狗)
当我第一次发现我写的代码里有类似于【人.被咬(狗)】这种形式的句子时，我迷惑了。当时是【数据源.加载到(表格控件)】。
我为什么会这样写。
虽然形式有点类似，但是我用的并不是那种可以随意交换对象位置的函数式编程语言。
在c系语法的表达中，人的被咬，活脱脱是一个主动的方法。
并不能表达出，咬这个动作是狗做的，人都是被动的。
我只能通过方法的命名去表达这层意思。
所以说，这样写不别扭吗？为什么会这样写呢？
后来想明白了，我这样写，是因为我更熟悉人这个对象。
人.xxx()习惯了。
抛开主被动的问题，其实就只剩下了一个先后的问题。
在现实生活中，我关心人不关心狗，所以我把人放在句子开头；在编程中，我熟悉后台的某个对象，所以扩展的一些方法也给归到它里面了。
所以说具体封装成什么样，也是和个人习惯有关的。
6.还有命名的时候很纠结
还有一些小事情，也很让我纠结。
就是一个文件它命名什么好呢？
首先我，总是想命名应该和它的含义能对应起来。
名字起好了，又一看，这么长？
又一想，挺乱啊，应该弄个前缀，让同类的文件按名称排序排到一起啊。
这种其实也不用纠结的。
文件命名，变量命名，都会有类似的纠结。
这个的底线大概是：下次自己能明白这个变量的意义。
7.程序错在哪里
当我程序写了不少，但bug改的不够多时，我感觉改bug很不得法。
从表面的错误反推逻辑哪里错了；
这和写程序的过程正好相反。
总结
前面的问题，通过逻辑推理，是可以得到唯一的答案的。
后面的问题，大多也和习惯有关系，有了自己的一个习惯或者说偏好，就不会纠结了。