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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

That coworker who never stops refactoring

363 点作者 mcrittenden将近 5 年前

66 条评论

renewiltord将近 5 年前
I don&#x27;t want a teammate like this. I want to work in a team where we all do this <i>sometimes</i>. Fortunately, I have that team. I think if I hired people and then determined how I could use them best I&#x27;ve already failed vs. if I see where I could use help the most and then hired the guy who can do that the best.<p>Every engineer I know who I respected for this behaviour also delivered boatloads of functionality independent from &quot;improving dev productivity 25%&quot; which kinda makes sense since if you go around refactoring everything you kinda know the whole thing. Also, how do you even know if you&#x27;ve improved dev productivity 25% if you haven&#x27;t even improved your own functionality-delivering at any rate (which you&#x27;d only know if you attempted to deliver functionality)?<p>In fact, every engineer I know who I respected to deliver boatloads of functionality also had this behaviour.<p>All of the guys who thought they were this guy but didn&#x27;t deliver boatloads of functionality were just some wheel spinners who weren&#x27;t really useful. I&#x27;ll probably never work with them again if I do my hiring right.
评论 #24128181 未加载
评论 #24136934 未加载
评论 #24128555 未加载
评论 #24128755 未加载
评论 #24128048 未加载
评论 #24127763 未加载
gfodor将近 5 年前
This advice applies generally - leaning into the interests of your team acts as a multiplier. I haven&#x27;t seen it done often, and sometimes it&#x27;s explicitly frowned upon, but I often advocate for team interests to influence roadmap prioritization.<p>&quot;But the customers&#x27; needs should prioritize the roadmap!&quot;<p>Yes, they should, but it should be balanced. Better to have 10x the output, a happy team, and hit a broad surface area of customer value, than a slow, clock-punching team who comes into work being told what to work on by dictum based upon the most high customer demands. A sign you&#x27;re doing this right is if there is some slight tension between engineers working on what they like, and what management feels is the important thing to be doing. You want that tension, and need to manage it from falling too far to one side or the other.<p>It often turns out if you have a balance here, you&#x27;ll see innovation happen as a side effect. Team interests of a smart team often are somewhat far afield and lead to bursts of creativity, and can lead to new forms of thinking that lead to new features. Ensuring the team groks the customers&#x27; needs, and their demands, as well as giving them opportunities to pursue their passions, allows them to connect the two together when inspiration hits. Often times to innovate you need to do more than just listen to your customer, you also need someone with an orthogonal interest, knowledge, or talent stack to cross-connect things into something greater than the sum of its parts. Empowering the builders on your team to explore things is a good way to harvest some of this &#x27;innovation space.&#x27;
评论 #24120999 未加载
simonw将近 5 年前
A big risk here is that it&#x27;s very easy for refactoring you make a codebase worse.<p>Someone spots the same functionality in two places, applies DRY, then two weeks later a new requirement means they need to work slightly differently from each other and that change has to be unwound again.<p>I&#x27;ve seen plenty of helpful refactors that broke code in subtle ways (if your tests aren&#x27;t robust enough this can happen really easily).<p>I&#x27;ve seen projects take literally months longer because the team hit caught up in &quot;refactoring&quot; code written by previous engineers - not because it needed it, but because the new engineers preferred to write their own code than dig in and understand what was written before them.
评论 #24120812 未加载
评论 #24120733 未加载
评论 #24127190 未加载
评论 #24120743 未加载
评论 #24121221 未加载
评论 #24122969 未加载
评论 #24120944 未加载
评论 #24121016 未加载
评论 #24138488 未加载
评论 #24126933 未加载
评论 #24121205 未加载
jll29将近 5 年前
This post talks about a team role that has been called the &quot;librarian&quot;. Some of the software engineering literature proposed that a team of three can be most productive as a pair supported by a librarian that writes useful library functions.<p>I have been in teams where we carried out projects, and each project&#x27;s codebase re-invented a lot of functionality (e.g. converting HTML to plain text, tokenising an English sentence). Of course I proposed a librarian role, which as the article contends is suitable for particular personalities.<p>In a group of, say, ten or more people there is a room for that kind of specialisation (librarian, sysadmin, statistician, ...).
评论 #24127590 未加载
评论 #24127975 未加载
评论 #24127556 未加载
评论 #24128122 未加载
评论 #24128654 未加载
Wandfarbe将近 5 年前
I&#x27;m not a big fan of people just doing what the ticket states.<p>Quality doesn&#x27;t start when a customer comes up with a simple fix&#x2F;enhancement. Quality comes from people with experience who knows exactly what needs to be done even if it is not stated in a Ticket.<p>- Security - Maintainability - Usability - Clarity - Performance<p>You are the expert, NOT your PO. Your PO tells you what he&#x2F;she needs, you tell them what you HAVE to do.<p>And personally, i have never heard anyone complaining that someone else did a better job on a ticket than the ticket stated.
评论 #24121222 未加载
评论 #24120973 未加载
评论 #24122238 未加载
thinkingkong将近 5 年前
Ugh. I hate posts like this. Refactoring, speed improvements, documentation, testing, etc arent roles. They arent buckets. They arent seats you fill. Theyre part of every engineers job. The issue is we keep dividing issues into “product work” and “unproductive” work. If this person is fascinated with refactoring thats amazing. If theyre obsessed with speed, equally so. But there needs to be constraints on when to start optimizing and when to stop. The when to stop part is the one where people fail the most. Simultaneously, we should all be dedicating time on a regular basis to these types of activities. Like min 25% of our weeks for most companies. Instead we hide these improvements in features and complain when coworkers are “slow”.
评论 #24121671 未加载
dmalvarado将近 5 年前
My god, this describes me to a T, and every one of those bullet points sounds like a fantastic way to spend time working. It was only when I caused a production issue due to a refactor that I gave up on trying to making a behemoth codebase better for everyone who has to work in it, and that’s when work got sad and boring.<p>I will take this to my team.
评论 #24127771 未加载
评论 #24127966 未加载
DanielBMarkham将近 5 年前
I think the thing a lot of devs don&#x27;t know is that there&#x27;s a limit to refactoring. At some point, you&#x27;re done.<p>It&#x27;s like a mountain. The team is dropped half-way up the mountain. The dev that refactors all of the time continues to head up the mountain. It can be slow work. It&#x27;s a tough climb. Most of the time, devs on the team don&#x27;t know any better, so they just do the work in front of them, slowly sliding down the mountain. Eventually, they look at the mountain and say &quot;There&#x27;s no way anybody could conquer that! We&#x27;re lucky just to get our work done without too many bugs!&quot;<p>Meanwhile, the refactoring dev reaches the top and slides down the other side. That dev starts looking for bigger mountains. The rest of the team he left behind sink into despair and cynicism.<p>Eventually, when organizations grow large enough, most everybody lives at the bottom of the first mountain. Devs who leave and try to summit are ridiculed at best, shunned at worst. They&#x27;re hated if they only go halfway and then fail.<p>I am of the opinion that most big-organization developers don&#x27;t actually know how to code. Sure, they know how to type in programs. Hopefully they know enough to test what they&#x27;re writing. But a real understanding of what programming is? No. Until you&#x27;ve been over a few mountains you don&#x27;t know what you don&#x27;t know. Sadly these are many times the folks that get promoted.
评论 #24128553 未加载
vp8989将近 5 年前
This article is based on a very commonly used but flawed premise that all product-driven work actually delivers value to the business and that tech-driven work doesn&#x27;t.<p>This is only really true in the real world for a subset of brand new startups, where none of the low hanging fruit product ideas have been built yet but the &quot;idea&quot; for the business is very good. Tech-driven work doesn&#x27;t pay off here because of scale. It&#x27;s not worth working on perf when your total server bills is in the hundreds or thousands of $. It&#x27;s not worth working on dev exp when you have &lt; 10 developers. You don&#x27;t need to refactor yet as it&#x27;s greenfield code anyway and it&#x27;s easy enough to glob stuff on to support business ideas ... for now.<p>If you are working on a sufficiently mature product, there is a fairly high chance that the product-driven feature you are about to spend months on will fail to gain any traction and be totally scrapped. Anyone who has 5+ years experience has probably experienced this multiple times, this happens all the time even at &quot;good companies&quot;.<p>This is because all the obvious low-hanging fruit ideas were already built years ago (which is why the business even has any money to employ YOU as a software engineer).<p>In more established companies you are less likely to deliver value to users but more likely to deliver value to the business by executing on &quot;tech-driven&quot; initiatives. This is because of scale:<p>- If you work on perf, cutting 10% of server costs is a big deal when you run thousands of them vs. tens of them - If you work on developer efficiency, improving that for hundreds or thousands of developers is a big deal - If you refactor to support future changes, preventing forced &quot;big bang&quot; rewrites of large established systems you will save the business millions of $ in salary
juliendc将近 5 年前
A very respected developer in my previous company once told me: &quot;make the change easy, then make the easy change&quot;. I guess everybody has already heard it because it&#x27;s kind of a famous quote but it has really changed the way I develop since then. Every times there is something I need to implement and I feel like the codebase &quot;resists&quot; it, I think about this quote. I then take the necessary time to make this change easy first.<p>Found a link to a tweet, which looks like the original source (not sure though): <a href="https:&#x2F;&#x2F;twitter.com&#x2F;KentBeck&#x2F;status&#x2F;250733358307500032" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;KentBeck&#x2F;status&#x2F;250733358307500032</a>
评论 #24121273 未加载
secondcoming将近 5 年前
Fred was employed to do a job. Fred isn&#x27;t doing it. Fred needs to learn the ropes; everyone would love to be in a position to work on whatever they want at the expense of everyone else. Fred could raise tickets to allow him time to do the refactoring but he sneakily does it as part of other work which puts his colleagues in a position where they have to accept his work because it&#x27;s late.<p>Don&#x27;t be Fred. Freds get fired.
评论 #24121013 未加载
评论 #24121051 未加载
评论 #24121240 未加载
评论 #24121072 未加载
评论 #24120874 未加载
评论 #24120899 未加载
评论 #24120960 未加载
评论 #24124271 未加载
评论 #24128817 未加载
评论 #24120902 未加载
评论 #24121229 未加载
评论 #24128147 未加载
评论 #24142239 未加载
staysaasy将近 5 年前
IMO being able to cut through work that you don&#x27;t love is a tremendous skill, especially for software engineers. Many of the most successful engineers I&#x27;ve worked with had a really valuable trait where they were 100% effective on projects that they loved while also 90% effective on ones that they hated. This really helped them stand out when the standard ratio was closer to 100% &#x2F; 20%.
评论 #24120761 未加载
rconti将近 5 年前
I don&#x27;t see why this perspective on someone doing things differently is so surprising in an era where we&#x27;re pushing the advantages of diversity. Everyone comes at things from a different perspective and has different strengths.<p>I remember having a coworker ask me for advice on a storage array he was working on. He was banging on the UI, checking out all kinds of irrelevant paths, seemingly exploring all possible ways of accomplishing the task at hand, even the ones that were very unlikely to be correct. I was kind of frustrated that he was spending time exploring unimportant elements as I could clearly see it was one of just two or three options. I tried to brush aside some of the exploratory actions and he said &quot;oh, I know that probably won&#x27;t work, I just wanted to take a look..&quot;<p>I didn&#x27;t have the patience or attention span to wait for this ridiculously slow interface, so I wandered away after giving my best advice.<p>A couple months later, whose experience did we always rely on when trying to figure out a novel problem? That&#x27;s when it clicked for me. I won&#x27;t necessarily have more patience myself with the exploration steps, but I certainly appreciate those who do.
bcrosby95将近 5 年前
You need to put Fred on stuff that other developers have some buy in for. If you have zero automation, putting Fred on that is a bad idea. If you have zero tests, don&#x27;t put Fred on that either.<p>Because the minute Fred leaves, all that work will rot then be discarded. It&#x27;s better to have Fred work on something that will be maintained beyond his employment.
评论 #24128173 未加载
评论 #24128144 未加载
fudged71将近 5 年前
Our CTO cofounder was a &quot;technical genius&quot; asshole who did 3 entire rewrites of our stack before a single user touched the product. He would come back from a weekend and say &quot;I stayed up and refactored everything to make it faster&quot;. Of course this left our other developer completely in the dark and it broke a lot of shit in the process.<p>We ultimately fired him and got another cofounder up to speed into that role. It was the most frustrating red flag that we should have caught earlier and put a stop to.
评论 #24129785 未加载
dmitryminkovsky将近 5 年前
I am that guy and every day is a struggle to manage that inclination!<p>I really appreciate the author’s attempt here to get into the psyche (developer experience vs user experience) and to find a constructive resolution.<p>I’m not sure I agree with the conclusion though because I think often the issue is a matter of lacking experience (which takes time) and discipline (which takes practice). Though I’m sure many cases are just as the author described.
spacemanmatt将近 5 年前
I am on a small team that factors&#x2F;refactors heavily. Some thing I have noticed about the practice over the almost three years since I started this particular job:<p>1. Adding small features is extremely predictable, in terms of delivery time estimates we give to management. 2. Our bug count is very low, and when we solve a bug it is often small, pervasive, and resolved in exactly one piece of code. 3. The more we factor, the better we get at it, and the easier it is to add new factors rather than new globs that need factoring.<p>I don&#x27;t see the promise of &quot;agile&quot; work out every time but factored code delivers like this every time for me.
gbuk2013将近 5 年前
Ha - I’m this guy at work except I’m a couple of times more productive than everyone else because I know the codebases back to front and our team is several times more productive than other teams because the code is neat and tidy after continuous refactoring for years. We added 2 engineers to the team and they were both shipping features after a week of training because the code is neat and tidy. Having close to 100% test coverage makes refactoring easier, although sometimes new bugs do happen. ;)
评论 #24127368 未加载
jeherr将近 5 年前
Fred sounds like he <i>may</i> have ADHD. I&#x27;m Fred and I have ADHD. Now I&#x27;m not an expert so it&#x27;s not necessarily true. ADHD comes in a spectrum of severity, and plenty of ADHD symptoms are just things normal people have trouble with too.<p>That said people with ADHD tend to have trouble with delayed gratification. Helping your coworkers has immediate benefits when they are grateful for your help, even though long-term it may make things worse. We also tend to have a lot of social anxiety and care a lot what other people think about us (rejection sensitive dysphoria). For these reasons, I believe people with ADHD have learned to be very helpful to those immediately around us, even to a fault.<p>Fred still has to get his work done though. Have some empathy for him because you don&#x27;t know what he may be dealing with compared to you, but it&#x27;s not an excuse.
评论 #24122505 未加载
评论 #24127761 未加载
watwut将近 5 年前
If the Fred is providing value to other developers, why are other team members despising him to the point of calling him names often?What this shows is a strawman situation that is meant to make the point, but is actually showing dysfunctional team.<p>It does not show enough details for us to know whether Freds refactorings are needed or making codebase worst. It is sort of Rorschach test where we are supposed to pick a side and then fight among ourselves about following two questions:<p>Question 1: &quot;is the refactoring you never seen on the codebase you have no idea about by a guy that is despised by his team&quot; good or bad?<p>Question 2: &quot;A guys is disliked by his team. Is he right and team is wrong or other way round?&quot;<p>The only correct answer is &quot;who the hell knows but damm start managing that damm team&quot;.
cle将近 5 年前
I often understand code based by refactoring things. And then I throw it all away. I use it as a way to play with the codebase and understand the rationale behind its design and organization.<p>Sometimes other people do that too, they just need some guidance that it’s okay to do that and then throw it away. The important artifact you’ve created is a deep understanding of the codebase.
aaanotherhnfolk将近 5 年前
I&#x27;ve been on a team like this before with heavily separated feature and refactor pods and it doesn&#x27;t really work.<p>The feature pods outpace the refactor pods. Feature pods can use a bad pattern 50 times in the time it takes refactor pods to fix 10 of them. Not every fix can be scripted. Some bad patterns restrict the ability for the codebase to stay up to date on dependencies, etc. Lots of reasons not to accumulate this stuff faster than you can strip it off.<p>It also impacted team cohesion, as refactor pods started to resent the poor quality of feature pods&#x27; deliverables. Since refactorers are peers, it got weird when they exerted refactor pressure on feature devs who got wedged between their peers and their managers.<p>Ultimately I think this article is a little too black and white. The &quot;just do the ticket&quot; dev is as undesirable a teammate as the &quot;refactors to excess&quot; dev. It&#x27;s better if devs are a little of both and the team culture helps everyone keep a healthy balance.
mcv将近 5 年前
A story about me! I mean, I&#x27;m not Fred, but I am. I always try to leave the code a little bit nicer than I found it, and that means if I find warts on code that I need to change, I&#x27;m going to fix those warts.<p>I love the project I&#x27;m currently on, and that&#x27;s probably because for the first time since I&#x27;ve gotten good at this, I actually get the freedom to do it.<p>Would it be better to just build those features quick and dirty? Maybe. Certainly for the first few weeks or months. And then the code starts turning into a mess, and somebody needs to clean it up, and apparently that&#x27;s what I love.
toomanybeersies将近 5 年前
The alternative is usually that if Fred isn&#x27;t allowed do these improvements, they never get done, then you end up with 5 year out of date dependencies, a useless test suite, and a mountain of technical debt.
tyingq将近 5 年前
My guess is that Fred isn&#x27;t going to be giddy about being taken off the main codebase.<p>The idea that he might be good at the plumbing doesn&#x27;t mean he wants to do it.<p>There&#x27;s also the danger that you end up with endless churn in your plumbing, testing, etc, tools instead.<p>I get the gist of the article, but sometimes you have to face the hard reality that there&#x27;s a bad match between a team&#x27;s needs and a team member&#x27;s desires.
评论 #24120736 未加载
adamsvystun将近 5 年前
The leap from this:<p>&gt; That coworker who never stops refactoring<p>to this:<p>&gt; Fred is more interested in providing value to other developers than to users.<p>is not so clear to me, while the article assumes it to be self-evident.<p>I personally like refactoring even though I work on the codebase alone. I do it because refactoring allows me to ship features faster (in aggregate), and allows me to create a better overall experience for users. I care only about the end result for the users, and this necessitates that I keep the code clean and succinct.
chojeen将近 5 年前
At a startup, there&#x27;s a good chance Fred&#x27;s time would be better spent knocking out feature work (you only have so much runway, after all). But at a mature tech company, assuming he&#x27;s good at his job, Fred is likely providing a ton of value by<p>- Keeping his coworkers sane (barely functional codebases that are difficult to work with have a way of killing morale) - Having an intimate knowledge of the code base that can inform future feature work - Paying down tech debt that&#x27;s generally uninteresting to more feature-oriented coworkers<p>Having a whole team of Freds is probably not a good idea, but having one in a senior engineer or tech lead role is really useful.
BurningFrog将近 5 年前
Refactoring is the design phase in an agile process.<p>The old way, inspired by bridge building, I guess, was to first thing out a great design for your software, and then implement it.<p>This turns out to not work because, unlike bridges, software is always changing and needs new features.<p>So in agile, you just write the simplest thing that can possibly work to solve your next task. <i>Then</i>, when things work, you refactor the code to have a good design.<p>Designing something <i>after</i> it&#x27;s built is a mind bending concept, but it&#x27;s made possible by what we make being just text in files, not set in stone.
tarkin2将近 5 年前
I’ve suffered from never-refactored codebases. And made people suffer from my refactoring.<p>My company once decided to use dependency injection, everywhere, everywhere, and for anything. The code became a needlessly orchestrated nightmare.<p>Now any refactor to make my code solve a generic rather than specific problem — and I’m making the codebase bigger in code and number of files — gives me pause for thought.<p>The more abstract something is, the further away from specifics it is, and sooner or later specifics change, and those changes break your happy abstraction.
评论 #24122962 未加载
ipsocannibal将近 5 年前
If you follow the advice of this article your refactoring wizard becomes the operations silo. Code quality on the team goes down overall because operations silo Guy can&#x27;t review all CR&#x27;s himself and if he tries to the rest of the teams velocity suffers. Don&#x27;t worry operations silo Guy will clean it up later anyway which doesn&#x27;t happen because more code is written by the other developers than operations silo Guy can refactor. Other developers on the team will put off refactoring and automation work because that&#x27;s now operations silo Guy&#x27;s domain. They grow rusty in those skills. You also lose the ability to include operations silo Guy in swarming on features as he hasn&#x27;t been keeping up with the product&#x27;s development because he&#x27;s always refactoring some old integ test or run script.
dgreensp将近 5 年前
Yup, I’ve found that even when pretty much every engineer on the team knows that velocity is slow because necessary refactors have not been done, refactoring is often not considered real work and real progress. It’s the kind of thing you’re supposed to do in your spare time, off the roadmap. Also, people who find refactoring difficult or unpleasant will try to get you to see things from their point of view! Or they and their teammates have tried so many times to get the green light from leadership to pay down technical debt that they have given up.<p>It’s underappreciated that developers have different strengths and interests and could be doing different kinds of work rather than being treated as interchangeable workers, even at a relatively small start-up, in my experience.
codenesium将近 5 年前
There is pointless refactoring but Fred sounds like a senior developer cleaning up messes to me.
solinent将近 5 年前
I think the biggest value of refactoring is reducing code size, which is directly correlated with bug count &#x2F; severity (there are tons of studies here). Ultimately you&#x27;re providing a huge value to your clients. If your code stinks on the inside, it&#x27;s gonna take a huge effort to make it smell nice on the outside.<p>If you stop repeating yourself, you may make less mistakes because there are simply less chances of it. Good abstractions help.<p>They also speed up your development speed, accelerating you towards your goal instead of coasting.
评论 #24142273 未加载
dave_aiello将近 5 年前
The greatest difficulty I run into as an indy developer is lack of internal documentation.<p>I often write something and don&#x27;t look at it for a long time thereafter; In the intervening period, I forget some important aspect of how this code works. Or I inherit a piece of code from another developer, and I have no idea why it was implemented the way it was.<p>I would love it if developers wrote a line of comment or two per function, just laying out what&#x27;s happening and why the code was written that way.
jspaetzel将近 5 年前
I draw a parallel between refactoring and code ownership. Once I&#x27;ve worked in an area of code for a while (several sprints) then I probably know enough to try refactoring. Longer time working on it == more ability to refactor.<p>The idea of what is correct (to you and to others) and what needs refactoring changes over time, even the product changes. Sometimes it can be beneficial to wait a while and see if you still feel the same way after a few weeks.
CGamesPlay将近 5 年前
If your team is 5 people, and each one makes the company 4% better every year, then after a year the company is 3.3x better, and after 5 it&#x27;s 403x better. If you team is 5 people, but one of them makes other engineers 4% better each year, and the rest focus on the company, then after a year the company is 3.2x larger and after 5 it&#x27;s 392x better. Wasn&#x27;t worth it. At six engineers the balance slightly shifts.<p><pre><code> Group 1 year 5 years Gain 5 product 3.3 403.4 1 tools, 4 product 3.2 392.8 -2.6% 6 product 3.5 492.7 1 tools, 5 product 3.3 501.0 +1.7% </code></pre> Now, obviously the team probably won&#x27;t stay 5 engineers for 5 years, but my point is: like everything else, this is a cost-benefit analysis. For small teams, it turns out it&#x27;s not worth it to have happy Fred on your team, and you should let him go work on internal tools for a few dozen engineers where he can have massive impact there.
ysavir将近 5 年前
This blog posts describes the conflict as &quot;providing value to other developers&quot; vs &quot;providing value to users&quot;, but that&#x27;s false dichotomy. Refactoring isn&#x27;t about providing value to other developers, it&#x27;s about reducing the complexity and investment necessary to make future changes. That&#x27;s valuable to the other developers, sure, but it&#x27;s also valuable to the business, and also valuable to the users.<p>While there&#x27;s certainly something to be said for assigning people responsibilities that work well with their personal strengths, that won&#x27;t compensate for misunderstanding the purpose of refactors, how and when to apply them, and how to prevent the need for them in the first place. It&#x27;s essentially hiding the problem rather than identifying the problem and introducing a relevant solution.
sfink将近 5 年前
Codebases follow evolutionary paths. If the code isn&#x27;t going to be needed for long, there&#x27;s no point in refactoring. If it does have a long lifespan, then every change, every addition, has the potential to increase complexity and make it harder to adapt. That&#x27;s ok for a while, but in the longer term requires a counterbalancing pressure in order to be sustainable.<p>Whether that pressure is provided by regular developers, or partly or wholly by dedicated people, depends on the interests and skills of the people on hand. Carving off a Fred is one successful strategy. So is having core developers actively maintaining the integrity of the overall system as they make changes.<p>You have to pick, or stumble upon, the right strategy for your situation and staff.
waiwai933将近 5 年前
The whole category of responsibilities listed (automated tests excepted) is what tech leads effectively do where I work... is this not normal?
评论 #24120831 未加载
neandrake将近 5 年前
I identify with the motivations outlined in this post. One additional thing I&#x27;ll add is that refactoring allows me to learn and understand the existing code base. Being able to move and rewrite code reminds me of playing with Play-Doh. This practice lets me immerse myself into the code a bit more so I can grok it more easily. Half the time my refactoring is thrown out or shelved for ages so there&#x27;s nothing in the project history to show for it other than my new-found knowledge.
gregkerzhner将近 5 年前
Having someone responsible for the dev environment and tools sounds great if your team and organization has scaled enough to allow this.<p>Having one person be the point person for refactoring, tech debt and code review on the other hand seems like a bad idea - these should be every developer&#x27;s responsibilities. This sounds like a pretty silly team overall - all the team members write quick, messy code and then one person is on &quot;cleanup crew&quot; fixing bugs and improving design?<p>Talk about a way to brew up some tension and misalignment on a team. &quot;Hey George... I know you are about to open a 2nd pull request to add additional features to your work, but I just refactored your whole initial implementation, and now there are 30 merge conflicts...&quot;<p>We always talk about the bus rule at work - if someone got hit by a bus tonight, would the team be able to operate tomorrow? If we had &quot;refactor guy&quot; on our team though, I probably would have to resist not giving them a gentle nudge forward every time we wait to cross the street together.
k__将近 5 年前
I remember my first React project in 2015.<p>A co-worker initialized the project with CoffeeScript and Flummox, then switched to ES6 and then switched to Redux.<p>It was a few thousand lines of code, so it was often &quot;Yes we can add that new feature when I did my refactoring&quot; which often took weeks in which I couldn&#x27;t do anything valuable.<p>Also, the bugs that grew of those re-writes followed us for months.
thunderbong将近 5 年前
Rule of Three<p><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Rule_of_three_(computer_programming)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Rule_of_three_(computer_progra...</a><p><a href="https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;rule-of-three&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;rule-of-three&#x2F;</a>
jariel将近 5 年前
&quot;Doesn’t it seem powerful, to have a person on your team completely dedicated to helping other developers be as productive as they can be? &quot;<p>Fred may be helping, he may be helping in an inefficient way, he may be doing &#x27;make work&#x27;, he may be screwing things up.<p>It depends more on the materiality of the outcome, not the motivation of the effort.
dummydata将近 5 年前
I have a Fred on my team. He recently took a few weeks to refactor a large part of the codebase which consisted of about 200 file changes. The problem with this approach is that he never discussed his changes with the team, leaving the discussion until code review time. Some refactoring doesn&#x27;t quite need a discussion, but large changes should.<p>It should go without saying that I think refactoring is super valuable. The way to go about it is to: 1. Recognize what in the codebase you see an opportunity to refactor 2. Discuss with the team (more experienced developers can have some useful suggestions) 3. Write a separate ticket for the changes (you can prioritize this after your required work)<p>Obviously, #3 won&#x27;t work if your group doesn&#x27;t value refactoring. In that case, you should bring up the conversation. You&#x27;ll probably find many&#x2F;most of your coworkers will be in agreement.
j_z_reeves将近 5 年前
I welcome a coworker refactoring a section of the codebase to make it easier to change in the future. I do not like it when a coworker, new to the project, assumes that a certain way is incorrect. Like, introducing docker and additional tooling when no one asked for it. I especially do not like it when abstractions are unnecessarily forced.<p>Another perspective, if I am busy building out a feature and I open my source control to several huge PRs containing trivial changes, I groan. Now, not only do I have to respond to these PRs in a timely manner, I have to ensure that the changes are part of a codebase&#x27;s design roadmap.<p>Large refactorings should be discussed, agreed upon and expected. Breaking a several thousand line module into a folder containing separate modules is nice and a welcome endeavor. I just don&#x27;t want to see it as part of a feature PR. Discuss it and create a separate PR.<p>Also, just because you refactor, doesn&#x27;t even your refactor is good. You can refactor in a worse off way as well. Your refactor may make the codebase nicer now, but could prevent easy changes later. Your refactor may go against best practices. I have seen this from developers that are on the Dunning–Kruger spectrum. Once again, refactors should be discussed and agreed upon.<p>As a side note, this seems like a great interview question to determine cultural fit. I do not want to work with a &quot;fred&quot; that doesn&#x27;t communicate concerns and intentions.
mannykannot将近 5 年前
I am sympathetic to this viewpoint, but I realized how infeasible it is with this suggested use of Fred&#x27;s obsessions: &quot;quick and thorough code review&quot;. People like Fred will never be <i>quick</i> in their review, but boy, will they be thorough! Everything presented for review will be rejected for being fundamentally the wrong way to do the job, as explained in great detail.<p>Similarly, &quot;refactoring and managing tech debt&quot; will become &quot;rewrite from scratch&quot;, and &quot;automating anything that can possibly be automated&quot; and &quot;streamlining the deploy process&quot; will be inordinately parameterized in order to cover every possible (and hypothetical) edge case.
评论 #24128951 未加载
bsaul将近 5 年前
on a side note, i&#x27;ve witnessed a big difference between code that was properly architectured from the beginning, to code that evolved in a purely iterative fashion, driven by end-user feature tickets.<p>Architecture design is to me a different beast from simply refactoring, because it is also meant to anticipate future evolutions, in order to provide a solid technical layer upon which feature can be iterated.<p>Unfortunately i don&#x27;t think a lot of teams knows when is a good time to seriously think about the time to (re)design &#x2F; architecture a system. Nor what is truely meant by &quot;architecture&quot; ( hint: no, it&#x27;s not just about picking the latest MVC variation of day).
spaetzleesser将近 5 年前
I often refactor code as a way to procrastinate on other tasks I am not sure about how to approach them. Sometimes it&#x27;s productive and results in better code but sometimes it&#x27;s just shuffling code around without much improvement.
nix23将近 5 年前
I like Fred, he cares about doing stuff the right way rather than get work done, with Fred our Operating-system&#x27;s would be much better&#x2F;faster and easier to maintain.
评论 #24126932 未加载
vemv将近 5 年前
It all boils down to one&#x27;s personal motivations.<p>Refactoring and tooling work make sense if that work is oriented towards increasing productivity and maintainability, using contrasted personal experience, and skill.<p>Do you envision being <i>done</i> at some point? Are you getting a actual productivity boost with your meta-work? Are you solving problems proven to be actual problems from previous experiences?<p>If not, it&#x27;s better to introspect.
zaro将近 5 年前
Yep, that&#x27;s me. Features are simply something that happens as a byproduct of a refactor.
ccktlmazeltov将近 5 年前
Honestly good and secure code is only achieved through multiple refactoring. I hate people who just jump from features to features and have no intention of maintaining and on improving a piece of code once it&#x27;s written. This is how you get tech debt.
hnruss将近 5 年前
If refactoring didn’t introduce regressions, then that would be great to have someone constantly refactoring to improve the codebase. In my experience though, it often makes more work for the rest of the team, sometimes for years afterwards.
zabil将近 5 年前
Great read. Especially the point about developers vs users.<p>Programming langauges and IDE&#x27;s have an effect too in my opinion. I&#x27;ve found myself and other team members refactoring much more when using OOP languages. Design is very subjective.
kapakos将近 5 年前
I call the coworker that is described in the article a ‘senior engineer’.
seancoleman将近 5 年前
I loved the term a colleague used for this: refactorbation.
yummypaint将近 5 年前
<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dQdsFpvTKU4" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=dQdsFpvTKU4</a>
praveenperera将近 5 年前
The fear would be Fred runs out of useful refactoring and starts creating work for himself.<p>When you&#x27;re a hammer everything looks like a nail syndrome?
mullikine将近 5 年前
I would like to put this in the personality profile part of my CV
zwilliamson将近 5 年前
I believe they call this person a “catfish” developer
评论 #24150859 未加载
polymonster将近 5 年前
Refactoring is life
jlucktay将近 5 年前
Hi, it&#x27;s me, I&#x27;m Fred
donatj将近 5 年前
My advice? Be Fred.
评论 #24130327 未加载
Trias11将近 5 年前
Yup. That&#x27;s me.<p>I hate shitty band-aid code. I love perfection.<p>I&#x27;m Michelangelo - but that by definition makes me a loner. I love staring at my code and contemplate on it&#x27;s beauty just like the result of the code working.<p>I&#x27;m perfect at one-man projects.<p>I hate processes, standups, scrums and all that team playing bullshit.<p>I love customers and bosses who are trusting and freedom giving.<p>I love beers, steaks, good food and team gatherings - and i love people whom i am &quot;working&quot; with - but everyone knows i am working on something that is NOT &quot;let get this shit done quickly and push this out of the door by next friday&quot;. That&#x27;s not me.<p>Although I&#x27;m the one my boss comes to with &quot;i don&#x27;t know how but can you do something about it tomorrow&quot;? I&#x27;m good and super sharp focusing and delivering on my own. If i need help - I&#x27;ll ask.<p>I&#x27;m all for skunkworks.<p>I debug my code myself, using techniques i polished myself over the years and I&#x27;ll end up with lightbulb that will last 100 yrs. Not the one that cost $3 and requires full replacement after 3.5 weeks of light usage.<p>I try not to buy stuff made in China. I love stuff made in Europe or Japan.<p>So, don&#x27;t push guys like me into your &quot;processes&quot; and &quot;change managements&quot; wasting pipeline bullshit.<p>I won&#x27;t fit.<p>I speak at conferences. I do evil harmless things. I violate countless stupid compliance rules. I take risks no one knows about. I don&#x27;t follow rules, and pretty much skip reading them when i can.<p>I do my best to deliver masterpieces. One piece at a time.<p>Downvote me.
评论 #24128110 未加载
评论 #24129493 未加载
评论 #24128634 未加载
评论 #24129084 未加载
评论 #24129927 未加载
评论 #24135504 未加载
评论 #24128800 未加载
评论 #24128768 未加载
评论 #24128534 未加载
评论 #24129281 未加载
评论 #24132480 未加载
评论 #24128055 未加载
评论 #24131273 未加载
评论 #24133776 未加载
评论 #24128556 未加载
评论 #24135283 未加载
评论 #24142619 未加载
评论 #24128043 未加载
评论 #24134119 未加载
评论 #24129359 未加载
评论 #24135741 未加载
评论 #24131659 未加载
评论 #24128249 未加载
评论 #24128406 未加载
blahbhthrow3748将近 5 年前
Personally when people move into the &quot;dev tools&quot; role they often seem to lose sight of the forest for the trees. They&#x27;ll argue for an idealized workflow - everything has to have 80% test coverage, everything has to have tracing, everyone&#x27;s editor needs an exact set of plugins. They start out fixing papercuts they&#x27;ve personally experienced and end up building tooling to solve problems nobody has.