Innes Ford wrote:One piece of advice, that one of the more mature students in one of my classes gave to me, was to make small changes, so that I would be able to know if and where things are going wrong. I'm struggling to think how I can do that here.
Innes Ford wrote:The insight you've given me, Junilu, will be especially helpful in deciding the aspects of Agile I will focus on in my report. I'll be sure to emphasize unit testing, I suspect that is something I might have not given enough attention without your input. I can still reflect on failures of my project, as long as I give good reflection I doubt the penalization would be too significant, but it'd be penalized non the less.
Thank you both for the response.
Junilu Lacar wrote:
Code that promotes understanding creates a virtuous cycle.
AgileAgility in software development means using a set of techniques that encourages the creation of virtuous code and the elimination of vicious code.
That is the sort of code you get when people don't think about the rules of the game. Had there been any thought put into that noughts and crosses (=TicTacToe) program, the user would have realised that you only have to check more than three directions in one specific circumstance, and that you only have to start the check from a single square.
Junilu Lacar wrote:. . . I recently wrote an TicTacToe implementation in Java, spurred by a question posted by one of our members. . . . "defies understanding". . . .
Campbell Ritchie wrote:you only have to check more than three directions in one specific circumstance, and that you only have to start the check from a single square.
RR #1: "That kind of looks good. I mean naming those methods "inRow" and "inColumn" really helps make the calling code become more conversational."
RR #2: "Yeah it does, I thought that was a great idea, but... ?"
RR# 1: "... but that spot parameter name doesn't quite capture the idea we were talking about, which is that you only need to check the row and column where the last move was made. There's something missing in that name that makes it fall a little short."
RR #2: "You're right. So, why don't we just make the code say what you just said." (Quickly refactor-renames spot to lastMarked)
Both RRs read the new code out loud.
RR #1 & RR #2: "Brilliant! That captures our thoughts perfectly!" (Fist bumps and high fives)
RR #1: "... you only need to check the row and column where the last move was made ..."
RR #2: "... So, why don't we make the code say what you just said." (Quickly refactor-renames the parameter name from spot to whereTheLastMoveWasMade)
RR #2: "How about that?" (makes a face )
RR #1: "Now you're just being a smartass."
RR #2: "What? That's what you just said, isn't it?"
RR #1: "Yeah, but that name's over the top. It's a bit of a mouthful, too. Just a little too conversational, don't you think?"
RR #2: "Relax, it's just so we can actually see it and feel how much it's NOT what we want to leave in there."
RR #1: "Hey, don't we have a mark(Position spot) method?"
RR #2: "Yes, in fact, we do. That's where we got the name "spot" to begin with."
RR #1: "Well why don't we just make the name we use here consistent with that term, of "marking" a spot? When we say "spot" over here, we really mean "the spot that was marked last," don't we? I think that was the missing part of the thought behind just "spot", right?"
RR #2: "So you mean to say you want to name this parameter like this? ..." (Quickly refactor-renames whereTheLastMoveWasMade to lastMarked)
RR #2: "Let's see what that sounds like now..."
(Both RRs read the new code out loud)
RR #1 & RR #2: "Brilliant! ... "
I wrote:... in my home-office when I have nobody to do pair/mob programming with besides Go Gopher, Darth Vader, Chewie, and Boba Fett.
Innes Ford wrote:I wish I had come to this forum sooner and found such inspiring views and ideas.
Innes Ford wrote:would agile programmers still utilise UML?
Innes Ford wrote:One of the hurdles that gave me apprehension when starting this project was getting the planning right, my inexperience in implementing plans gets me anxious and I tend to procrastinate, I've no doubt the process of planning is extremely helpful in learning to program and anticipating the problems and their solutions of a projects implementation but, unfortunately, that knowledge doesn't really help motivate me.
and it's the inefficiency that pushes me to procrastinate, I'm a perfectionist that doesn't have the drive to be perfect, so I end up looking for distractions. I hope that makes sense.