Coder+问题+酷

PI君一直想做一名极客式的开发者，也正在为之努力，但是路途中多有曲折，也偶有迷茫困惑之感，写下来，共勉吧。

这段时间在负责项目的顶层业务模块开发，项目的细节出于公司保密的要求，略去不表，直接说问题，界面上有简单的数据查询/选中编辑/选中删除/保存，都是对数据的操作，流程很简单，界面也大致相同，但是业务模型非常多，如果每一个都写一个增删改查的流程，后期较难维护是其一，工作乐趣全无却不能忍受，怎么解决？这是第一个悬在PI君心中的问题，目前没有做深入的思考，欢迎留言讨论~

另外一个问题，前天，整理了之前看过的关系数据库的相关知识库（暂时更新到存储过程），期间一直通过一个足球比赛的小游戏来验证数据库的相关知识，在使用ADO访问数据库时，三个表，PI君就写了三个DAL，写到后来，实在无奈（忍住没有用ORM），于是痛彻心扉的领会使用ORM的必要，但是，还是忍着不用ORM，想想如果自己写，应该怎么避免DAL的大量重复性代码，这是一个很值得深入思考的点，PI君抛出问题，感兴趣的Coder们一起讨论下~后续，PI君会将自己解决这个问题的思路和过程刊出，分享快乐~

上个月，给PAN君（PI同事）派了个活，写个XMLParse，配合现在的领域对象在计算过程中读取和保存中间计算结果，PAN君给出两种方案：①序列化和反序列化，②DOM对象自定义读写。PI君不给建议，因为实现简单，让PAN君不如都写出来试试，在实现过程中，遇到了问题：首先，序列化和反序列化行不通，因为领域对象依赖于第三方库，第三方库的部分对象不支持序列化，所以直接序列化行不通；DOM自定义读写，实现了，但是和领域对象的结构耦合性太强，完全是面向过程的编码，项目中领域对象很多，不可能一个结构一个XMLParse，所以也是不靠谱的方案。那么咋办呢？PI君再把这个问题抛出给大伙~一起讨论下吧，PI君有自己的解决方案，后续刊出，分享快乐~

有段时间和领导沟通一个思路——测试驱动开发（TDD），PI君从网上和培训课堂上对概念性的东西耳熟能详，可惜，纸上学来终觉浅，须知此事要躬行。PI君有个习惯，针对一种技术或手段，如果要学，首先得明白这种技术或手段解决的问题，也就是产生这种手段和技术的需求是什么，不然总是不能尽心，所以对TDD，一直以来，PI君很好奇他产生的需求是什么？网上有不少介绍，从软件工程的角度评说TDD带来的好处，解决传统瀑布式开发模式存在的问题，但是就目前PI君的水平还远没到这般高瞻远瞩，如果从Coder角度看，TDD解决Coder们的痛点是什么呢？PI君抛出这个问题，欢迎Coder们一起讨论~

开发工作中，总是遇到这样或那样的问题，遇到问题的态度决定Coder前行的远近，解决问题的能力决定Coder水平的高低。

发现问题，有时候并非自愿，但是一旦发现，便迎难而上，历经磨练，最终搞定问题，丰富学识，岂不是真的很酷。Coder就应该这么酷的工作。