p*****3
发帖数: 488 | 1
我们这非逼着写unit test和integration test。倒不是说这两种test没有用，但是搞
的有时候test code比production code还多就麻烦了。每次改点程序，refactoring一
下还得改test code. Integration test啥的还得每次想破头去call各种api创建环境然
后再verify,也不知道值不值得。 |
|
z****e
发帖数: 54598 | 2 这不就是大公司和小公司的区别
小公司无非那几个人，自己看懂就好了，但是大公司
上头要尽量让你的代码能被其它人接受，比如refactor
amazon已经过了startup阶段，掌舵的要把船开稳
差别就好比驾驶民航客机和战斗机的差别一样
战斗机飞行员一般被认为不适合当民航客机飞行员
因为倾向于做一些高风险的动作 |
|
z****e
发帖数: 54598 | 3 其实这些问题就是软件工程的经典问题
做过大项目的人都知道，需求分析阶段一定要放大力气投入
否则这个地方如果出现了什么问题，后面对于项目成败是决定性的
相比之下，编码开发阶段的重要性，其实是相当低的，就比测试高一点
一个人写不出来，两个人三个人给我上，加班加点给我上
都没有问题，怕就怕，需求分析给我搞错了，设计就错了
那乖乖，你后面怎么改，都是空的，因为改下去，伤筋动骨
这就是维护成本的问题，最后项目失败的主因普遍都是维护成本高居不下
重构代码是很幸福的一件事，谁都想做，但是实际上，大多数公司不愿意你做
因为business理解不了，为什么我需要投入资源去做一个已经搞定了的东西？
他们不会承认之前做的人写的代码的烂，那样等于承认自己的无能
但是实际上大多数项目的代码，其实是很糟糕的，这个糟糕不是说算法怎样
是设计根本就是错的，没有层次感，几千行代码凑在一起一个类，wtf
聪明人看到这种代码之后，基本上就琢磨着跑路了
所以愿意去refactor代码的公司是好公司
愿意给员工时间去做各种核心编码以外的事的上司是好上司
不过这些老公司用这些破烂也有好处，给了新公司以发展的余地
新公司可以通过结... 阅读全帖 |
|
c*********e
发帖数: 16335 | 4 那要看你找到什么样的工作了。新手很难有人要你从头写code的，一般让你做qa或者改
一下legacy code.如果你对ood,refactoring没啥概念的话，就麻烦了。如果要从头写
code那要你设计database有几个table,每个的schema之类的，要你设计几个interface,
几个class,这些都是最开始的活，让新手做，出错了，后面的就全错。 |
|
c*********e
发帖数: 16335 | 5 高手一般高在整个設計上，ood的概念，refactoring前人的code,就是architect搞的那
些高屋建瓴的东西。
也有的会说自己会multi-threading,reflection,delegate,singleton,fp |
|
m******t
发帖数: 2416 | 6
I run eclipse and vim at the same time bridged with eclim.
It gives me the best of both - for usual heavy coding I can
do it in vim comfortably, and for massive refactoring
and a couple other scenarios I switch to eclipse. |
|
D*******a
发帖数: 3688 | 7 【 以下文字转载自 Apple 讨论区 】
发信人: DrumMania (羊城大少), 信区: Apple
标 题: Re: Re: MAC系统下 对于程序猿,最好用的鼠标是哪款阿?谢谢了
发信站: BBS 未名空间站 (Wed Nov 17 12:19:08 2010, 美东)
I don't understand why unix programmers still stick to vi/emacs. While they
may be handy text editors but if one is working on something of 500k to 1m
code lines scale it is becoming very inefficient (e.g. context, find
declaration, type/call hierarchy, refactoring support, debugging...etc).
I develop C++ under Linux and the best I can find is eclipse/CDT... 阅读全帖 |
|
l******e
发帖数: 12192 | 8 虽然我用vim，但是搞开发还得是ide
autocompletion是一个，但是refactor、自动文档啥的确实不如ide |
|
wy
发帖数: 14511 | 9 其实refactoring啥的用熟了vim也很容易啊。不就是find & replace么？
lol |
|
T*o
发帖数: 363 | 10 haha, dude..
that's only one of refactoring.. |
|
|
p******g
发帖数: 347 | 12 【 以下文字转载自 Programming 讨论区 】
发信人: paperdog (I've Never Been To Me), 信区: Programming
标 题: netbeans compile on save
发信站: BBS 未名空间站 (Tue Mar 8 10:20:37 2011, 美东)
most of the time it works. however, it doesn't some time. and when it doesn'
t work, it will screw up things like refactoring (java), hot swap code when
attaching to remote debugger, and it is not able to detect simple errors
such as missing class method.
anyone has the similar experience? any hint? |
|
mw
发帖数: 525 | 13 computer scientists 用vi/vim，每天在各个不同的服务器上倒腾，写的都是核心的代
码，统共就那么几千行，压根不需要project management
所有其他的scientists用emacs，因为emacs是IDE for all. 写代码，调python，ess，
matlab，latex，从proof of concept到最后写paper全都可以在一个editor下面完成
software engineer用eclipse/netbean，要组织大型项目，要refactoring，一个
function可能在无数的地方被overload过，这些vi/emacs都支持不得不好
application developer, 各大咨询公司的Consultants们用visual studio。这样的工
作‘怎么编’不是重点，跟用户沟通，了解‘编什么’才是难点。所以consultants们
是一半engineer一半sales，msvs是最idiot proof的IDE，用在这里最合适
manager用ppt，你懂的。 |
|
|
g*****g
发帖数: 34805 | 15 yep, just some thoughts for what I did last couple of days.
Somehow I felt it would be better if I just rewrite it,
but more than often you have no options. |
|
g*****g
发帖数: 34805 | 16
We are talking about 3000+ lines of code here, which will take at least
2 weeks for a complete rewrite and proper unit testing. Unfortunately
I don't have that much time. For each release, we usually have to finish the
development phase in 2 months, and that usually includes adding a big new
feature and several other improvements, and I can't afford 2
weeks on one class. With a couple of days, I am able to break it down to
several small classes, remove some instance variables, break down some
l |
|
g*****g
发帖数: 34805 | 17 6. Many god classes pack everything together, but it's better to
keep them in different function groups. We often see GUI classes
doing that. It's nothing wrong when the class is short and everything
in a page of two (couple of hundred lines), but when it's getting
bigger, time to apply MVC pattern. For other long classes that
have no obvious pattern to apply, check the instance variables, you'll
see some variables are used intensively in some functions, and rarely in
others. That's a good smell |
|
c*****t
发帖数: 1879 | 18 其实争这个没必要了。以前（Eclipse 3.1 以前），Eclipse 没有这种
highlight，所以看 code 没 prefix/suffix 很费劲。现在有 highlight
instance variable 就不是太大问题。
当初用 NetBeans 2.0 的时候（没 refactor），我处理某同事的 code，
那个叫累。不单他采用 a, b, 等 instance variable，而且 declaration
是在 class 中间（不是开头也不是结尾），那个差点没气死。好在他离
开了，再改下去要疯掉。另外那个出现 abc = abc 的问题也挺讨厌。问题
是写这程序的家伙的东西出现 1w 多 warning 。
至于其它语言，如果没有合适的 highlighter，prefix/suffix 还是
相当重要的。 |
|
c*****t
发帖数: 1879 | 19 本来一直用 Eclipse 的 CDT，但是不爽。狠下心装了 VS 2008，结果更不爽。
VS 2008 不自带 refactor C/C++ 的工具。没 variable / function highlight
（点了某 variable 以后，自动 highlight 屏幕上用到该 variable 的地方）。
另外 ctrl + arrow 一下跳过整个词，用起来很不方便。
有什么更好的 C/C++ IDE？thx |
|
w****n
发帖数: 127 | 20 The most agile developers, however, are those who approach programming with
a firm grounding in computer science. Likewise, I suspect that the current
abundance of Web tools is a sign that the Wild, Wild West of Web development
is coming to an end. Increasingly, ad hoc projects and cobbled-together
tools will give way to those that emphasize the values and methods of
traditional software development, such as design patterns, code reuse, and
refactorability.
But you tell me. If you're in charge o |
|
c*****t
发帖数: 1879 | 21 所有在这里的 test case 都是测试过的（不过 parser 部分还在 svn 里，
我现在还差将 compressed table 放进 code generator）。
http://code.google.com/p/cookcc/source/browse/trunk/tests/
code generator 现在只有 Java 。其实弄 C/C++ 也不是太难（毕竟是
template approach）。
现在用的是 xml 输入。主要是 yacc/lex 的输入文件其实很复杂。手工写
parser 太困难。至于自动 generate，俺不正在写嘛。
至于 mix 代码和 grammar 。我有个想法，不适合 C/C++，但是很适合
Java / C# / Python 。这样可以直接利用现成的 Java/C#/Python editor
（同时该 editor 的功能，比如 refactoring，context sensitive help
等）。我已经手工推出个 prototype，就差 implementation 。 |
|
P*****f
发帖数: 2272 | 22 eclipse的 refactor比如函数改名啥的还是很方便.
的问
颜色
就是 |
|
g*****g
发帖数: 34805 | 23 eclipse的refactor相当强, VS似乎没有那么方便。 |
|
t****t
发帖数: 6806 | 24 我不是跟你较劲, 我是说IDE的主要用处不在这里. 你说的这些, 都是一个好一点的编
辑器就应该有的功能. 你总不能说vim是个IDE吧. 另外autocomplete我倒是没觉得有什
么强大的.
后面说的refactor, class view等等, 才是IDE主要的用处. |
|
s***e
发帖数: 122 | 25 这就是各花入各眼吧，auto complete对我非常有用，因为我经常要用第三方库，你要
是让我每次调用一次api都去查一下帮助，那不累死也烦死了。你要说refactor, class
view(也就是我说的看project的结构，而且还不止这一种view而已)也是IDE的重要用
处，我同意，而且我还得说这还不止，只是那些自己用得多的就印象最深了。vim就算
不说是IDE，它实现的那些功能不也是从成功的IDE学来的吗？ |
|
N********n
发帖数: 8363 | 26
看了这么多发现都没说到点上，一个IDE能否强大取决于其支持的语言而不是
这个IDE本身。C++大把DIRECTIVES的特性在理论上就是不能REFACTOR，无法
和JAVA，C#比，不是IDE做不出来。 |
|
g*****g
发帖数: 34805 | 27 有难度也有程度的区别，C++的宏使得一些refactor难以进行。 |
|
r****t
发帖数: 10904 | 28 你们说的都很高深，但是我要提醒一下 python 是强类型的，perl 才是弱类型的。你这个
说法不知道是哪里听来的。而且我同意对弱类型的搞 refactor 不现实。 |
|
N**D
发帖数: 10322 | 29 bug comes from refactoring |
|
g*********s
发帖数: 1782 | 30 有做refactoring的工具。
另外不能加上namespace，然后用C++编译器么？ |
|
k***r
发帖数: 4260 | 31 when I refactor Python code. This is when I truly miss Java!
Any recommendations for tools and methodologies? Extensive
automated tests is probably the only remedy that doesn't really
solve any problem but to help you catch them early. |
|
I*******e
发帖数: 1879 | 32 ☆─────────────────────────────────────☆
koder (koder) 于 (Fri Feb 6 12:11:27 2009) 提到:
准备把一个project用Java重新写了，好在东西不太多。有点郁闷。呼唤statically
typed
Python/Jython
☆─────────────────────────────────────☆
arsablue (真神) 于 (Fri Feb 6 22:04:43 2009) 提到:
我幹過把Java 改成 Python, 挺方便的 :D
☆─────────────────────────────────────☆
jobseek (seeking+jobs) 于 (Fri Feb 6 22:13:33 2009) 提到:
改什么改，直接用jython就得了
☆─────────────────────────────────────☆
koder (koder) 于 (Fri Feb 6 22:59:01 2009) 提到:
最早Python |
|
X****r
发帖数: 3557 | 33 个人看法：
1.想好了再写。先确定设计和接口再具体实现。设计和接口注意一定的通用性和扩展性
。实现的时候注意封装而不要抄近路。当你感到有迫切的抄近路的需求的时候多半说明
你的设计有问题。随着代码的发展和需求的变化原来的设计和接口一定会过时，所以要
有重构(refactoring)是开发中的常态的准备。
2.测试，测试，测试！从单元测试到集成测试，都要自动化，并且覆盖面尽可能得广。
测试是软件质量的第一道也是最后一道防线。
3.Code defensively（不知道中文怎么说）。首先是代码单元（比如函数和方法）必须
完全实现所宣示的功能而不依赖于额外的假设，比如按一定格式输出一个数，如果这个例程
没有声明只接受一定范围的数的话（除非有这样的必要，不然一般也不应该有这样的声
明），即使在当前的程序里这个数不可能超出这个范围也不要依赖于这个条件。更进一步
的，即使输入不完全符合接口，根据情况也可以考虑尽可能地完成操作，不过这种情况下要
留下记录，而且未必适合所有情况。
4.代码的可读性也很重要。没有比改一段自己还不太明白的代码更容易造成隐患的了。 |
|
g*****g
发帖数: 34805 | 34 Addison Wesley - Refactoring Improving the Design of Existing Code
You can check this book for examples. I can't sum up better. |
|
d****p
发帖数: 685 | 35 Haven't used Eclipse for C++ yet but it is really awesome in term of code
refactoring. Other IDE I used, such as Xcode or Visual Studio, are no way
near its half. |
|
D*******a
发帖数: 3688 | 36 问题是很多时候，东西quick & dirty地做完了之后，就这么留下了。没啥人有那个功
夫去refactor或者重写，反正谁接手谁遭殃。所以还不如一开始就用一个可读性更强的
玩意。
再说了，很多时候写script未必就一定比java/c#这种编译型快速开发的语言快。其中
一个原因就是调试麻烦，而且容易出bug。 |
|
t****t
发帖数: 6806 | 37 it is not designed to be refactored or maintained or rewritten or readable. |
|
b********n
发帖数: 609 | 38 why? as long as u don't break old interface and there's no performance
degradation the customers will be fine. ever heard of refactoring? |
|
m***t
发帖数: 254 | 39 这个朋友写java的， 作application多了，想转底层一点的东西。 我最近写refactor
一些legacy code正恼火， 于是说起来这个程序员的素养。市场的需要和程序员的素养
有多大的关系呢。 程序员的基本素养有三方面， 算法，语言／软件工程，系统。但具
备这三方面的程序员不一定能适应市场的需要。 比如现在， 大家都在拼命上mobile的
船， 满世界都是要javascript, webkit. 这种大干快上的空气， 市场不让大家坐下来
好好写， 而是被product追着death march。 一个kernel很熟的人， 在这个市场上可
能还不如写过几个iphone游戏的开心。所以追求底层或者一些市场上不需要的东西，
有多大的价值呢？
话说回来， 要没有mobile这个大泡泡， 大家可能不知道要被裁多少。 所以对技术太
有追求可能是个误区，或者是个自娱自乐的项目。 认为技术好就等于能赚到钱太天真
了。 |
|
|
g*****g
发帖数: 34805 | 41 我老一直说的是，要想吃程序员这碗饭，还是要看看市场的。
底层开发的需求永远是相对小的，而且绝对不是有些人想的kernel很熟
C/C++很熟干啥很容易。
一个是但凡senior的工作都要实际经验，没有面试就混不过去。
另一个是具体到语言的类库，框架也是一大堆东西，不是说一下子
就能上手的。
refactor |
|
z****e
发帖数: 54598 | 42 你技术好了是为了什么？
技术只是工具，你总得为了实现什么而搞好技术
refactor |
|
i****l
发帖数: 78 | 43 一个底层做得好的programmer绝不会差钱
现在缺乏底层、上层都搞得好的人
refactor |
|
N********n
发帖数: 8363 | 44 Theoretically impossible if you consider the cases where there might be a
whole bunch "#ifdef" and "#ifndef" in your code. You won't even know what
the content of the C code really is.
It's crazy macros like these making C-kind languages un-refactorable and
badly designed languages in general. |
|
d****p
发帖数: 685 | 45 Agree - naming is a part of design. If you feel confused about choosing a
good name, chances are your design
model is not straightforward and clean.
Very often, if names appear too long, like
isLockReleasedWhenCurrentClientWasDeletedByAReferencingClientInPassiveInvoca
tion, you need to refactor
stuff more or less.
My experience is if we don't shorthand names while the name appears
reasonably long (< 15/20 chars),
perhaps we get things right. |
|
