I come across situation where I'd need to render fields outside of current chessboard. That would entail having border on side(s) of rendered board, and then filling border with, say, white and light grey fields, and obviously taking care to match field size and alternating light vs. dark fields with what would be rendered for chessboard.
Obvious solution would be to recycle borders, as already provided by board descriptor. Obvious solution would also be wrong. You see, borders of rendered board were meant to be used for spacing-out image and for border text, like enumerating rows and columns, and not to be recycled to render off-board fields.
It's not that just purpose is violated. What would happen if, for instance, one would need both off-board fields and enumerated rows, columns? Another problem with that kind of "solution" is "mudding the water", i.e. internal structure, names don't match usage anymore, so it's much harder to figure it out what that piece of code actually does.
Real solution is to refactor code if change is small enough, or rework it completely if that's not the case. "Small enough" should be determined solely by the developer who'll do it. Rework might be better idea, it errs on cautious side with no ill effects beside taking a little bit longer if change actually was "small enough".
Also, rework doesn't mean everything has to be written from scratch. For basic stuff (like, in this instance, rendering field, piece) one should actually reuse (copy over and adapt) existing, working, proven snippets, functions, methods.
So, refactor if possible, rework if necessary, reuse what you can, but don't recycle code and it's design, intention, purpose, even if you could, with no known ill effects at the time. Development also includes constantly adapting to changing requirements. Sooner or later, there will be a requirement that challenges violated design, intention, purpose of recycled code.
This is also why it might take some time before I resume work on the book, I'll have to rework board renderer.
No comments:
Post a Comment