10 answers
2
Questions
Asked
3829 views
Describe the process a software engineer might use for writing a piece of code, from requirements to delivery.
#software #computer-software #software-engineering #technology
Login to comment
10 answers
Updated
Ilaria’s Answer
Hello Jaelany! This is a very good question and there are several ways of doing this depending on how you work. If I could describe this high level I would say:
1. Understand the requirements: make sure that you know what you need to deliver and for what it would be used.
2. Identify which part of code you need to modify: is this going to be something completely new or a modification in an existing code?
3. Have a clear idea of what are your inputs and outputs
4. Comment what you do: writing comments is always important together
5. Follow the correct code style: different languages use different code style, but it is always important to have written a good generic code (ie you cannot identify who wrote it, because everyone writes in the same style)
5. Resolve your issue using the simplest approach: don't forget to consider how long it would take to run your code!
6. Test test and more tests: have tests that make sure both your code works and that it achieves what you want
7. Code review: have your code reviewed by a peer using version control.
Hope this gives you a high-level idea of how t write code!
Ilaria
https://medium.com/@isaaclyman/steps-to-better-code-e6c3cce0c7f9
1. Understand the requirements: make sure that you know what you need to deliver and for what it would be used.
2. Identify which part of code you need to modify: is this going to be something completely new or a modification in an existing code?
3. Have a clear idea of what are your inputs and outputs
4. Comment what you do: writing comments is always important together
5. Follow the correct code style: different languages use different code style, but it is always important to have written a good generic code (ie you cannot identify who wrote it, because everyone writes in the same style)
5. Resolve your issue using the simplest approach: don't forget to consider how long it would take to run your code!
6. Test test and more tests: have tests that make sure both your code works and that it achieves what you want
7. Code review: have your code reviewed by a peer using version control.
Hope this gives you a high-level idea of how t write code!
Ilaria
Ilaria recommends the following next steps:
Updated
RAVI’s Answer
This is a fairly high level view. In my 20 years of software development and then moving to Business Development side of the software solutions, I have seen a lot of variations. Philosophy will be the same. But styles will be different.
It will take a sometime to get used to each software development company, their culture, style and mode of operating. Sometimes multiple groups work in a slighly different manner within the same company as well. Most companies provide adequate time for you to get used to their culture. Without over thinking, just ease into it and you will do just fine.
By the time the requirements are delivered to you, someone has analyzed the business needs and the end user needs to draft the requirements. In other words, you have a clear directions as to what the input is and what the output is and potentially also include the rules you need to follow in transforming the input to the output. You also will have a architecture and data flow diagrams to show where your piece of code will reside and what neighboring systems the code has to interact with: Where do you get the input from - system, user interaction or other means; where to store intermediate/final data; what the output data is going to be; APIs (Application Programming Interfaces) for all these; Programming language/environment is specified as well
Hope that gets you the right understanding. You will probably need to interact with the system engineer (the person who provided the requirements) and the architect (the person who provided the context for your code with respect to the other systems).
You can now formulate how to develop the code with all these parameters defining your working "scope" or "space". You can start thinking about intermediate or temporary data structures to organize the input data/parameters to efficienty code the business rules that transform the input data into the output format requested.
It will take a sometime to get used to each software development company, their culture, style and mode of operating. Sometimes multiple groups work in a slighly different manner within the same company as well. Most companies provide adequate time for you to get used to their culture. Without over thinking, just ease into it and you will do just fine.
By the time the requirements are delivered to you, someone has analyzed the business needs and the end user needs to draft the requirements. In other words, you have a clear directions as to what the input is and what the output is and potentially also include the rules you need to follow in transforming the input to the output. You also will have a architecture and data flow diagrams to show where your piece of code will reside and what neighboring systems the code has to interact with: Where do you get the input from - system, user interaction or other means; where to store intermediate/final data; what the output data is going to be; APIs (Application Programming Interfaces) for all these; Programming language/environment is specified as well
Hope that gets you the right understanding. You will probably need to interact with the system engineer (the person who provided the requirements) and the architect (the person who provided the context for your code with respect to the other systems).
You can now formulate how to develop the code with all these parameters defining your working "scope" or "space". You can start thinking about intermediate or temporary data structures to organize the input data/parameters to efficienty code the business rules that transform the input data into the output format requested.
Updated
Jon’s Answer
In addition to the previous answers, I would emphasize the following:
- know your audience
- Use the KISS method (Keep It Simple Stupid. :) ). A good rule of thumb is that no method (in Java) should be longer than one screen/page.
- Write test cases before or during your software development, rather than after. Write both positive and negative tests. Positive tests verify that your code does what you want it to do. Negative tests validate that it does not have any unexpected side effects
- Use descriptive variable/object/method names. This will greatly improve the readability/understandability of your code. It will also be a great way to "pay it forward" to the programmer coming after you who needs to maintain your code. This also helps to self-document your code.
- Make your code re-usable. By decomposing your functions appropriately, you enable other processes to leverage them. This concept applies whether your are defining a method in your code, an API, or a service. Reusability of code also minimizes bugs because you don't have multiple functions/services that do similar things that need to be maintained.
- Peer review your design and your code. In an Agile world, fail fast and regroup if necessary. It's much easier/faster to fix an issue the sooner you find it.
- know your audience
- Use the KISS method (Keep It Simple Stupid. :) ). A good rule of thumb is that no method (in Java) should be longer than one screen/page.
- Write test cases before or during your software development, rather than after. Write both positive and negative tests. Positive tests verify that your code does what you want it to do. Negative tests validate that it does not have any unexpected side effects
- Use descriptive variable/object/method names. This will greatly improve the readability/understandability of your code. It will also be a great way to "pay it forward" to the programmer coming after you who needs to maintain your code. This also helps to self-document your code.
- Make your code re-usable. By decomposing your functions appropriately, you enable other processes to leverage them. This concept applies whether your are defining a method in your code, an API, or a service. Reusability of code also minimizes bugs because you don't have multiple functions/services that do similar things that need to be maintained.
- Peer review your design and your code. In an Agile world, fail fast and regroup if necessary. It's much easier/faster to fix an issue the sooner you find it.
Updated
Faten’s Answer
This is called SDLC - Software development life cycle.
In a well structured organisation, several resources are involved.
1. Requirement gathering: done by a Business Analyst (sometimes the business himself)
2. Requirement Analysis: done by a Business Analyst to produce something called FSD (Fucntional Specifiction Document)
3. FSD is shared with a technical lead to analyze propose a solution and produce a TDD (Technical Design Document)
4. TDD is shared with developers to do the necessary.
5. Developers will code and proceed with unit testing
6. Quality Assurance / Testing engineers will do their part
7. Business team will come on board to perform UAT (User Acceptance Test)
8. Once validated, deployment is done in production
9. Training is provided for all end-users
In a well structured organisation, several resources are involved.
1. Requirement gathering: done by a Business Analyst (sometimes the business himself)
2. Requirement Analysis: done by a Business Analyst to produce something called FSD (Fucntional Specifiction Document)
3. FSD is shared with a technical lead to analyze propose a solution and produce a TDD (Technical Design Document)
4. TDD is shared with developers to do the necessary.
5. Developers will code and proceed with unit testing
6. Quality Assurance / Testing engineers will do their part
7. Business team will come on board to perform UAT (User Acceptance Test)
8. Once validated, deployment is done in production
9. Training is provided for all end-users
Updated
Subhash’s Answer
"
I recommend following the methodical approach to target this kind of situation.
1. See the big picture, understand the product/solution as a whole before jumping to the next step
2. Gather the requirement and design your thought into the good design document and get it reviewed.
3. Consider all the possible use cases in the design.
4. Now come to the coding part, write the secure code, and avoid all the possible memory leak and segmentation faults.
5. Use code/static analysis tool for memory leak, unused variables, buffer overrun, buffer over follow correction here itself. If any changes required then revisit and make suitable changes. Rerun the static analysis and make sure you don’t have any issue left in your code.
6. In the coding, you have to be very careful with the variable, function file name deceleration. The name of each should be self-sufficient to understand the purpose. Ex: use camel case wording.
7. Always add print messages in the code but it should not be overburden to your process/binary. So make the right judgment while adding the logs.
8. Add different debug levels to the code. Basically write your own print statement where you can define the log level.
9. Try not to use any hardcoded values, if it is required then add them in micro with a useful name.
10. Maintain code hygiene always, like indentation, adding a comment to most or all part of code, limit/boundary checks, null value checks, code should not have multiple returns, initialize all the variables, etc..
11. Do the frequent code check-ins to the repository, this will help you to go back to the working code if something went bad while making changes.
12. A good engineer always keeps a place in the code to sniff in. This will help the developer when there are some issues that hit it the changed code. So don’t make it hard coupled always try to make a loosely coupled.
13. And at the last, take all the code review comments and the QA verification result as positive feedback and learn from your mistake and make suitable changes to the code and move ahead.
There is nothing called perfect code but we always try to give fair justice to the current requirement but not on the cost of security/variability as well as it should not disturb the existing features.
Best wishes and happy coding!!!!!
"
I recommend following the methodical approach to target this kind of situation.
1. See the big picture, understand the product/solution as a whole before jumping to the next step
2. Gather the requirement and design your thought into the good design document and get it reviewed.
3. Consider all the possible use cases in the design.
4. Now come to the coding part, write the secure code, and avoid all the possible memory leak and segmentation faults.
5. Use code/static analysis tool for memory leak, unused variables, buffer overrun, buffer over follow correction here itself. If any changes required then revisit and make suitable changes. Rerun the static analysis and make sure you don’t have any issue left in your code.
6. In the coding, you have to be very careful with the variable, function file name deceleration. The name of each should be self-sufficient to understand the purpose. Ex: use camel case wording.
7. Always add print messages in the code but it should not be overburden to your process/binary. So make the right judgment while adding the logs.
8. Add different debug levels to the code. Basically write your own print statement where you can define the log level.
9. Try not to use any hardcoded values, if it is required then add them in micro with a useful name.
10. Maintain code hygiene always, like indentation, adding a comment to most or all part of code, limit/boundary checks, null value checks, code should not have multiple returns, initialize all the variables, etc..
11. Do the frequent code check-ins to the repository, this will help you to go back to the working code if something went bad while making changes.
12. A good engineer always keeps a place in the code to sniff in. This will help the developer when there are some issues that hit it the changed code. So don’t make it hard coupled always try to make a loosely coupled.
13. And at the last, take all the code review comments and the QA verification result as positive feedback and learn from your mistake and make suitable changes to the code and move ahead.
There is nothing called perfect code but we always try to give fair justice to the current requirement but not on the cost of security/variability as well as it should not disturb the existing features.
Best wishes and happy coding!!!!!
"
Updated
Sagar’s Answer
Hi
Software engineer used SDL process which is Software define Lifecycle.
It is well defined process to made final product more reliable, flexible and good in quality. So process has below vital phases:
1. Requirement engineering
2. Product Architecture
3. High level Design
4. Low level Design: Here we do coding.
5. Validation and Verification of Product (Quality Engineering)
6. Final delivery and installation at customer end.
Thanks.
Software engineer used SDL process which is Software define Lifecycle.
It is well defined process to made final product more reliable, flexible and good in quality. So process has below vital phases:
1. Requirement engineering
2. Product Architecture
3. High level Design
4. Low level Design: Here we do coding.
5. Validation and Verification of Product (Quality Engineering)
6. Final delivery and installation at customer end.
Thanks.
Giles Nugent
Executive Vice President, Head of Front Office Technology at PIMCO
7
Answers
Updated
Giles’s Answer
These people are much more qualified than me, especially as it relates to current best practices.
However, an old school opinion can sometimes offer some insights....
Obviously, understand desired outputs, and then list the inputs required (magically or otherwise) that are available to lead to those outputs.
Then, break down the problem into as many independent steps as possible. This is often skipped, but it is fundamentally important to writing scalable code. And, when you commit to this, you will find it easier Han you first imagine.
Then define the interfaces for each component.
Write test inputs / scripts for each component. This is the most important. It forces you to think at a component level, and develop testable scripts that can help you test each component independently and thoroughly. I must admit, I often developed these in partnership with the component development (not best practice), but I never skipped this step. This was a life saver many times over.
Build and expose test scripts around each component. Run them with every update, comparing the outputs.
Maybe this can weave into some of the better answers.
Thanks
However, an old school opinion can sometimes offer some insights....
Obviously, understand desired outputs, and then list the inputs required (magically or otherwise) that are available to lead to those outputs.
Then, break down the problem into as many independent steps as possible. This is often skipped, but it is fundamentally important to writing scalable code. And, when you commit to this, you will find it easier Han you first imagine.
Then define the interfaces for each component.
Write test inputs / scripts for each component. This is the most important. It forces you to think at a component level, and develop testable scripts that can help you test each component independently and thoroughly. I must admit, I often developed these in partnership with the component development (not best practice), but I never skipped this step. This was a life saver many times over.
Build and expose test scripts around each component. Run them with every update, comparing the outputs.
Maybe this can weave into some of the better answers.
Thanks
Updated
Tina’s Answer
Step 1: Know the business on which the code has to be written.
Step 2 : Jot down a flow diagram on a piece of paper and cover every base of functional requirement (e.x.if this happens that should be the output).
Step 3: Define the test coverage, Meaning for every functional requirement there should be a test plan to check your code.
Step 4: Pick the most relevant scripting language used in firm/college.
Step 5: For every piece in process flow diagram write a code and connect it to the other piece through input and output variables. As in process flow every box get some value and in return gives an output to another box.
Step 6: Simulate every class (Module/piece of code) with the test case which should provide an expected input and an expected output.
Step 7: Write a main file which is going to call each and every class in a sequence defined by business/functional requirement.
These steps will ensure the understanding of business and a bug free code.
Step 2 : Jot down a flow diagram on a piece of paper and cover every base of functional requirement (e.x.if this happens that should be the output).
Step 3: Define the test coverage, Meaning for every functional requirement there should be a test plan to check your code.
Step 4: Pick the most relevant scripting language used in firm/college.
Step 5: For every piece in process flow diagram write a code and connect it to the other piece through input and output variables. As in process flow every box get some value and in return gives an output to another box.
Step 6: Simulate every class (Module/piece of code) with the test case which should provide an expected input and an expected output.
Step 7: Write a main file which is going to call each and every class in a sequence defined by business/functional requirement.
These steps will ensure the understanding of business and a bug free code.
Updated
Rohit’s Answer
Planning.
Feasibility analysis.
Product design.
Coding.
Implementation and Integration.
Software Testing.
Installation and Maintenance.
Feasibility analysis.
Product design.
Coding.
Implementation and Integration.
Software Testing.
Installation and Maintenance.
Updated
Josh’s Answer
I am a business analyst, so most of my work happens in the gathering requirements step that several other answers have mentioned. Ideally if you are a software engineer you won't have to do a lot of this, but you will always have to clarify things with the Business analyst, or if you are in a smaller company you may need to do this step yourself. Here is the advice I have for getting requirements:
1) Ask questions - There are a lot of things that are very clear until you have to program them. As you start working you will almost always realize there are more questions that you need to ask.
2) Think about the edge cases - the cases that are at the very edge of what the application will do will often give you the most problems. What happens if a user is putting in incorrect data? What if a different user tries to use this code for something else? You won't always be able to solve all of them, but thinking about them will help make it less common to run into an issue later in the process.
3) Do as much thinking as you can before you start writing code. The earlier in the process that you can find an issue the easier it is to solve. As a Business analyst a huge part of my job is making sure that we don't get half way through a project, then realize that we have another major requirement that we have to add. The farther into the process you are the harder it is to add or change things.
1) Ask questions - There are a lot of things that are very clear until you have to program them. As you start working you will almost always realize there are more questions that you need to ask.
2) Think about the edge cases - the cases that are at the very edge of what the application will do will often give you the most problems. What happens if a user is putting in incorrect data? What if a different user tries to use this code for something else? You won't always be able to solve all of them, but thinking about them will help make it less common to run into an issue later in the process.
3) Do as much thinking as you can before you start writing code. The earlier in the process that you can find an issue the easier it is to solve. As a Business analyst a huge part of my job is making sure that we don't get half way through a project, then realize that we have another major requirement that we have to add. The farther into the process you are the harder it is to add or change things.