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就应该这么酷的工作。

回到

顶部