`
qipvfgkh
  • 浏览: 4258 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
最近访客 更多访客>>
社区版块
存档分类
最新评论
文章列表
我的经验: 第一步,先搞清楚这段代码要实现什么样的功能或作用。 第二步,初略看懂代码中,主体类及其函数的相互关系。 第三步,编译出可运行的程序。 第四步,根据可运行看到的实际效果,在代码块中,加入相关注释或日志。 第五步,验证自己写的注释或日志是否正确。 第六步,根据代码,反馈自己的疑惑,与其他人进行交流。 第七步,根据大脑中的代码轮廓,详读代码。

重构心得(一)

目的:在不改变软件可观察行为的提前下,提高可理解性、降低其修改成本。 过程:在不改变软件可观察行为的提前下,调整其结构。 重点方向:消除重复代码。 重构应随时随地进行,不应该为重构而重构。 1、三次法则:当你对同一块代码,进行三次修改时,你就应该重构此部分代码。 2、如果收到一份错误报告,这就是需要重构的信号,因为显然代码还不够清晰-没有清晰到让你能一眼看出bug. 代码复审,有助于在开发团队中传播知识,也有助于让较有经验的开发者把经验传递给比较欠缺经验的人,并帮助更多人理解软件系统中的更多部分。 待续。。。
问题如下:    假如说你的产品已经卖出去了,而且用户很多(可能上千上万),你怎样处理你的代码才能达到尽量满足不同客户的需求,而程序又不会乱呢?    比如说,将源代码分成上千上万份,每个客户对应一份,当修改某个客户的要求时,去找到该份源码来修改..这是一种方法..另一种方法是将源代码只合成一种,不同客户的需求都在这里面改动..    上面两种方法肯定都是行不通的,那请问你们商业软件开发程序员们怎样处理这种状况呢?
今天到一公司去面试.开始的时候和人事部谈的很好...大约等了一个多小时,技术部的人员来面试我. 他向我问了几个问题,其中我回答的不是很好的问题是这个: 成立了一个软件开发组,软件需求已经写好了,问你在准备开发的过程中,要注意哪些方面才可能将以后的更改化做的最小? 注意:这里是软件需求已经写好,就是说回答跟软件需求没有一边关系才行! 本人经验尚浅,一时无法回答这个问题,所以被那人BS了一番..请问各位做过多年的兄台,以你们的经验来回答的话,又会有哪些方面..
Global site tag (gtag.js) - Google Analytics