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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Code Age vs. Time to Recall

30 点作者 trwhite超过 4 年前

8 条评论

l0b0超过 4 年前
&gt; There are step-by-step instructions in the comments explaining what&#x27;s going on.<p>This is a big red flag. As everyone has been saying since decades, comments are for the <i>why,</i> not the <i>what.</i><p>Also, recall should be upper bound to the time it takes to find the relevant commit message. Having to actually recall from my brain why something was done is a terrible way to work: presumably at most two people in the original group know why, the people may not even be there anymore, and recall is far from perfect.
评论 #25628966 未加载
评论 #25627951 未加载
评论 #25628655 未加载
war1025超过 4 年前
Got a real kick out of this blog post as it seems to imply that code written two years ago is &quot;old&quot;.<p>I&#x27;ve been surprised quite a few times in the past year that what I thought was &quot;relatively new&quot; code actually ended up being 5+ years old when I went back and looked at the commit history.<p>Just me getting old I guess.
评论 #25627289 未加载
Alterlife超过 4 年前
It isn&#x27;t technical debt any more if you can default on it.<p>It&#x27;s stable? It&#x27;s fast? It works? No bugs have been reported on it for years?<p>Regardless of how I &#x27;feel&#x27; about that piece of code, I objectively should _not_ touch it.
评论 #25628901 未加载
dluan超过 4 年前
i&#x27;ve been thinking about this a lot after my post-burnout brain has slowed considerably as i&#x27;ve gotten older (30). i definitely know i&#x27;m not as quick as i used to be.<p>i&#x27;ve noticed that even after 3 weeks, code that i wrote deep in the flow zone will feel completely foreign, so it&#x27;s more like a linear curve up and then it plateaus. however, i feel like at my current trend, by the time i&#x27;m 50 code i write the day before will feel completely foreign.<p>i used to watch this trend when i worked with programmers older than me, but i never realized just how badly it would hit me.
评论 #25629200 未加载
评论 #25628133 未加载
clumsysmurf超过 4 年前
I think Adam Tornhill has a nice take on this. He recommends tech debt not be quantified as such, but encourages focusing on areas with high complexity and large churn<p>GOTO 2019 • Prioritizing Technical Debt as if Time and Money Matters • Adam Tornhill <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=fl4aZ2KXBsQ" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=fl4aZ2KXBsQ</a>
keyle超过 4 年前
What I found really impacts &quot;time to recall&quot; is the language or framework used.<p>For example, Go, not hard to recall, due to how rigid the language is with gofmt etc.<p>On the other hand, Perl, forget even trying to understand what drug you were on that day when you wrote this.<p>Then there is the extinct, like opening an old app made in cakePHP or backbone...<p>That&#x27;s why I&#x27;m a proponent of ESLint, Gofmt, etc.<p>Pain today, pleasure later, hopefully.
rutthenut超过 4 年前
Definitely got something here - legacy code becomes that way by mostly working, not by being constantly changed or rewritten. Though constant changes may also be applied to legacy code.<p>&gt;&gt; One common developer bias is that old code is bad. You&#x27;ve never heard anyone say the phrase &quot;legacy code&quot; without contempt in their tone &gt;&gt;<p>As for the &#x27;code age&#x27; point, I&#x27;d think it is more related to recency of the requirements, when was that problem domain last worked on and understood.<p>So maybe the issue points to clarity of requirements capture, and perhaps the coding&#x2F;design corresponding to the requirements.<p>Another commenter referred to automated testing, which hits on having test cases to match the requirements. With that level of functional documentation, the code is likely to be easier to understand.
xupybd超过 4 年前
I&#x27;ve seen this happen not because the code is hard to read but brittle. We tried and tried to clean it up but it was hard to tell if we were making a dent on code quality. Then a third party added a test system and we started writing automated tests. The code was a dream to work with.<p>I cannot overstate how much better it was to work with.<p>There were internal attitudes that prevented me from pushing for tests. Oh and the fact that the company had not used them in the past. But I regret not pushing hard for testing.