Reputation: 5 Worker
- Active Posts:
- 38 (0.03 per day)
- 20-January 11
- Profile Views:
- Last Active:
- Oct 29 2013 03:26 AM
- OS Preference:
- Favorite Browser:
- Favorite Processor:
- Favorite Gaming Platform:
- Your Car:
- Who Cares
- Dream Kudos:
Posts I've Made
Posted 28 Mar 2013Thanks for the contributions
You're right about making your own loops LordOfDuct, it's definitely something I should look more into.
Am currently adepting the code-styles from work onto my own code, simply becauses it reduces implementation time when working with the same set of functions/methods/subclasses.
I'll put all tips into motion and see how this ship will sail.
Thanks for taking the time.
Posted 27 Mar 2013Would love too! If their code wasn't insanely complex at some points..
Learned alot of stuff, am still only a student y'know, so fixing a near-30's programmer's code doesn't really sound all that, truthful xD.
Still, I might just give it a shot you know, will start with cleaning up the mess that gets left behind. Thanks for the pro-tip.
Posted 27 Mar 2013Thankfully I also have a lot of free time in my job to use just going in and ripping large parts out as well and refactoring them.
Now I'm gonna turn your Nightmare into Hell.
Since we have stand-ups every day, we must give feedback on the things we did.
Again, results first things are the kind of things that should be talked about.
Sooooo.. It really itches if stand there going "I refactored abit this morning, cleaned some code" while the rest goes on about the recent bug fixes they did and implementations they're planning/doing.
Makes you feel unworthy of the job when you don't have much to tell.
Posted 27 Mar 2013Start by refactoring as much as possible and making the code self-documenting. Comment where necessary, make notes to guide yourself and others through the morass where you haven't cleaned it up, but prefer fixing the code to documenting it. Documentation is a time bomb: every change to the code puts the docs further out of date, and the most-used code is the code that changes the most...
Yea I'd like to give that a try, though my company puts extreme stress to something called "results first".
It basically means: Do whatever is needed, aslong as you can show us the design and use changes asap even if it means sacrificing code-design.
It might be what caused a mess in the first place, my colleague (aka, top-dev) stated today he can't put too much time into good design choices. Might be lack of work-force?
If you can use tools like doxygen to auto-generate docs, that's great. Bake that into your build process.
I'll look it up! Might be worth a shot, it sounds good for starters..
Do you have a build process? Version control, issues list, deployment schedule, testing, and so forth? If not, you should institute those things. Basically, a sane environment requires that all changes come off of an issues list and are committed to a repository, builds are done on a regular basis and tested before deployment, and all commits are logged with at least the tracking number of the issue they address. Getting this in place means that at least you have a way to track how the environment is changing from here out, which allows you some hope of sanity.
Yes sir. We got version control, issues lists and the bunch. (repositories, nightly builds, build versions.. about 80 test databases.. we develop certain parts of our software for individual clients, thus not every client has the same database)
However, what do you mean by deployment schedules? And would testing be "TDD" aka Test Driven Development?
Thanks for the help!
- Member Title:
- New D.I.C Head
- 23 years old
- December 12, 1991
- Years Programming:
- Programming Languages: