Frühere Suchanfragen

Keine früheren Suchanfragen

Suchoptionen

Nur verfügbar, wenn angemeldet.
mastodontech.de ist einer von vielen unabhängigen Mastodon-Servern, mit dem du dich im Fediverse beteiligen kannst.
Offen für alle (über 16) und bereitgestellt von Markus'Blog

Verwaltet von:

Serverstatistik:

1,4 Tsd.
aktive Profile

mastodontech.de: ÜberStatusProfilverzeichnisDatenschutzerklärung

Mastodon: ÜberApp herunterladenTastenkombinationenQuellcode anzeigenv4.4.1

#ExtremeProgramming

1 Beitrag1 Beteiligte*r0 Beiträge heute
Amitai Schleier
Code by a computer will often, compared to a human’s, appear

- Less principled, coherent, systemic

- More expedient, forgetful, surprising

In short: even riskier.

If there were such a thing as expertise in managing software risks, you’d want that, right?!

#ExtremeProgramming
thoughtbot

🎙️ Our Director of Software Development for EWAA, @purinkle, appeared on the A Junior, A Senior and I podcast with Steven R. Baker!

He dives into:

✅ Why eXtreme Programming (XP) is still vital today
✅ Its impact on team collaboration and efficiency
✅ Tips for integrating XP into your workflow

If you're into agile and sustainable software, this is a must-listen! 🎧

🔗 Check it out: open.spotify.com/episode/0djMC

Spotify08- On eXtreme ProgrammingA Junior, A Senior and I · Episode
#eXtremeProgramming#AgileDevelopment#SoftwareCraftsmanship
Lou Franco

In 2000, I read about CI/CD, but there weren’t tools yet (CruiseControl came out in 2001). So, we implemented CI by having a physical card that had to be on your desk in order to commit code. Then, you had to go over to our build (desktop) machine, get your code, run the build/test scripts (and fix if you broke them).

We eventually automated it all, but just that step saved a lot of “works on my machine” bugs from breaking our builds.

#extremeprogramming#softwareengineering
Vertigo #$FF

@cosy_skog I've been a professional software engineer since 2001, in the sense that I actually get paid legitimately by large corporations to solve a variety of problems.

The answer is, in my experience, you don't.

All you can really do is trust in your development processes, whichever one you choose to invest time in learning. For me, it was #TestDrivenDevelopment and #ExtremeProgramming.

I often start by creating a crude model of a candidate solution, fully knowing ahead of time that that solution is going to be wrong. But, it starts out as being "good enough" to solve some of the problem at hand. Over time, I just hack on it and refine it, adding tests here and there to verify my understanding and guide my development process. And, yes, there are times, when I go down a wrong path, learn something new about how to do it better, and I end up having to rewrite both tests and production code. It's part of the process. It's frustrating. I often have to walk away from the computer for a day or two to cool off from it. But, it happens, and the end result is usually better for it.

But the process is key -- basically, don't give up, keep chipping away at the problem until you have a solution you are satisfied with, and maybe then move on. Software is rarely ever "done". But, for a given problem, it can be "done enough."

That said, here's a few things I found that works well for me:

  1. Consider designing a solution either from the top-level down or from the inside-out. Never design from the bottom up unless you have sound understanding of the problem domain and customer requirements.

  2. Consider implementing a solution from the bottom-up or from inside-out. Once you have a design (which is really just a "here is how I plan on writing the software components and how they fit together"), it's much easier to lay a working foundation so that you can come to trust in it axiomatically. It's easier to reason about your code if the lower-level foundation has already been proven to your satisfaction.

Try to avoid top-down implementations. These can work (and we have working examples of complex systems written this way, such as the Oberon System and many compilers in the Pascal/Modula family); however, it can also lead to overly complicated implementations. You might find that a lower-level structure doesn't quite fit into the "user interface" (so to speak) of the module you're trying to write, and instead of feeling like you're free to change that interface, you often add adapters or compatibility layers to act as bridges between the high- and the lower-level code. Working bottom up helps eliminate those excess pieces of code.

As you can imagine, working with test-driven development allows you to work "inside-out" which is a valid approach for either situation. You'll often find the quality of the code to sit somewhere in between top-down and bottom-up; some complexities will arise (adapters/shims to facilitate interaction between modules or to support better testing), but it'll not be anywhere near as bad as a purely top-down implementation or a bottom-up design.

Hoping this helps out, and I wish you luck on your learning journey.

AngesagtLive-Feeds
Über