作者：赖秋芳（广智公司技术部）
前段时间过得比较苦闷，压抑，于是拿起笔随意乱画后，发现这种方式可以渲泄自己的感情，画完后有种很舒服的感觉，很自然地就喜欢上了画画，可能这会让以前嫌我做的界面奇丑无比要送我到美校去培训的人笑掉大牙了吧～。不过那也许那并不算是画画，只是随笔乱涂吧，乱涂之下结合自己的工作竟也有些感悟。
画画中有一种练习叫“纯轮廊画”，就是盯着某样事物一直不去看自己画画的结果来画，即“盲画”，这种练习是一种右脑运动，我们的左脑累积了太多平时生活、学习、工作带给我们的定律，例如太阳一定是圆的，星星是五角的。。。而这种练习正是抛开这种定律，完全凭自己的感观所得到的东西去画，全身心地投入到要画的事物中，抛开一切理性认识，当你试一下做这件事情时，会出现一种有趣的情况，当你在画的时侯，你的左脑会忍不住抗议这种可笑的行为想要阻止你，但是当你坚持下去的时侯，你会发现得到一些收获。这让我想起以前写程序时，总是喜欢拿旧系统或是其他软件的作法去比较、参照，当然旧系统中有不少可取的经验，但是前辈所做的东西也并非是百分百正确的，有时侯更应该抛开一切已知定律去独立分析问题，看清问题的本质而非表面。
画画的过程很像研发，或者说可以从画画的过程看到整个研发过程应该怎么去做。下面我就拿别人用来写画画教程的图图来说一下我自己的感受。对于某些前辈来说，这些道理也许很肤浅，无论如何，只想分享一下。
在模特缺乏的情况下，一般都会拿照片来作为临摹的对象。无论是照片还是模特，在画之前要做的事情就是仔细观察要画的对象，只有观察得深入，才有可能画得尽可能相像。这和我们开发系统之前所做的需求调研是一样的，在开发之前一定要把系统调研清楚，了解客户的每个需求，绝不能出现模棱两可的模糊需求。
观察完毕以后，先用铅笔勾勒出大概的形状，仅仅是形状，也就是把各个组件勾勒出来，看得出来大概的样子，先不用考虑具体细节，各个组件的位置布局要和原物尽可能一样，这很重要，否则到已深入细节的时侯再去改就很难了。同样，调研完毕需求确认以后，就要进行概要设计了，在概要设计里先要把系统的每个模块功能和具体流程都划分清楚，而至这些功能怎么去实现，先不用考虑，先让设计出来的模块功能尽可能满足需求，让流程看起来尽可能通畅，如果这些东西没有事先考虑周到的话，要到具体功能已经做出来后再纠正的话会比较困难和别扭。
接着开始大面积上色，同样大面积上色时也先不用考虑细节，但是有一点是要考虑的，就是光源问题，用深色块标明每个阴暗点，用浅色块标明每个亮点，这很重要，因为这样做的话你在深入细节时才能更清楚地去刻画。大面积上色有点像详细设计和制定开发计划，这时要考虑怎么去实现功能，但是仍未到刻画细节即具体编码的阶段，仅仅是设计和计划，详细设计时会更深入地了解需求，分析功能，估计大致完成此功能所需要的时间，制定开发计划，这有点像标明光源色块。
好了，接下来可以深入地刻画细节了。说是深入，其实也是一步一步地逐渐深入，因为当你画完了第一笔，你才会知道第二笔应该怎么画会更好。刻画细节到什么地步可以结束，是无人知晓的，视乎画画人自己的标准，有些人觉得可以完成的时侯也许有些人觉得还未可以。编码过程也是一样，程序员先按自己的理解用代码实现具体的功能和表达，这个功能出来时只是一个胚子，而这个功能最终的样子会在测试――提交Bug――解决Bug――回归测试这几个过程中去完成，完美的东西是在一步步的磨炼中完成的，也许这世上并没有完美的东西，当我们觉得是完美的时侯仅仅是因为还没有更美的东西出现。
一幅画中有主题人物，也有背景，一般情况下，背景的刻画可能比较粗糙，而主题则尽可能刻画得精致，如果一幅画背景和主题同样精致的话这样反倒没有了层次，有点喧宾夺主了。同样的，我认为一套系统也并非一定要应有尽有的、尽善尽美，而是要有他自己的特点，这个特点可以成为他的亮点盖过其他所有的不完美。所以我认为一套系统在调研阶段确定面向群体的时侯，就可以先确定这套系统的最大亮点，确认重要的功能模块，而在开发过程中也围绕这个亮点着重开发，再完善其他辅助点。同样的，在向客户推销软件时，先要弄清楚他最需要的是什么，再围绕着他的需求进行推销，如果他只是一个零售商，你向他怎么推销批发模块是多么的好也没有用，因为那个功能对他来说根本没有用处，这个道理也许做销售的人员一早就懂了，我这里只是顺便提一下～
有时侯画画的弊端就是太过专注于刻画细节以至忽略了整体，导致细节和整体之间的不协调，所以在刻画细节的同时应该也不时检查一下细节和整体的关系，尽可能地揉合到整体里面去。同样的，在开发过程同样地要注意各个模块之间的关系，尽可能让各个模块合理地溶合到系统中。