文章列表
 
您正在查看 "软件开发" 分类下的文章

2009-05-23 6:49
    UltraEdit是一个非常棒的编辑器,对于程序员可以支持很多种语言。除了开发意外,用它来分析日志也是方便的。日志文件往往都很庞大,几百兆也是很平常的,而UltraEdit可以支持4G的文件。UltraEdit有一个很有用的查询功能“列出包含字符串的行”,这个选项是UltraEdit的【查找】功能中的【高级】配置。


由于日志文件包含的东西很多,所以用这个方法可以很快的找出自己感兴趣的内容
再通过【查找结果窗口】剪贴板的剪贴板功能,将查询结果复制到windows剪贴板中,然后用Ultraedit再新建一个文件,粘贴内容到该文件。通过这种方式,就可以不断的缩小日志查找的范围,避免了其他内容的干扰。有时候也会需要分析某条日志的上下文,也可以先利用以上的方法定位到了某条日志,再以该条日志的内容为查询条件到完整的日志文件中查找,马上就可以定位了:-)。
 
2009-03-28 15:43
问题:为什么我们需要统一的编码风格
回答:统一的编码风格可以让你的团队减少由于代码冲突而导致的效率的降低和出现错误的几率,而将你的时间去解决真正的业务问题。
解决方法:
1. 自定义IDE代码格式,现在的IDE都支持代码格式的自定义功能
  

2. 代码提交前都要进行格式化操作

3. 用CheckStyle检查和规范代码
  

参考
用CheckStyle来规范我们Java代码
 
2009-03-21 7:48
以下是计划在2009年重点学习的内容
1. Oracle
2. Erlang
3.Java Concurrency Programming
4.Java Network Programming
5. Memcached
6. Linux
7. JBoss
8. JVM
9. Mysql
10. UML
11. REST
 
2009-03-10 13:04


内容如下:在编码的时候请把维护你代码的人想象成一个永远都知道你住哪里的疯狂连环杀手
 
2009-01-23 15:14

    春节前在一篇DIV INTO JAVA 的文章中看到了一些关于语言理解方面的内容,于是翻译出来放到了blog上。作者首先提出了一个问题——“什么时候叫做你Know(了解)一种语言”,并给出了几种可选的答案:
      1.
当你了解语法的时候吗(When you know the syntax)?
       2. 当你可以用这门语言来编写软件的时候吗(When you can write software with it)?
       3. 当你知道在哪里可以找到这门语言的手册指南吗(When you know where is the manual)?
       4. 当你使用这门语言N年以后吗(When you use the language for N years)?
        5.是当你可以和其它一起讨论这门语言的时候(When you can consult others)?

当然这些答案都是否定的。
   

最后作者给出了作者认为正确的答案
    你了解一种语言只有当你.....
     当你知道不同版本的语法差别的时候
     当你可以用这种语言高效地编写可维护的代码的时候
     当你知道如何使用手册的时候
     当你积极使用这种语言N年以后并依然紧随这种语言的发展
    当你可以针对这种语言的高级话题加以讨论的时候
    当你知道何时、如何以及为什么应该使用工具和第三方扩展
    当你知道和在实践中使用这种语言的主要概念和方法论(例如java的面向对象设计和设计模式)。
    我想这段文章是一面不错的“镜子”,每个开发人员可以用这些标准来评定一下自己对某种语言的了解程度以及接下来该努力的方向。不过在这里我还想说说自己自己对语言的理解。最初做程序员的几年做项目比较多,接触了不少的语言VB、VC、Delphi,那个时候工作中奉行的都是“拿来主义”,有项目的时候那一本参考书就开始开发项目了,平时也不注重知识的积累和学习,认为所有的语言不都是if-else,while,for等等吗。随着工作的变化和开发经验的积累,越来越注重欣赏每种语言的细节和特性,开始把每种语言当作一个“个性实足”的朋友,开始关注如何最大限度地利用每种语言各自的特性和合适的运用场景。
  

  

      

 
