TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Things You Should Never Do, Part I (2000)

174 点作者 joseflavio超过 11 年前

31 条评论

bguthrie超过 11 年前
If you absolutely must rewrite, consider isolating and replacing components piecemeal rather than scrapping the whole thing and starting over. You don&#x27;t eat the whole cost at once, you can keep moving forward with new features if needed, and you get more modular architecture to boot.<p>It&#x27;s called the Strangler Pattern. <a href="http://www.martinfowler.com/bliki/StranglerApplication.html" rel="nofollow">http:&#x2F;&#x2F;www.martinfowler.com&#x2F;bliki&#x2F;StranglerApplication.html</a>
评论 #6328903 未加载
评论 #6327861 未加载
评论 #6328274 未加载
评论 #6328815 未加载
评论 #6327898 未加载
moron4hire超过 11 年前
This article, when I originally read it 5 years ago, was hugely influential to me. It completely convinced me of the superiority of refactoring existing systems to an ideal over rewriting. It doesn&#x27;t take anywhere near as much time to fix cruft as it is to create a system from scratch and try to avoid your own cruft. But it&#x27;s scary and it&#x27;s an unknown. But if you approach it with courage, it falls quite easily.<p>EDIT: refactoring large systems has also convinced me of the superiority of statically typed programming languages for large projects. When I break code, I want it to break as hard as possible. I want to see absolutely everywhere function XYZ is called, and one way to do that is to rename XYZ to XYZ___ and see where all of the compiler errors show up.
评论 #6328054 未加载
评论 #6328549 未加载
romaniv超过 11 年前
This is the most overrated and overquoted piece of (bad) software engineering advice ever. Sure, it&#x27;s harder to read unfamiliar code than write new code, because your understand the reasoning behind the new code. That&#x27;s exactly why rewrites often make much more sense than labor-intensive incremental changes.<p>I&#x27;ve had many real-life situations where I successfully chain-deleted thousands of lines of legacy code and replaced it with some sub-100-line method that simply worked. All that without understanding how legacy code works. You&#x27;re wondering what&#x27;s the secret here? Instead of trying to deduce the undocumented logic behind legacy code I gathered current requirements and implemented them in the simplest way possible.<p>In most cases the results were dramatically more readable, because I used build-in language capabilities and standard libraries whereas old code spectacularly failed to do so. Also, I didn&#x27;t have to worry about requirements that were no longer relevant.
评论 #6328407 未加载
评论 #6328334 未加载
评论 #6328497 未加载
评论 #6329594 未加载
评论 #6330859 未加载
评论 #6328683 未加载
RogerL超过 11 年前
We have plenty of empirical evidence that you can rewrite from scratch - every competing product in the marketplace is essentially a &#x27;rewrite from scratch&#x27; from the perspective of all the other products. Almost very start up poster on here is &#x27;rewriting&#x27; an app in that sense.<p>If you can&#x27;t &#x27;rewrite from scratch&#x27; (i.e. write a new app) you probably don&#x27;t have very good programmers (they are only comfortable bandaiding and throwing a few routines in existing code), or, perhaps, management is tying their hands someway. So, I don&#x27;t buy into the horror stories. Well, I buy that they exist, just not that they should drive my decisions.<p>Of course, you should expect the cost of your new app to be about the same as entering the business cold. It&#x27;s particularly difficult to meet every requirement&#x2F;feature&#x2F;bug of the old system. Orgs get fossilized around features. If you were to download and install a new IDE you&#x27;d expect it to have different features from the old one. You will miss some of the old features, but presumably the new features more than make up for it (otherwise why would you switch). Yet, when we upgrade apps, it&#x27;s &quot;remove nothing at any cost&quot;. It doesn&#x27;t necessarily make a lot of sense. It can take enormous effort to re-implement some broken feature as opposed to just offering a new way to do things.<p>None of that is to say I blithely throw code away. I did, once, amidst a bunch of hue and cry of &#x27;oh no&#x27;, but it was the correct decision because the old system was hacked together by &#x27;weekend programmer&#x27; (my boss at the time who was very smart but learned programming from a book). I turned it into a modular, decoupled system, and most of those parts got reused over and over in different parts of our vertical. If you have a plan, and the old code doesn&#x27;t, it can pay off.<p>There&#x27;s more to be said, but this is a wall of text already. Every day I work in the refactor mode, even while mostly adding new features. Its an extremely powerful idiom. But I also have my eye on code that really needs to go to the big bit bucket in the sky. No one understands it, every fix introduces new bugs, and what it is trying to do is very well served by existing open source code, or code be written from scratch.
评论 #6328376 未加载
评论 #6328249 未加载
评论 #6328097 未加载
评论 #6329760 未加载
评论 #6328638 未加载
评论 #6328355 未加载
shubb超过 11 年前
This is an interesting article because though the rewrite killed Netscape, the rewrite became Firefox, possibly the most popular browser in the world.<p>It became that way because developers were able to run laps round Microsoft (who clung to an old, bad codebase).<p>And because it was a redesign not just a rewrite, and the redesign redefined what browsers did.<p>Firefox, as we use it today is a rewrite of that rewrite, with god forbid far less features than the original!<p>I wonder, with a little more money behind Netscape, and without anti-competitive MS browser bundling, would Joel&#x27;s piece look so correct in hindsight?
评论 #6328652 未加载
评论 #6329978 未加载
评论 #6331510 未加载
评论 #6328448 未加载
freework超过 11 年前
If I had superpowers that allowed me to delete one website from the in internet forever, it would be this article.<p>I find the &quot;complete code rewrite&quot; to be the most powerful programming technique I have in my repertoire.<p>In 2007 I wrote an application called FlightLogg.in. It was basically a clone of logshare.com that I wrote in my spare time with PHP. It was my first really &#x27;big&#x27; project. You can see the code here: <a href="https://github.com/priestc/old-flightloggin" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;priestc&#x2F;old-flightloggin</a><p>If you look around that codebase, you&#x27;ll see nothing but spaghetti. I starting writing the app in late 2007, back when you could say I was a &#x27;noob&#x27; (so noobish in fact, I didn&#x27;t even use source control). At the time I thought I was writing the most awesome code ever. By the middle of 2008, that project had reached a state where it was pretty much &#x27;done&#x27;. I then stopped working on that codebase, and moved on to other projects.<p>Then by late 2008, FlightLogg.in&#x27;s traffic had kept growing, and there was a list of bugs and really cool features that I had thought up since I last touched the codebase a few months earlier. I set out to continue development on the PHP codebase. The problem was that in the past few months I&#x27;ve been away, I had become a better programmer, and the sight of that spaghetti code made me vomit.<p>It was less about the code being &#x27;bad&#x27;, and more about me not remembering how things worked. The small set of fetures and fixes I wanted to make would have taken me a few hours to do back when I was first working on this codebase. Since a few months time had passed, it was taking me much longer.<p>Eventually I decided to do a complete code rewrite. This was before I ever saw that Joel Spolsky article. The new codebase is here: <a href="https://github.com/priestc/flightloggin2" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;priestc&#x2F;flightloggin2</a> It took me roughtly the same amount of time to build the new codebase as it did the old codebase.<p>Ever since, each and every project I take on, I accept the reality of doing a complete code rewrite might come up. For my own personal projects, I do complete code rewrites all the time. On the other hand, at the various jobs I&#x27;ve had over the years, its a much different story. If I came into work today and brought up the idea of doing a complete code rewrite, I&#x27;d either get laughed out of the room, or even worse, threatened with being fired, thanks to this Joel Spolsky article. Thanks Joel.
评论 #6328950 未加载
评论 #6328961 未加载
评论 #6328894 未加载
评论 #6328991 未加载
评论 #6329128 未加载
评论 #6330117 未加载
评论 #6329580 未加载
评论 #6331161 未加载
评论 #6329202 未加载
评论 #6328971 未加载
zimpenfish超过 11 年前
If you read jwz&#x27;s output, it&#x27;s not that &quot;Mozilla decided to rewrite it&quot;, it&#x27;s more like &quot;bunch of idiots who didn&#x27;t know what they were doing took over and tried to rewrite things whilst ignoring all the sane advice&quot;.
hvs超过 11 年前
Great article that is still relevant today (sadly, I remember reading it when it first came out). If you really, really feel the need to rewrite from scratch, I recommend instead picking up a copy of &quot;Working Effectively with Legacy Code&quot; by Michael Feathers [1]. It will give you ways to improve those terrible code bases while not throwing out the existing code. Plus you&#x27;ll still get that &quot;new car smell&quot; of working on your code.<p>[1] <a href="http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;Working-Effectively-Legacy-Michael-Fea...</a>
TheRealDunkirk超过 11 年前
Seems to me that a lot of what Joel was complaining about could be mitigated by some well-placed comments in the code. &quot;This function is 2 pages long! Oh, this part does that, and THIS part does THAT. I see what&#x27;s going on. This is all good.&quot;<p>This seems to be something people don&#x27;t even bother to argue about any more. Everyone&#x27;s given up! I don&#x27;t do much myself, but no one I have worked with over the past 20 years has done ANY. Scary. I&#x27;ve only recently moved out of engineering to a &quot;real&quot; coding firm, but I&#x27;m still not seeing it.<p>I guess coders, in general, either think that everyone should immediately understand WHY code should be doing what it&#x27;s doing, or be fired, or they think it&#x27;s job security to not share these details.
评论 #6328175 未加载
评论 #6328608 未加载
ronilan超过 11 年前
The rewrite meant Netscape 6 used Gecko, which brought us Firefox, which revived the browser wars, which brought us the WebKit browsers.<p>History is a twisted mess...
评论 #6328273 未加载
GVIrish超过 11 年前
One of the huge pitfalls in the writing from scratch situation is that often times the original application didn&#x27;t have adequate requirements. So the team sets about building the new version without a comprehensive and detailed understanding of what the old version did. That alone can lead to huge timeline and cost overruns.<p>And if your organization didn&#x27;t learn from its mistakes the first time around, it&#x27;ll make many of the same mistakes the second time around, except this time they&#x27;ll be concentrated in one monster release rather than a number of smaller releases. Especially if the original developers have left.
brudgers超过 11 年前
<i>It is easier to write an incorrect program than understand a correct one.</i><p>-- Alan J. Perlis, Epigram 7
danso超过 11 年前
I picked up the Pragmatic Programmer some time ago and among the great lessons it had, the one that sticks with me every day at the code editor is: You spend far more time reading your code than you will writing it.<p>With that in mind, it makes it easy to write tests and more comprehensible variable names (still thinking and re-thinking how to best do documentation...was checking out github&#x27;s Ruby guide and Tomdoc yesterday <a href="http://tomdoc.org/" rel="nofollow">http:&#x2F;&#x2F;tomdoc.org&#x2F;</a>)
评论 #6327629 未加载
chatman超过 11 年前
This is esp. true for dynamically typed languages.<p>An IDE helps a lot more deterministically for a static typed language like Java.
评论 #6327779 未加载
评论 #6327883 未加载
评论 #6327684 未加载
eldavido超过 11 年前
This article shows how much progress we&#x27;ve made in languages and tools over 13 years. It&#x27;s vastly more difficult to read large, c++ codebases with tons of memory allocation, pointer arithmetic, macros, and complex locking schemes than much of the Java&#x2F;Ruby&#x2F;other mainstream language code written today.<p>Also, it strikes me that this was written in an era where most large-scale systems were giant monolithic codebases sharing an address space, rather than distributed groups of services communicating over a network. Distributed systems are inherently easier to rewrite because a lot of the hard problems around abstraction, state, representation, etc. already have to have been solved by the architecture -- you can&#x27;t exactly pass a naked void* over the wire.
semjada超过 11 年前
So he was wrong then? NS6&#x2F;firefox seems to be doing alright today... Rewriting your OWN codebase from scratch certainly makes it get better with each iteration - as long as &quot;from scratch&quot; implies constantly referring to the old code.
评论 #6328912 未加载
kbd超过 11 年前
This is from 2000. People need to stop posting old articles without putting a date in the title.
评论 #6329252 未加载
etler超过 11 年前
The new historical perspective on this is very interesting. The code rewrite killed the company, but it gave birth to mozilla, which came back to topple IE from its throne and help bring through a new renaissance of browser development. If they hadn&#x27;t rewritten their code how would have history changed? Would we be where we are today? How many years behind would that setback have put us? The release of Firefox was instrumental at disrupting and evolving the web. With a poor code base could they have done that as effectively as they did?<p>A company may be transient, and killed by choices that hurt them in the short run, but will support them in the long run. But good open source code is eternal. The quality speaks for itself. Their decision may have killed their company but it was astronomical for the web. From a higher level perspective, they did the right thing, and it shows that good code is so powerful, it can even outlive the company that made it.
评论 #6329612 未加载
lxe超过 11 年前
I know I don&#x27;t have the expertise to argue with Joel Spolsky about software engineering, and while I agree that rewriting from scratch is a huge strategic mistake, it is hardly the worst.<p>Have any of you ever worked for a large engineering firm with a sizable operating budget? There are many &quot;strategic&quot; errors that happen on the daily basis in those kind of shops that range from software stack choices to engineering process drowned in bureaucracy. Rewriting code is hardly the worst.<p>Also, don&#x27;t assume that even though rewriting code is bad for business, it&#x27;s bad overall.<p>You iterate, and learn from mistakes you made that were caused by the lack of experience at the time previous code was written.<p>You de-couple components during a rewrite and eliminate unnecessary features, drastically improving maintainability.<p>You make it easier for other programmers (and yourself) to read the code.<p>You can alter core platform pieces, make tech stack alterations, and eliminate reliance on legacy components during a rewrite.<p>The list goes on...
ht_th超过 11 年前
At first sight, this statement seems odd. For sure, writing a text is more difficult than reading it, and programming is writing a text. But a different kind of text. A program is written to communicate ideas with a computer first, and with humans second, whereas an article or novel is written to communicate ideas with humans only. What if we would have a programming language that allowed us to write to communicate ideas to humans first and have the compiler&#x2F;interpreter automate the communicating with the computer?<p>Or could it be that a non-trivial program is essentially more complex than an article or novel or any other regular text we encounter daily?<p>Or is reading a program similar to reading a text in an unknown language? Like trying to read some Roman text when you don&#x27;t really know Latin, but you&#x27;ve access to a Latin-English dictionary and a good grasp of history and the context and topic of the Latin text?
评论 #6327907 未加载
cehlen超过 11 年前
Code may not rust overtime but it does become harder to maintain and more importantly harder to find quality innovative people willing to work on it. I would guess that very few of the people making a pro argument for Joel Spolsky’s article would be willing to support 1970’s COBOL banking software for a living.
YZF超过 11 年前
It&#x27;s not black and white. There are situations where investing in your old code base is throwing good money after bad and there are situations where the old code base can be better. You need to make educated decisions not blindly follow rules.<p>Refactoring can be a problem because you&#x27;re always working towards some local minima. It&#x27;s a little bit like the decision to renovate an old house vs. raze it and build a new one or buy an old car&#x2F;boat and repair it.<p>There&#x27;s a good discussion of various factors here: <a href="http://programmers.stackexchange.com/questions/6268/when-is-a-big-rewrite-the-answer" rel="nofollow">http:&#x2F;&#x2F;programmers.stackexchange.com&#x2F;questions&#x2F;6268&#x2F;when-is-...</a>
drderidder超过 11 年前
There&#x27;s a time and place for everything. Firefox and Mac OS X are examples of successful rewrites. I&#x27;ve had some positive experiences with re-writing certain things from scratch. Not to downplay the issues Joel raised back in 2000, but if a product is tied to a technology that&#x27;s limiting its effectiveness, and better alternatives have become available, a next-generation implementation bears consideration. I think companies that fail to iterate and evolve this way will ultimately stagnate.
mtdewcmu超过 11 年前
I can&#x27;t imagine how a codebase could be so horribly bad that it doesn&#x27;t do even one thing right, and you have to throw it out wholesale. That is, assuming it was good enough to ship at some point.<p>I don&#x27;t like to feel that I&#x27;m wasting my time doing rework, and vulnerable to getting in way too deep with no backup plan. I&#x27;d definitely want to rewrite in pieces without ever discarding the whole, even if eventually there might come a day when every single piece has been rewritten.
ryanackley超过 11 年前
You usually only hear the catastrophic failure anecdotes. Large, complex, yet successful rewrites I know about:<p>* The Windows kernel. From my understanding, Windows NT was a completely different kernel from Windows 95 and eventually replaced it in Windows XP.<p>* Coldfusion, I used to work with an ex-Adobe guy that told us the story how this was rewritten from scratch at one point. From C++ to Java<p>* I used to work on the SQL Server team at Microsoft. We completely rewrote the Reporting Services product between the 2005 and 2008 releases.
评论 #6329688 未加载
评论 #6330063 未加载
kailuowang超过 11 年前
I always deem readability the number one priority in writing working code. Readability is not just about understanding what the code in front of you is doing but also easiness to find where in code a particular business logic was implemented. Code written with readability as the top priority has the best chance of avoiding the need for a full re-write. And even if it needs to be re-written from scratch, it&#x27;s so much easier with a readable codebase.
bluedino超过 11 年前
How does this apply to a platform change? Say, going from an application written on 80&#x27;s UNIX hardware that&#x27;s still going strong today on a 9-year old Itanium system?<p>Start writing replacements for individual modules? The original programmers are set to retire in another 5 years and then it&#x27;s going to get really, really ugly.
igl超过 11 年前
April 06, 2000.<p>Any progress report on this?
评论 #6327825 未加载
评论 #6328044 未加载
lowmagnet超过 11 年前
(2000)
yuhong超过 11 年前
An example is legacy color parsing. I personally figured out where legacy color parsing is in the Netscape classic source: <a href="http://stackoverflow.com/questions/8318911/why-does-html-think-chucknorris-is-a-color/12630675#12630675" rel="nofollow">http:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;8318911&#x2F;why-does-html-thi...</a><p>It is so subtle even Netscape&#x27;s own Gecko rewrite did not get it completely right the first time: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=121738" rel="nofollow">https:&#x2F;&#x2F;bugzilla.mozilla.org&#x2F;show_bug.cgi?id=121738</a>
powertower超过 11 年前
Does anyone have a good way to distinguish between -<p>A) Rewriting the codebase.<p>B) Fixing &amp; modularizing the codebase - breaking it up into self-contained units&#x2F;parts while improving, cleaning, and modernizing them?<p>Because if you throw away the edge-case of completely starting from scratch, B) can easily be seen as A) and vice versa.<p>Is there a thin line here?<p>(*I have a 200K line C#&#x2F;.NET app that will be evolving and pivoting with it&#x27;s next major version).