Win a copy of TensorFlow 2.0 in Action this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

Challenges in coding

 
Ranch Hand
Posts: 172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi!

Thank you for clicking. I am currently working on a large financial system and I would like to ask you for help. I have been assigned a task to find out a bug and correct it.

Unfortunately, this task has been taking too long and maybe my approach is not correct. For the past 2 weeks, I have been single stepping through the code that spans more than 10 Java files and hundreds of lines for just the save method.

I have documented it with more 8 pages of hand written notes for the save method.

The challenge now is when I create a new record and save it, the database would be locked and I have to use another transaction number to save it again.The problem now is the ids of the record change and I do not know why the record type has also changed. Maybe it is due to the transaction number.

Now I am lost in the labyrinth because I do not know where I had left off the last time and my notes seem to be a mess. I have been working days and nights for this save method.

The technical lead does not help much because he does not reply my Skype messages or emails. The manager is not complaining yet, but I can feel that he is concerned about the time that I have taken this long.

Can anyone point to me a better method of how to document the single step process?

In addition, how should I speak to my manager? Can I be assigned a simpler task or take on another project which other teams have been working on? How would this reflect upon me?

Thank you for reading and advice.
 
Sheriff
Posts: 4889
317
IntelliJ IDE Python Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When trying to make sense of any code I like to start by writing some automated tests that exercise the code I'm interested in. That way I get to see for sure what behaviour works as expected and what doesn't with the added bonus that the tests act as long lived documentation of that behaviour.

I found the book "Working Effectively with Legacy Code" by Michael Feathers to be the most valuable read I ever had on dealing with such problems.
 
Rancher
Posts: 919
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Alan Blass wrote:Hi!

Thank you for clicking. I am currently working on a large financial system and I would like to ask you for help. I have been assigned a task to find out a bug and correct it.

Unfortunately, this task has been taking too long and maybe my approach is not correct. For the past 2 weeks, I have been single stepping through the code that spans more than 10 Java files and hundreds of lines for just the save method.

I have documented it with more 8 pages of hand written notes for the save method.

The challenge now is when I create a new record and save it, the database would be locked and I have to use another transaction number to save it again.The problem now is the ids of the record change and I do not know why the record type has also changed. Maybe it is due to the transaction number.

Now I am lost in the labyrinth because I do not know where I had left off the last time and my notes seem to be a mess. I have been working days and nights for this save method.




Alan, you don't say how much experience you have or much of anything else, other than help you're overwhelmed. There is really no shortcut, you have to find the point in the code where you have the additions that are causing the problems.  You have to visually walk through the code from a point you know what is going on until you get to a place where you need to see what is happening better, but a breakpoint there and start looking at your variables and if they are changing correctly once you figure that out, then start visually going through the code from there until you don't understand again and then set a breakpoint and step through looking at everything again at that point.  There is no shortcut, but you cannot go step line by line through the entire project.

Alan Blass wrote:
The technical lead does not help much because he does not reply my Skype messages or emails. The manager is not complaining yet, but I can feel that he is concerned about the time that I have taken this long.

Can anyone point to me a better method of how to document the single step process?



Everyone there is probably saying: "Oh good, I'm glad I didn't get it for my project." There is no winning if the project lead will not communicate with you, basically, you are going to have to do it on your own.

Alan Blass wrote:
In addition, how should I speak to my manager? Can I be assigned a simpler task or take on another project which other teams have been working on? How would this reflect upon me?



Be open with your manager and tell him, you have not found what is going on yet.  Don't try to throw anyone under the bus, like the project lead for not helping you enough, but tell them you could use more assistance from someone that might be more familiar with the code.  Debuggers generally need to be able to run through huge amounts of code and find the anomalies and are expected to do it on their own or with very little help.  If this is just too much for you, be honest and tell your manager.  Will it reflect on you? You bet it will, but not nearly as bad as going down the road and having the project taken away from you with no progress toward a fix.

I have been in your situation before, and there is no magic to getting out of the bad situation, but here is my formula:

1 - you're freaking out.  Stop it.  Get up, take a walk, take in some fresh air, but get a hold on your head and quit freaking out -- calm gets the job done.
2 - take a look at it with "new eyes", what you've been doing is not working--don't be afraid to say: I'm trying an alternate path... make that plan and follow it.
3 - look at a method at a time and see where the entry points are, the exit points are, and what parameters it expects, then check what unwanted side effects it may have (are all of the variables used in the method local or passed in or are there global side effects that have to be tracked down?)
4 - isolate each object and see how it interacts with the execution path you are tracing
5 - breath and remember calm gets the job done, your mind regresses to a primitive state when stressed, it wants to run for cover and hide--you cannot debug when you are stressed--chill out, be calm and get your higher brain functions started again.
6 - go back to step 1 if you need to.
7 - don't be afraid to cut and rewrite--who knows what craziness went through the mind of the original writer, he might have been freaking out and not put his best or even a good effort out, so maybe it needs to be scrapped and rewritten to do the right things.
8 - be the control freak.  A good programmer has to be able to say: "I know it, this sucks, and I'm going to rewrite it."
9 - you are in charge of how it's done--do it how you know, or make a plan on how to attack the problem, but remember, you are in charge.

those are my basic rules... apply them in any order as needed or not at all, but stop freaking out, make a plan, follow the plan, stop freaking out, remember you are in charge of how it's done don't be afraid to do it.