2008-08-29 7:08

   该博客以及搬迁至http://www.daniel-journey.com/ 本文的新地址为http://www.daniel-journey.com/archives/31

   以下内容翻译至《Learning Python》17章的Function Design Concepts一节。有些地方翻译的不到位,敬请谅解,建议阅读原文。
   当你开始使用函数的时候,你马上就会面对的一个问题是“如何把多个部件结合到一起”,例如如何把一个任务分解成多个有目的的函数(内聚),函数之间如何通讯(耦合)等等。在函数的设计过程中你需要考虑内聚(cohesion)、耦合(Coupling)、函数的大小等一系列问题,这些都会影响到函数结构的分析和设计。下面为Python的初学者提供几条通用的设计指南。
    耦合:使用“参数”做输入,用“返回”做输出。我们应该努力使一个函数独立于函数以外的东西。“参数”和“返回”通常都是使函数和外部隔离的最好的方法。
   耦合只在万不得已时候才使用全局变量。全局变量通常都是一种很差劲的函数间通讯的方式会导致若干函数间的相互依赖、时间选择(timing issue)等问题,并且最终从而使程序变得难以调试、维护和修改。
   耦合除非调用者期望,否则不要改变“可改变”的参数。函数能够改变部分传递过来的参数的值。但就和全局变量一样,这会导致调用和被调用函数间的依赖,从而使得函数变得特别的“特殊”和“易碎”。
   内聚:每个函数应该有它自己单一的、唯一的目的。一个设计良好的函数应该只做一件事情,对函数功能的描述用一句简单的话就可以加以总结。当你发现对某个函数的描述过于宽泛的(例如,这个函数实现了我所有的程序),或是描述内容中包含了很多的关联(例如,这个函数给店员增加提成并提交一个pizza订单),你可以考虑将这个函数分割成几个独立的更为简单的函数。否则就无法重用混杂在一起的代码。
   函数大小每个函数都应该相对的小。这个原则实际上会和上面那个内聚目标关联在一起的。如果你的函数需要占据多个页面话,最好能够分割他们。在Python编程中如果出现某个function要依赖很长的、嵌入很深的嵌入函数这通常就是设计有问题的信号。让函数保持小且简单。
     耦合:避免直接修改在另一个模块文件中的变量。作为参考,要谨记跟全局变量会耦合函数一样,跨多个模块文件修改变量会导致模块变得难以理解和重用。只要有可能就要使用存取方法,而不是直接的赋值语句。
下面这张图是对上述几条规则的总结。图的左边是函数的输入(包括了参数、全局变量、文件/流等等),图的右边是函数的输出(包括了返回语句、也变参数、全局变量)。很多函数设计人员更喜欢使用参数做为输入,用返回语句做为输出。

   当然对于之前的设计准则也会有不少的例外,例如Python中面向对象的支持。对象中的函数会通过self(也就是java和c中的this)来修改对象中的状态信息(self.name='bob')。如果没有了对象的支持,开发人员很容易会用全局变量(上例中的name就会引入一个global的name变量来替换)来实现几个函数间的相互调用和通讯,这样就会引入一些副作用和危险。

总结
   作者描述的这段内容超越了特定语言的,使用各种语言的开发人员都可以从以上的内容中汲取函数设计的经验。

 
2008-08-06 16:53
Refactoring – Martin Fowler
Design Patterns – Eric Gamma, John Vlissides etc. (GoF)
Refactoring to Patterns – Joshua Kerievsky
Extreme Programming Explained - Beck Kent
Test Driven Development by Example – Beck Kent
UML Distilled – Martin Fowler
Applying UML and Patterns – Craig Larman
Patterns of Enterprise Application Architecture – Martin Fowler
Domain Driven Design – Eric Evans
Object Design: Roles, Responsibilities and Collaboration – Rebecca Wirfs-Brock
Fit for Developing Software, Ward Cunningham etc.
The Mythical Man-Month – Fred Books
No silver bullet . 1987
Algorithm + Data Structure = Program, Niklaus Wirth
这些书籍都是超越具体语言的优秀作品。可惜读过的也就4本,读完的更是一本都没有,需要加油啊!!!
 
2008-08-06 6:09
今天整个下午都在对一个类进行重构,重构以后的代码引入了大量设计模式的使用(工厂模式、Strategy模式)。整个重构的收获还是很大的,不但实现了代码的优化,也通过这次重构的实践加深了我对面向对象、设计模式、TDD的理解。另外,还想起来设计模式解析 还没有读完。
   以下记录一些这次重构过程中参考到的一些资料
   http://misko.hevery.com/2008/07/30/top-10-things-which-make-your-code-hard-to-test/
   http://refcardz.dzone.com/refcardz/design-patterns?oid=ban00021-0
 
 
   
 
 
文章分类
 
   
 
文章存档
 
     
 
最新文章评论
  

如果我想学习了解单元测试的话,我想知道我学到什么水平、或者说了哪些内容后才可以
 

按照这种操作,创建分支,点击ok后,提示access to 'http://xxxx/svn' forbidden,这
 

今天刚了解了这个设计原则,摊开来讲的话,博大精深
 

能详细阐述一下就好了
 

thx
   
帮助中心 | 空间客服 | 投诉中心 | 空间协议
©2012 Baidu