Reviewing your own library, and knowing when it is done

When you read code you wrote yesterday, you do not read what is there. You read what you meant, because your memory helpfully fills in the intention behind every line. That is why your own bugs hide so well from you and are so obvious to somebody else within thirty seconds.

You cannot switch that off by trying harder. What you can do is stop relying on judgement and use a list. A checklist asks the same questions every time, in the same order, whether you are pleased with the code or sick of it, and it asks about things your memory cannot paper over: is there a check for this criterion, does this function say what it does with bad input, does this name still make sense.

This is the last lesson of the course because it is the one that makes the rest durable. Anyone can write code that works today. The reason to review is that the code has to work in three months, when the only thing left of today is what is written down.

Ten items, in this order, because the early ones catch the expensive problems. One: every acceptance criterion from lesson 1 has a check, and that check fails when you deliberately break the code. Two: every criterion is currently green, or is written down as dropped. Three: every public function says what it does with wrong input - reports it, throws, or is documented as trusting its caller.

Four: no function returns undefined by accident on any path. Five: the empty case is answered deliberately for every function that takes a list. Six: nothing inside the library prints, unless printing is its job - a library that logs is a library you cannot use quietly. Seven: no function changes data its caller handed in, unless changing it is the point and the name says so.

Eight: every name would make sense to somebody who has not read the body, and no comment is explaining what a name should have said. Nine: you can state the trade-off behind each decision you kept - not defend it, just say what you gave up. Ten: the out-of-scope list is up to date, so that everything missing is missing on purpose.

Run it top to bottom, write down what fails, and only then start fixing. Reviewing and fixing at the same time is how a review turns into an afternoon of rewriting item three while items four to ten go unread.

Think about how you meet somebody else's library. You do not start at line one and read to the end. You look at the list of functions it offers, you read their names and arguments, and you guess what they do. Only when the guess fails do you open the body.

So review in that order. Write down the seven function signatures of readlog on their own - toSession, summarise, pagesByTag, validateSession, createSession, loadSessions, report - and read them as somebody who has never seen the insides. Can you tell what each one takes and returns? Do two of them sound like the same thing? Is there one whose name promises something the body does not deliver?

This ten-minute exercise finds problems that no amount of reading the bodies will, because the bodies are exactly where your memory of writing them is strongest.

A result whose shape depends on the data. If a summary object gains a field only when some condition is true, then every caller has to test for that field, and the ones that forget will read undefined and carry on. A result should have the same fields every time, with a value saying no, rather than a missing field meaning it.

A copy that is not a copy. Copying a list of records with slice() gives you a new list pointing at the very same record objects, so changing one through the copy changes it through the original as well. Tests that only count the items pass happily while the caller's data quietly changes underneath them.

A catch that protects nothing, as lesson 4 showed. Wrapping a try round code that does not throw looks careful and is decoration - and worse, it makes a reader believe the failure has been handled when nobody has checked anything at all.

There is always something left to improve. A faster tally, a nicer message, one more edge case. If your definition of done is 'I can think of nothing else', you will never ship anything, and the ideas will keep arriving faster than you can implement them.

Done for version 1 is exactly this: every acceptance criterion is met, every check is green, and everything you decided not to do is written down where the next person can find it. That is a state you can reach in an afternoon and defend in a review.

The ideas you did not build are not waste, they are version 2 - and writing them down is what stops them nagging at you. 'Keep a date on each session', 'use a Set for unique titles when the log gets big', 'attach the errors array to the thrown error as well': three lines in a file, and your head is clear.

Be clear about what you have and have not learned. You can model data, write and name functions, handle failure deliberately, prove your code works with checks you wrote yourself, and improve code without breaking it. That is the language, and it is genuinely the hard part - it transfers to every JavaScript project you will ever open.

What this course did not teach, because the sandbox it runs in has none of them, is the platform: the browser's DOM, the network, files, timers and everything asynchronous that goes with them, and the runtimes and frameworks built on top. Nothing here pretended otherwise, and that honesty is the point - a course that showed you fetch in a sandbox with no network would have been teaching you a story.

So the next step is deliberately outward, and this is where the redirecting posture of this product is not a cop-out but the right advice: the official documentation is now readable to you in a way it was not before. Reference pages assume you know what a function, an argument, a return value and an object are. You do. Read MDN's guide pages on the DOM and on promises, and this time the sentences will land.

And build the next small thing. The loop you have practised - brief, criteria, shape, checks, code, refactor, review - does not change with the size of the project. Only the number of times round it does.

You cannot review your own code from memory, so use a fixed list of questions in a fixed order, and write down failures before fixing any of them. Read the public surface first, as a stranger would. Watch for results whose shape depends on the data, copies that share the objects inside them, and try blocks round code that cannot throw. Done means every criterion met and everything else written down as version 2 - not the absence of ideas. Then go and read the official docs, which are now written in a language you can read.