Difference between revisions of "Talk:Refactoring"
Skilgannon (talk | contribs) (→Refactoring woes: a messy king...) |
Darkcanuck (talk | contribs) (→Refactoring woes: two guns) |
||
(2 intermediate revisions by 2 users not shown) | |||
Line 8: | Line 8: | ||
* [[DrussGT]] could use a lot of refactoring, at least as far as readability goes, I admit. However, I'm at a point with it where if I add ''any'' overhead it will start skipping turns left right and centre. (It already skips turns whenever the flattener is enabled and it gets hit.) I'm working on fixing this, and possibly improving the flattener simultaneously (having my bot as a reference bot provides strong incentives to change it's functionality). Also, because [[DrussGT]] 'grew', there are lots of small but important things that are hiding in dark corners of large methods. I'm fairly sure that any refactoring attempt will break something. --[[User:Skilgannon|Skilgannon]] 19:48, 4 August 2009 (UTC) | * [[DrussGT]] could use a lot of refactoring, at least as far as readability goes, I admit. However, I'm at a point with it where if I add ''any'' overhead it will start skipping turns left right and centre. (It already skips turns whenever the flattener is enabled and it gets hit.) I'm working on fixing this, and possibly improving the flattener simultaneously (having my bot as a reference bot provides strong incentives to change it's functionality). Also, because [[DrussGT]] 'grew', there are lots of small but important things that are hiding in dark corners of large methods. I'm fairly sure that any refactoring attempt will break something. --[[User:Skilgannon|Skilgannon]] 19:48, 4 August 2009 (UTC) | ||
+ | ** I don't think I'm convinced - all the reasons you give sound to me like reasons you ''should'' refactor or rewrite. =) Ideally, a refactor would reduce overhead and/or improve performance (mine certainly have). And about those "small but important things that are hiding in dark corners of large methods"... bringing them out into the light during a rewrite might end up gaining you points if you find bugs / quirks in them. That was certainly the case with the [[Dookious]] rewrite (and he was already at #1 and 2100+). If a refactor could break stuff because it's not clear how it all works, maybe it's already broken? Not that I want you gaining any more of a buffer on that #1 spot... :-P --[[User:Voidious|Voidious]] 20:09, 4 August 2009 (UTC) | ||
Yep, I hear you. I have a somewhat similar situation right now, myself. [[Dookious]] has really clean and robust wave handling, built with extensibility and [[Virtual Guns]] in mind. With [[Diamond]], I really didn't see myself focusing on 1v1 for a long time, so the gun code is kind of minimalist. Well, now I'm really excited by the [[Anti-Surfer Challenge]], and of course Diamond is the bot I've been focused on lately. But to get started on an AS gun for Diamond, I'll need to either refactor to include a nice Virtual Guns implementation (with melee support), or find an innovative way to do it in one gun ([[Gaff]] comes to mind). It's not like Virtual Guns is that tough a problem, but I really don't feel like dealing with it. =) --[[User:Voidious|Voidious]] 13:22, 4 August 2009 (UTC) | Yep, I hear you. I have a somewhat similar situation right now, myself. [[Dookious]] has really clean and robust wave handling, built with extensibility and [[Virtual Guns]] in mind. With [[Diamond]], I really didn't see myself focusing on 1v1 for a long time, so the gun code is kind of minimalist. Well, now I'm really excited by the [[Anti-Surfer Challenge]], and of course Diamond is the bot I've been focused on lately. But to get started on an AS gun for Diamond, I'll need to either refactor to include a nice Virtual Guns implementation (with melee support), or find an innovative way to do it in one gun ([[Gaff]] comes to mind). It's not like Virtual Guns is that tough a problem, but I really don't feel like dealing with it. =) --[[User:Voidious|Voidious]] 13:22, 4 August 2009 (UTC) | ||
: As a note, [[User:Rednaxela/SaphireEdge|SaphireEdge]] also does it in one gun just as much as [[Gaff]] does. I would say though that their approach is not all that different from eachother. --[[User:Rednaxela|Rednaxela]] 14:49, 4 August 2009 (UTC) | : As a note, [[User:Rednaxela/SaphireEdge|SaphireEdge]] also does it in one gun just as much as [[Gaff]] does. I would say though that their approach is not all that different from eachother. --[[User:Rednaxela|Rednaxela]] 14:49, 4 August 2009 (UTC) | ||
+ | |||
+ | : Actually, [[Gaff]] uses two guns, one for each network. The whole thing is pluggable, including the module that selects the final firing solution. In Gaff's case that involves summing the outputs and selecting the largest, but I have other modules including choosing the best hit rate, etc. --[[User:Darkcanuck|Darkcanuck]] 05:22, 5 August 2009 (UTC) | ||
Yes, refactoring is always annoying. You basically have to do repetitive work and get roughly the same function, and you're temporarily doing a step backwards because most of your code won't interact well yet with the new component. Right now I have many classes where I just defined variables as public, instead of making setXXX() and getXXX() methods, and I'm really not motivated enough to change that. :P --[[User:Positive|Positive]] 13:40, 4 August 2009 (UTC) | Yes, refactoring is always annoying. You basically have to do repetitive work and get roughly the same function, and you're temporarily doing a step backwards because most of your code won't interact well yet with the new component. Right now I have many classes where I just defined variables as public, instead of making setXXX() and getXXX() methods, and I'm really not motivated enough to change that. :P --[[User:Positive|Positive]] 13:40, 4 August 2009 (UTC) | ||
+ | |||
+ | I was on vacation and had a lot of spare time when I decided to continue my robocode project and found out it could use some refactoring. Now this is my last week of vacation and the refactoring isn't done yet, it is more like a total rewrite... Nevertheless, I must admit I was able to improve a little my project's peformance and speed. --[[User:Navajo|Navajo]] 22:04, 4 August 2009 (UTC) |
Latest revision as of 06:22, 5 August 2009
Refactoring woes
Who else dislikes realizing doing some refactoring would be for the best, when they really have an urge to just want to get some functioning code out there? After some work on my melee bot today, I ended up coming to the conclusion that while my old enemy tracking framework I had in SaphireEdge didn't break with the less frequent scans of melee (and in fact my wave tracking code needed only a one line bugfix to support melee firing detection), it was poorly architectured to naturally support some of the things I wanted to do with interpolation of enemy ticks not scanned. Due to that I'm now rewriting large parts of my enemy tracking code. But man, I really don't want to, I just want to get something on the battlefield that works better than my old MiniSurreptitious. Who else knows this feeling? Any stories of refactoring woes? --Rednaxela 4:26, 4 August 2009 (UTC)
Well, I did know this feeling very well. I think I know one robot which really need a lot of refactoring (I'm looking at you, User:Skilgannon =)) My own BlackHole, at first I tried to split the Wave Surfing part into small parts (from the base of BasicSurfer). But when I'm developing them, I'm too lazy to split them all up. It is now really messy and I have one BIG bug in the second wave surfing which make it act very awful. When I tried to fix it, result in far worse movement. I can't fix them now since I don't know where I changed them and I'm so careless that I have very unmeaningful variable names. I'm too lazy to figure it out so I decide to leave it as it is.
Another thing I have is my own buffer system. I've finished a good VCS buffers system that allow me to add/change them easily (easier than DrussGT's). But when I decide to add support for thee Dynamic Clustering and Neural Network buffer, I rewrote it and I can't finish it. I think we've got the same things here. (along with Bulky Project Demotivation) » Nat | Talk » 12:32, 4 August 2009 (UTC)
- DrussGT could use a lot of refactoring, at least as far as readability goes, I admit. However, I'm at a point with it where if I add any overhead it will start skipping turns left right and centre. (It already skips turns whenever the flattener is enabled and it gets hit.) I'm working on fixing this, and possibly improving the flattener simultaneously (having my bot as a reference bot provides strong incentives to change it's functionality). Also, because DrussGT 'grew', there are lots of small but important things that are hiding in dark corners of large methods. I'm fairly sure that any refactoring attempt will break something. --Skilgannon 19:48, 4 August 2009 (UTC)
- I don't think I'm convinced - all the reasons you give sound to me like reasons you should refactor or rewrite. =) Ideally, a refactor would reduce overhead and/or improve performance (mine certainly have). And about those "small but important things that are hiding in dark corners of large methods"... bringing them out into the light during a rewrite might end up gaining you points if you find bugs / quirks in them. That was certainly the case with the Dookious rewrite (and he was already at #1 and 2100+). If a refactor could break stuff because it's not clear how it all works, maybe it's already broken? Not that I want you gaining any more of a buffer on that #1 spot... :-P --Voidious 20:09, 4 August 2009 (UTC)
Yep, I hear you. I have a somewhat similar situation right now, myself. Dookious has really clean and robust wave handling, built with extensibility and Virtual Guns in mind. With Diamond, I really didn't see myself focusing on 1v1 for a long time, so the gun code is kind of minimalist. Well, now I'm really excited by the Anti-Surfer Challenge, and of course Diamond is the bot I've been focused on lately. But to get started on an AS gun for Diamond, I'll need to either refactor to include a nice Virtual Guns implementation (with melee support), or find an innovative way to do it in one gun (Gaff comes to mind). It's not like Virtual Guns is that tough a problem, but I really don't feel like dealing with it. =) --Voidious 13:22, 4 August 2009 (UTC)
- As a note, SaphireEdge also does it in one gun just as much as Gaff does. I would say though that their approach is not all that different from eachother. --Rednaxela 14:49, 4 August 2009 (UTC)
- Actually, Gaff uses two guns, one for each network. The whole thing is pluggable, including the module that selects the final firing solution. In Gaff's case that involves summing the outputs and selecting the largest, but I have other modules including choosing the best hit rate, etc. --Darkcanuck 05:22, 5 August 2009 (UTC)
Yes, refactoring is always annoying. You basically have to do repetitive work and get roughly the same function, and you're temporarily doing a step backwards because most of your code won't interact well yet with the new component. Right now I have many classes where I just defined variables as public, instead of making setXXX() and getXXX() methods, and I'm really not motivated enough to change that. :P --Positive 13:40, 4 August 2009 (UTC)
I was on vacation and had a lot of spare time when I decided to continue my robocode project and found out it could use some refactoring. Now this is my last week of vacation and the refactoring isn't done yet, it is more like a total rewrite... Nevertheless, I must admit I was able to improve a little my project's peformance and speed. --Navajo 22:04, 4 August 2009 (UTC)