Skip to main content
deleted 1 characters in body
Source Link
CodeART
  • 4.1k
  • 1
  • 23
  • 23
  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • You need to break down your problem into smaller tasks. Set yourself a goal and work towards the goal. E.g. I want to understand authentication process. Find the code that you think does that and start working through that. If you'll get hang up on entire system, you will be very unlikely to get anywhere in my opinion.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's stronglytightly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • You need to break down your problem into smaller tasks. Set yourself a goal and work towards the goal. E.g. I want to understand authentication process. Find the code that you think does that and start working through that. If you'll get hang up on entire system, you will be very unlikely to get anywhere in my opinion.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's strongly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • You need to break down your problem into smaller tasks. Set yourself a goal and work towards the goal. E.g. I want to understand authentication process. Find the code that you think does that and start working through that. If you'll get hang up on entire system, you will be very unlikely to get anywhere in my opinion.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's tightly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

added 327 characters in body
Source Link
CodeART
  • 4.1k
  • 1
  • 23
  • 23
  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • You need to break down your problem into smaller tasks. Set yourself a goal and work towards the goal. E.g. I want to understand authentication process. Find the code that you think does that and start working through that. If you'll get hang up on entire system, you will be very unlikely to get anywhere in my opinion.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's strongly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's strongly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • You need to break down your problem into smaller tasks. Set yourself a goal and work towards the goal. E.g. I want to understand authentication process. Find the code that you think does that and start working through that. If you'll get hang up on entire system, you will be very unlikely to get anywhere in my opinion.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's strongly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)

Source Link
CodeART
  • 4.1k
  • 1
  • 23
  • 23

  • I was in a similar position after I finished first year at university. Based on that experience I think that you bit more than you can chew on.

The following might make your life easier, but you'll need to put in a lot of work.

  • Gain complete understanding of your problem domain. Talk to the business and model application's features with use case diagrams or something similar. I assume you have unlimited time and resources to do that.

  • Get contacts of people who have worked on this previously. If they are still in the same company, then work with them after you get familiarised with the system.

  • Going through code, documenting what it does will take you a very long time. I doubt that you can afford that.

  • Deploy system in a fresh environment. Hopefully it'l break and you'll have to debug lots of code to see what's happening.

  • Assuming you have the use cases, start to debug through the codebase.

  • Make sure you are clear on why business wants you to review the codebase. Surely it's not just an expensive and pointless exercise, so they must have a good reason. This should give you a good idea where to look.

  • There are tools that analyse codebase and tell you whether it's strongly coupled and how much duplicate code is there. This might be useful, but not at the start of your project.

  • Check whether there are any unit tests. Start running those to see what the system is capable of doing.

Things to keep in mind:

  • It's not an easy task, so don't beat up yourself.

  • There will be a lot you won't understand, so don't hang up on those things and keep moving forward.

  • This is normally quite de-motivational, therefore it's important you take a note of your progress. I normally have this on a whiteboard in front of me.

  • Don't hang up on big numbers. Yes, you can use that in self-defence and 200 classes probably equals to quite a few responsibilities, but this doesn't make your life any easier, so lets look for solutions :)