[HN Gopher] Snippet-Driven Development
___________________________________________________________________
Snippet-Driven Development
Author : drakerossman
Score : 35 points
Date : 2022-09-24 17:49 UTC (2 days ago)
(HTM) web link (drakerossman.com)
(TXT) w3m dump (drakerossman.com)
| didibus wrote:
| Would like the author to describe the kind of applications/use-
| case they apply this too? And maybe detail what the next step is
| of incorporating that snippet back in the actual application?
| nine_k wrote:
| Yes and yes. Works like a charm for me when I need to learn a new
| area, including an unfamiliar area in a large existing codebase.
|
| Start with tiny snippets. Spend a lot of time in a REPL, or write
| tiny tests, learning basic facts, proving intuitions, and
| connecting the dots. Write a lot of comments describing the
| findings, linking to the docs, etc. Ignore the urge to structure
| things beyond small, easily observable functions: not enough is
| known yet.
|
| Eventually I convert a worksheet full of tiny snippets into a
| worksheet with a number of more interesting functions added, then
| with functions connected so that parts of the actual problem get
| solved. I can track the solution at every step back to the tiny
| snippets and comments.
|
| Then I turn the worksheet into something like real code, using
| most of these functions, just structured properly, with tests
| split out, etc.
| d3ckard wrote:
| So... macros? This is how it sounds to me.
| Jtsummers wrote:
| No, more like:
|
| 1. Get a feature request.
|
| 2. Create a standalone program that does _just_ that thing
| (pulling in, presumably, whatever is needed from the primary
| application(s), otherwise you 're reinventing the wheel a lot).
|
| 3. Do V&V on this, use it, but leave the code alone.
|
| 4. Some time later, merge it with the primary application(s)
|
| (4) would usually require a refactoring/cleaning up to ensure a
| clean separation between UI and logic layers in the "snippet".
| Once done, the logic portion should be incorporable into other
| applications more easily because it's been converted into a
| library.
|
| I usually don't delay between (3) and (4), but take basically
| the same approach. Convert the primary application into a suite
| of libraries and the glue code between them and UI code (this
| is an ongoing process if it's a legacy application, this is
| what I try to do early on otherwise). Those libraries can be
| reused for a "snippet"/spike/whatever you want to call it to
| avoid reinventing the wheel. The new program is brought up,
| used enough to be confident in it (combination of testing and
| real-world use), then its logic is properly modularized (if it
| wasn't already) and reincorporated into the primary
| application.
|
| Repeat with the next thing. If all the necessary components are
| present, but not the glue/UI for it, then you can skip that
| process (or most of it) and just work on the main application.
| jayjader wrote:
| An interesting read. Near the end I started to feel like what the
| author is describing is very similar to the general approach I've
| coalesced on, over the years.
|
| I've always deleted the snippet(s) in question after implementing
| the full behavior, however - or, more accurately, absorbed them
| into the final implementation piece-by-piece.
|
| More recently, my team at work has started committing a logbook
| into our project repo for similar reasons of recording technical
| musings for posterity. Also similar to what the author describes,
| only in our case we are effectively _starting_ from the readme
| files and introducing code snippets where we feel the need. We're
| also maintaining the log as a single file - the plan is to
| archive 3- or 6-month chunks at a time as separate files once
| they reach a certain age.
|
| This logbook experience makes me very curious as to how the
| author manages their snippets in practice. I wish they had gone
| into more detail than
|
| > if you're able to keep on top of things [...] it mandates
| discipline
|
| The baked-in chronological component of the logbook makes it
| straightforward to look topcis up by roughly _when_ they were
| deliberated on, but it's not great at guaranteeing a _valid_ code
| snippet exists that encapsulates any given deliberation.
| Conversely, snippets that
|
| > should not even be conceptually aware of another snippet's
| existence
|
| and be treated
|
| > as a fully self-sufficient standalone program
|
| seem to force me to incur a substantial _obscuring_ of how any
| given musing or deliberation builds on what came before. At the
| least, many snippets will start with 10-20 boilerplate setup
| lines and class definitions.
|
| Perhaps I am just wishing the author had explicitly mentioned if
| they import existing modules, functions, classes, etc as needed
| to keep the snippets short. If that is indeed an implicit
| assumption, then overall I don't have much to critique. If not, I
| am _very_ curious as to what snippet-driven development for
| "framework-heavy" frontend code (eg React apps) looks like.
| drakerossman wrote:
| Thank you for all the valuable feedback. And thank you for the
| insight on how your team organizes a logbook. I'll try to
| expand on the process of the snippet organization itself when I
| have time for it (there's a newsletter on my website you may
| want to subscribe to).
|
| Addressing the "fully self-sufficient program" - no, the
| imports are limited to minimum, at least from the owned
| codebase. 3rd party libraries are okay - the point is to limit
| the system coupling, and also to provide a fresh and unburdened
| look onto the functionality piece. Think github gists - you
| find them via google, they solve some pain point of yours, and
| they also serve as an "etude" for their authors.
|
| After all, this development approach is a very psychological
| thing (and I would say, every approach is). It also aims to
| solve the issue of developer's burnout, the fear of an
| extremely big-scoped work, and gives possibility to ship as
| often as physically possible. Having a lot of snippets is way
| better than having something in development for weeks without
| any insight on what is being worked on. And when you've
| accumulated quite a lot of snippets, the task of gluing those
| together becomes a rather playful quasi-snippet in itself.
|
| Speaking of the "framework-heavy" stuff, React included, - yes,
| it would definitely be harder to implement this strategy
| compared to, say, backend development, - you gotta have a lot
| of boilerplate just to make the snippet run (after all, it
| should be at least viewable in browser, which is already a
| lot.) But you still can use this way of development with a
| moderate success (and depending on your managerial skill or
| self-control): the front-end developer would have to
| accommodate and internalize the fact, that snippets are to be
| written with more boilerplate, and after all, React is
| component based, and components are already snippets per se.
| Etheryte wrote:
| Unless I misunderstood the intent, this sounds like a rephrasing
| of the Unix philosophy. Evidently the approach works for certain
| types of problems and up to a point, but we've all seen a shell
| script hell of one sort or another in our lifetime. I don't see
| this rephrasing addressing that problem. At some point you are
| going to need more complex things than a composition of a few
| simple programs, and that's where the real difficulty lies.
| drakerossman wrote:
| It is a nice comparison, but I would honestly say, that I never
| had Unix in mind in regards to this approach. And I would say,
| it again lacks the "catch" I've mentioned in the article: Unix
| philosophy implies composability, while here you treat your
| snippets as etudes, isolated etudes, which may or may not
| compose well, while always keeping in mind, that you are doing
| all that to eventually tackle a bigger problem.
| thor_molecules wrote:
| Sounds like a Lisp or Jupyter Notebook workflow (or maybe more
| broadly, the "literate programming" paradigm)
|
| I'm not sure how to do this with a SpringBoot/NodeJs app that you
| would find in 90% of shops
___________________________________________________________________
(page generated 2022-09-26 23:02 UTC)