add utterances
ci/woodpecker/push/woodpecker Pipeline failed
Details
ci/woodpecker/push/woodpecker Pipeline failed
Details
This commit is contained in:
parent
c4b29c5e6f
commit
ab1597a28b
|
|
@ -9,4 +9,43 @@ heroAlt: ruins
|
|||
draft: true
|
||||
---
|
||||
|
||||
It is the inevitable nature of code to be refactored.
|
||||
It is the inevitable nature of code to be refactored. How do we make it a less
|
||||
painful process?
|
||||
|
||||
It pains me to start a stream-of-consciousness type of article with a
|
||||
definition, but to set things straight let's be sure we're talking about the
|
||||
same thing. When I say **refactoring** I mean changing potentially large parts
|
||||
of the codebase purely for the sake of making it more "organized". For some
|
||||
definition of organized.
|
||||
|
||||
As software developers, we usually think of refactoring as something we do in
|
||||
order to make something easier. A common example would be something like a few
|
||||
lines of code that people on your team have just been copy and pasting
|
||||
mindlessly everywhere, because to make it generic would mean that they would
|
||||
have to touch code outside of their little bubble and then reviewers get
|
||||
hesitant at the diffs and yadda yadda all kinds of problems supposedly.
|
||||
|
||||
Now it's your turn, and you have to change something tiny in those few lines of
|
||||
code ...everywhere. Before you go in and start abstracting all of it into
|
||||
something more generic, take a breather and think for a second: is it worth it
|
||||
to refactor?
|
||||
|
||||
If your refactor involves adding some extra helper classes or you're pulling out
|
||||
your toolbelt of design patterns, **you are creating complexity**. And in the
|
||||
software world, complexity is the real devil.
|
||||
|
||||
Many people try to code in an "extensible" way in order to avoid refactors, with
|
||||
extravagant interfaces and inheritance patterns. But all they've created is just
|
||||
a larger mess that's harder to clean up later down the line when it eventually
|
||||
needs to be rewritten. And it _will_ eventually need to be rewritten.
|
||||
|
||||
Let's talk about object-oriented programming. There's this bizarre
|
||||
[open-to-extension but closed-to-modification][1] principle I've observed where
|
||||
people are so resistant to changing their source code that they'd implement
|
||||
heaps of useless design patterns on top of it in order to keep their little
|
||||
classes from ever being touched.
|
||||
|
||||
[1]: https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
|
||||
|
||||
If that doesn't sound insane to you, let's take a look at a case study. Suppose
|
||||
you're writing some code that takes in a request type,
|
||||
|
|
|
|||
|
|
@ -6,11 +6,14 @@ import "../styles/global.scss";
|
|||
import "katex/dist/katex.min.css";
|
||||
|
||||
interface Props {
|
||||
title?: string;
|
||||
pad?: boolean;
|
||||
toc?: boolean;
|
||||
}
|
||||
|
||||
const { pad } = Astro.props;
|
||||
const { title, pad, toc } = Astro.props;
|
||||
const shouldPad = pad === undefined ? true : pad;
|
||||
const hasToc = toc ?? false;
|
||||
---
|
||||
|
||||
<!doctype html>
|
||||
|
|
@ -18,7 +21,7 @@ const shouldPad = pad === undefined ? true : pad;
|
|||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
|
||||
<title>Michael Zhang</title>
|
||||
<title>{title && `${title} - `}Michael Zhang</title>
|
||||
<slot name="head" />
|
||||
</head>
|
||||
|
||||
|
|
@ -28,7 +31,7 @@ const shouldPad = pad === undefined ? true : pad;
|
|||
|
||||
<div class="sep"></div>
|
||||
|
||||
<main class={classNames(shouldPad && "pad")}>
|
||||
<main class={classNames(shouldPad && "pad", hasToc && "hasToc")}>
|
||||
<slot />
|
||||
</main>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ type Props = CollectionEntry<"posts">;
|
|||
|
||||
const post = Astro.props;
|
||||
const { Content, remarkPluginFrontmatter, headings } = await post.render();
|
||||
const { toc, heroImage: heroImagePath, heroAlt } = post.data;
|
||||
const { title, toc, heroImage: heroImagePath, heroAlt } = post.data;
|
||||
|
||||
let heroImage;
|
||||
if (heroImagePath) {
|
||||
|
|
@ -29,19 +29,21 @@ const datestamp = post.data.date.toLocaleDateString(undefined, {
|
|||
month: "short",
|
||||
day: "numeric",
|
||||
});
|
||||
const excerpt = remarkPluginFrontmatter.excerpt.replaceAll("\n", "");
|
||||
console.log("except", excerpt);
|
||||
---
|
||||
|
||||
<BaseLayout pad={false}>
|
||||
<BaseLayout title={title} pad={false} toc={toc}>
|
||||
<meta slot="head" property="og:title" content={post.data.title} />
|
||||
<meta slot="head" property="og:url" content={Astro.url} />
|
||||
<meta slot="head" property="og:description" content={remarkPluginFrontmatter.excerpt} />
|
||||
<meta slot="head" property="og:description" content={excerpt} />
|
||||
<meta slot="head" property="og:type" content="article" />
|
||||
<meta slot="head" property="og:locale" content="en_US" />
|
||||
{heroImage && <meta slot="head" property="og:image" content={heroImage.src} />}
|
||||
{heroAlt && <meta slot="head" property="og:image:alt" content={heroAlt} />}
|
||||
|
||||
<meta slot="head" property="keywords" content={post.data.tags.join(", ")} />
|
||||
<meta slot="head" property="description" content={remarkPluginFrontmatter.excerpt} />
|
||||
<meta slot="head" property="description" content={excerpt} />
|
||||
<meta slot="head" property="article:published_time" content={datestamp} />
|
||||
<meta slot="head" property="article:author" content="Michael Zhang" />
|
||||
|
||||
|
|
@ -82,6 +84,16 @@ const datestamp = post.data.date.toLocaleDateString(undefined, {
|
|||
|
||||
<div class="post-content" id="post-content">
|
||||
<Content />
|
||||
|
||||
<hr />
|
||||
|
||||
<script
|
||||
src="https://utteranc.es/client.js"
|
||||
repo="iptq/blog-comments"
|
||||
issue-term="og:title"
|
||||
theme="github-light"
|
||||
crossorigin="anonymous"
|
||||
async></script>
|
||||
</div>
|
||||
</div>
|
||||
</TocWrapper>
|
||||
|
|
|
|||
|
|
@ -1 +1,4 @@
|
|||
$breakpoint: 720px;
|
||||
|
||||
$tocWidth: 240px;
|
||||
$tocBreakpoint: $breakpoint + $tocWidth;
|
||||
|
|
|
|||
|
|
@ -98,13 +98,17 @@ pre > code {
|
|||
|
||||
.flex-wrapper > main {
|
||||
min-width: 0;
|
||||
max-width: 720px;
|
||||
max-width: variables.$breakpoint;
|
||||
flex-grow: 1;
|
||||
box-sizing: border-box;
|
||||
|
||||
&.pad {
|
||||
padding: 20px;
|
||||
}
|
||||
|
||||
&.hasToc {
|
||||
max-width: variables.$tocBreakpoint;
|
||||
}
|
||||
}
|
||||
|
||||
@media screen and (max-width: variables.$breakpoint) {
|
||||
|
|
|
|||
|
|
@ -23,9 +23,10 @@
|
|||
}
|
||||
|
||||
.post-container {
|
||||
max-width: 720px;
|
||||
max-width: variables.$breakpoint;
|
||||
display: flex;
|
||||
padding: 20px;
|
||||
box-sizing: border-box;
|
||||
|
||||
flex-direction: column;
|
||||
.toc-drawer {
|
||||
|
|
|
|||
|
|
@ -1,6 +1,4 @@
|
|||
@use "variables";
|
||||
$tocWidth: 240px;
|
||||
$tocBreakpoint: variables.$breakpoint + $tocWidth;
|
||||
|
||||
.toc-wrapper {
|
||||
position: relative;
|
||||
|
|
@ -13,6 +11,7 @@ $tocBreakpoint: variables.$breakpoint + $tocWidth;
|
|||
|
||||
.toc {
|
||||
height: 100vh;
|
||||
box-sizing: border-box;
|
||||
|
||||
ul {
|
||||
list-style-type: none;
|
||||
|
|
@ -53,20 +52,20 @@ $tocBreakpoint: variables.$breakpoint + $tocWidth;
|
|||
}
|
||||
}
|
||||
|
||||
@media screen and (max-width: $tocBreakpoint) {
|
||||
@media screen and (max-width: variables.$tocBreakpoint) {
|
||||
.toc {
|
||||
display: none;
|
||||
}
|
||||
}
|
||||
|
||||
@media screen and (min-width: $tocBreakpoint) {
|
||||
@media screen and (min-width: variables.$tocBreakpoint) {
|
||||
.article {
|
||||
flex-grow: 1;
|
||||
}
|
||||
|
||||
.toc {
|
||||
flex: 0 0 $tocWidth;
|
||||
max-width: $tocWidth;
|
||||
flex: 0 0 variables.$tocWidth;
|
||||
max-width: variables.$tocWidth;
|
||||
|
||||
position: sticky;
|
||||
top: 0;
|
||||
|
|
|
|||
Loading…
Reference in New Issue