My biggest problem I had out of college was assuming there was somebody going to tell me how to do it.  NO THERE WASN"T and THERE STILL ISN"T. You choose how to do it, and do it. (BTW: I've been in the game now for about 30 years)

Alan Blass wrote:
Thank you for reading and advice.



Right out of college I had a project dropped on me of 1000's of lines of code that went into production and had a very large number of errors in it, multiple calls per day on failures all through the code.  I literally had to remove all of the code from one of the designers--nothing he had worked not one routine!  You may have to do similar things and rewrite a large part of the project.  If it needs to be done, it needs to be done, and you will have to do it.  Tell the manager and give him an estimate or how long the rewrite will take.  Right now they are probably not getting concerned that it is not done, but they are getting concerned that you do not have a plan of attack on getting a solution.
 
Sheriff
Posts: 15953
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For the second time today I find myself saying "A big YES to what Tim said!"

The WELC book is an indispensable resource for maintenance programmers. Get it, read it, apply what you learn from it. It's an old(er) book but I doubt it will ever be outdated.

Second, Les' points 7, 8, & 9. Take ownership of the code. Be its master, not its slave. "10 Java files and hundreds of lines of code for just the save" sounds to me like just the kind of nightmare the WELC book was written for. Any programmer worth his salt has had to deal with this kind of nightmare in their career. I spent almost eight years doing it and I came out of it a better programmer with a dog-eared copy of WELC held tightly in my hands. I also came away with an unshakable belief that writing tests first is not only the best but also the most responsible way to be as a developer, both to yourself and to others who come after you.

An essential companion to the WELC book is Martin Fowler's "Refactoring: Improving the Design of Existing Code." This book (1ed/2ed) catalogs common code smells (22/24) and refactoring techniques (70+/70+) to address them.

Yes, that's a lot of smells and even more possible ways to deal with them. But there are three refactorings you can apply immediately:

(continued...)
 
Junilu Lacar
Sheriff
Posts: 15953
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The three basic refactoring techniques you can apply immediately are:

1. Rename - probably the easiest one and least risky, especially if you have a good IDE like Eclipse or IDEA. Technical debt is manifested as a lack of understanding of what the code is doing. Since you've been at this for days with little progress, I would say you are close to bankruptcy in terms of the amount of debt (i.e., lack of understanding) you're dealing with. I would bet you a few dollars that despite all your note-taking, you still come back to some/many sections of the code and have to sit and stare at it a little/a lot to figure out what it means/does. Stop this nonsense. Once you gain some understanding of what that section of code does, rename things so that the code reflects your understanding.

2. Extract - After you've renamed things so the code better reflects your understanding, try to isolate and extract it to a separate method with package private (default) access. This allows you to write one or more unit test for it. Keeping it package private also means you don't intend to make it part of the API of the class. It's a dirty trick I've used many times as an intermediate step when dealing with very messy code. The tests will document your understanding of how that little section of code behaves. These are what Michael Feathers calls "characterization tests" because they characterize what you believe is the behavior of the class under test.

3. Compose methods - when possible, keep everything at the same level of abstraction. Composing methods is about clarity and being able to quickly understand intent. This is really the end result of renaming things and extracting things to their own methods. A composed method consists of many calls to smaller methods that express their intent well. Look for examples by searching for Compose Method refactoring

That's it.

(continued...)
 
Junilu Lacar
Sheriff
Posts: 15953
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you start applying those three refactoring techniques ruthlessly to your code, you will soon find it more amenable to understanding it quickly and being able to navigate through the complexity. It will also be easier to find that bug. If you're successful in doing this, there's a good chance that you'll make the bug manifest itself after you've extracted the section of code where it exists and write a characterization test that surprisingly fails because of the bug. You might even find it earlier because through renaming and increasing the clarity of the code you've made it obvious.

C.A.R. Hoare wrote "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."

For many reasons, most code is written the second way. It takes a lot of skill and savvy to be able to write code the first way. Those two books and these three refactoring techniques are your basic tools to get you from the second way to the first way.

One final (to this series of replies) note: Extracting to a separate method also helps you eliminate duplication. You'll probably find a lot of duplication in those 10 Java files and hundreds of lines. And duplication is not just mechanical, character-per-character duplication. Duplication also exists as the same intent or knowledge or action done on variable parameters. Where you can, extract the duplicated intent, knowledge, action and parameterize the variable parts. This will also help you clarify the code and significantly increase the signal to noise ratio.

If you can, post some particularly opaque code here so we can help you figure it out and suggest how you can refactor it for clarity. By "opaque" I mean "not clear" and defies or hinders understanding.
 
Junilu Lacar
Sheriff
Posts: 15953
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a story about how I dramatically proved to a room of developers that Rename and Extract are the key refactoring techniques you have to apply on a minute-by-minute basis as you write code. It's a little bit involved so I'll tell it  later (or sooner ) but the punchline is this: Open up the refactoring menu of any decent modern IDE (right click to open a context menu, then find the "Refactor..." option). I can guarantee that "Rename" and "Extract" are two of the main choices.

(later...)

So, I was giving a presentation on refactoring to a room of 50 or so developers. I had previously given a piece of paper to one of my colleagues before we started. I call this my "Jack Reacher Oline Archer" parlor trick, after a scene in the first Jack Reacher movie. Anyway, before I showed my audience "The 3 Refactorings that will clean up 80% of your code smells," I told them they probably already knew or have used at least two of the three techniques I was about to show them.

To test my theory, I took a quick survey of the room asking for a refactoring and then having everyone who had used it raise their hand. We ended up with about five refactoring techniques tallied up on the board. Rename came in with the most marks with Extract coming in a close second. Then, I had my colleague pull out the piece of paper I had given him before the presentation and read what I had written on it out loud: "Results will be: #1- Rename, #2-Extract, maybe 3 or 4 others."

What would I have done if the survey didn't match my prediction? Well, first of all I don't tell the audience about the piece of paper I gave my colleague beforehand. I'll only do that if the results match the prediction. If the results are different, I just skip the whole Jack Reacher Oline Archer bit. This has happened to me, too, and I don't even remember what ended up on the list but they weren't any commonly known and named refactorings, more like general descriptions of changes they'd make like "add comments," for example. Of course then I'd have to point out that comments are the #22 code smell listed in the first edition of the "Refactoring" book.
 
I have always wanted to have a neighbor just like you - Fred Rogers. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic