Don't rely on an inbox, comprehensive indexes, or backlinks When writing notes for your Zettelkasten, it's natural to feel some anxiety about whether you're just writing into the void, or whether you'll actually stumble across those notes again in the future. To relieve this anxiety, there are at least three tempting solutions that seem to make sense on the surface, but which tend to fall apart in the long term.

Take Wikis as an example. Most of them have two different modes: The reading mode. The editing mode. The reading mode is the default. But most of the time you should create, edit and re-edit the content. This default, this separation of reading and editing, is a small but significant barrier on producing content. You will behave differently. This is one reason I don’t like wikis for knowledge work. They are clumsy and work better for different purposes.

Before writing component tests, think about whether you actually need to test the component, or if it’s more about the logic inside the component. If so, consider extracting out that logic to test it in isolation, without the overhead of a component

A lot of it feels like someone who doesn’t like the old code and wants to do it “right.” I can agree that the old code is ugly. But it will take an awful lot of effort to make a new implementation. It’s a lot like what happened to Elvis: A rewrite was going to make it much better, but it took so long, during which Vim added more features, that eventually there are not so many Elvis users. And the rewritten Elvis may have nice code, but users don’t notice that.

Feature Branching also discourages developers from making changes that aren't seen as part of the feature being built, which undermines the ability of refactoring to steadily improve a code base.

Most companies where I worked have a history of rebuilding their applications every 3 to 5 years, some even 2 years. This has extremely high costs, it has a major impact on how successful the application is, and therefore how successful the company is, besides being extremely frustrating for developers to work with a messy code base, and making them want to leave the company. A serious company, with a long-term vision, cannot afford any of it, not the financial loss, not the time loss, not the reputation loss, not the client loss, not the talent loss.

they know how to separate concerns and reduce coupling

By abstracting code away from "Files" and "Lines" we can offer more nuanced views like "Repeated Code Blocks" that could be refactored.

ake sure you are mentoring someone, always. Make sure you’re always mentoring others. And I have found that mentoring others gives me new perspectives on things. Because I may be telling them things, but I’m learning a lot while I’m telling them.

ExportProcessControl

In particular, it allowed for organizing common traits (such as extensibility, or different ways of showing examples as schemas that can be mixed in to the main object definitions.

I have refactored the schema to use allOf, oneOf, and unevaluatedProperties, which not only dramatically shrank the file (1500 lines down to 845) but allowed a different approach consisting of a number of "mix-in" schemas grouping commonly used fields, which are then referenced throughout a set of object schemas.

By offering to have a real-time technical discussion, you are reframing the code review process away from an 'instructor correcting student' dynamic and into a 'colleagues working together' mindset.

Level 5: Stop the line. The highest level of code review comments. Borrowing the term from Toyota's manufacturing process this is when the code reviewer noticed something in the PR that signals a major defect.

Level 4: Infringement. This is where things get more serious, note that infringement means rules were broken. In this context, rules can mean a number of things, from the more obvious feature spec and framework rules to things like style guides and coding principles.

Level 3: Suggestions. These can also be thought of as recommendations and alternatives.

Level 2: Nitpicks. Usually, comments about grammar errors and minor stylistic issues/typos go there. The solution to the nitpicks is usually very obvious and if the solution is opinionated, the opinion is not strongly held. Naming a method foobarGenerator vs foobarFactory goes in here, and nitpick comments often start with Nitpick:.

Level 1: Clarifications. I also think of these as sanity checks, I may even start the comment with something like I may be completely off the base here... or Just to sanity check...

and if I think this is too boilerplatey, I can export a handler from some .js file and pass the error to that: <script> import { onError } from 'svelte' import { genericHandler } from '../my-error-handler.js' onError(genericHandler(e => { // code which is called first to try to handle this locally return true // we've handled it here, don't do anything else. }) </script>

Abstract the whole queryCommandState / execCommand system into a store (or some wrapper that also holds a store) that has state like isBold and canMakeBold and a makeBold() function.

The consumer component will barely change from our last example. The only difference is the way we'll get a reference to our store (since now the store is exported from the JS module):

In order to use this, we need to use a little more advanced readable store. Here's your example updated for this:

// our temperature is now a store with initial value 0 const temperature = writable(0); // now we don't need to change this function, the change will be propaged // by the store itself const getTemperature = () => { return temperature; }

Here's how we would rewrite our callback example with a store instead:

That's it! Just replace let! with let_it_be. That's equal to the before_all approach but requires less refactoring.

That technique works pretty good but requires us to use instance variables and define everything at once. Thus it's not easy to refactor existing tests which use let/let! instead.

I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.

Also, Sandi Metz mentions this in POODR. As I recall, she also advocates wrapping bare instance variables in methods, even when they're only used internally. It helps avoid mad refactoring later.

But sure, go ahead and enforce self-encapsulation if you like; it makes it easier to do memoization or whatever later on.

The number one problem that I see developers have when practicing test-first development that impedes them from refactoring their code is that they over-specify behavior in their tests. This leads developers to write more tests than are needed, which can become a burden when refactoring code.

Refactor ruthlessly. Rewrite bravely.

Refactoring is a means of addressing the problem of software rot. It is described as the process of rewriting existing code to improve its structure without affecting its external behaviour.

(Nearly all of the code from D3 3.x has been rewritten.)

Unfortunately, given how widely used concat_javascript_sources is, this required changing a lot of tests. It would be nice if we could remove some of the duplication in these tests (so that similar changes would not require updating this many tests), but that can come in another PR.

Now I just need to figure out how to decouple this ball of mud

If I can find some time, maybe I can help pitch in somehow.

That should work, but it's a non-trivial change.

Right now major changes require a deep and broad understanding of the codebase and how things get done.

You’re free to test this activity in a separate unit test.

The legendary cfp-app will become a Rails-to-TRB refactoring tutorial.

You must modify the code surrounding each of those 1,000 calls to compensate for the change.

We could of course refactor our code to rename things any time we like, but we don’t do this enough in practice

If we renamed things more often, then it probably wouldn’t be so hard to name them in the first place.

We also find it hard to agree on what good names and bad names look like, which makes it hard to know when renaming improves a name.

It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

Jbuilder gives you a simple DSL for declaring JSON structures that beats manipulating giant hash structures. This is particularly helpful when the generation process is fraught with conditionals and loops.

Got a bit sidetracked into refactoring the Element visitor code, so haven't actually started on the event handler stuff per se, but that'll come soon. Element stuff is starting to feel a bit more logical and easier to follow.

Refactoring at scale is challenging and a significant investment, so communicating the progress is important both from a business perspective but also as a motivational effect to developers. In this case we used a combination of complexity trend visualizations and Code Health Metric as shown in the preceding example.

I refactored quite a bit of tarball-fetcher now to use actual Promises and asyncawait instead of passing resolve / reject callbacks around. This makes the code quite a bit easier to follow in my opinion, but let me know if anything should be changed there.

I know this is existing code but we can probably use this as an opportunity to "fix" it: it is discouraged to use the async exists method to check for a file and try operating on it.

We don’t need to apply refactorings we don’t want.

Here are few, real-life commits of refactorings that make use of this solution:

This does solve the problem, but now our project and API is structured differently. In large projects it might be very hard to determine how to pull this trick off, or even impossible!

hyperscript is much simpler to refactor and DRY up your code than with JSX, because, being vanilla javascript, its easier to work with variable assignment, loops and conditionals.

Derived data can move between being synchronous and asynchronous without modifying the components that use it.

State can be replaced with derived data without modifying the components that use it.

Templates are prone to unnoticed runtime errors, are hard to test, and are not easy to restructure or decompose.

This is pretty good, but I don’t love that $contactStore.length bit. If we wanted to change the shape of the store from an array to a key-value store or something, we’d have to remember to update this component too. Instead, we can define a new derived store: contactCountStore. It’ll always track the count, which lets this component have less knowledge about the structure of the store. That refactor looks like this:

When a component reaches such a size that this becomes a problem, the obvious course of action is to refactor it into multiple components. But the refactoring is complex for the same reason: extracting the styles that relate to a particular piece of markup is an error-prone manual process, where the relevant styles may be interleaved with irrelevant ones.

(At the point at which it does make sense to turn this into a separate Tooltip.svelte component, the extraction is a completely mechanical process that could even be automated by tooling.)

Primitives are often used to “simulate” types. So instead of a separate data type, you have a set of numbers or strings that form the list of allowable values for some entity. Easy-to-understand names are then given to these specific numbers and strings via constants, which is why they’re spread wide and far.

It would be nice if the tests weren't so implementation specific, but rather tested the essence of the functionality. I tried to make them less brittle but failed. To that end, re-writing all the tests in rspec would be (IMHO) a brilliant improvement and pave the way for better tests in the future and more flexibility in implementation.

Prefactoring is the application of experience to the creation of new software systems. Its relationship to its namesake refactoring is that lessons learned from refactoring are part of that experience.

Refactoring is intended to improve the design, structure, and/or implementation of the software (its non-functional attributes), while preserving its functionality.

However, since problems are only addressed when they arise, maintenance is reactive rather than proactive. Small problems left unaddressed can balloon into major failures due to focus on cost.

Potential for political focus on building new features over technical improvements (such as refactoring)

If you'd just like to see refactorings without Quick Fixes, you can use the Refactor command (Ctrl+Shift+R).

What is code refactoring?Code refactoring means restructuring your existing code, in a way that improves the internal structure but doesn’t change its external behavior. This complex procedure is aimed at modernizing software. It is typically used to increase the system’s maintainability, enhance performance, scalability, security and so on. If performed well, it can help developers discover some hidden bugs or vulnerabilities in the system.Typically, refactoring is done in small steps, called micro-refactorings. Each of these steps is usually a tiny change to a source code that leaves the functionality of the system unchanged, it just makes the code cleaner and simpler. And if you do want to change some functionality of your code, it’s much easier to do with a clean, refactored code.