11 answers
Asked Viewed 423 times Translate

Describe the process a software engineer might use for writing a piece of code, from requirements to delivery.


+25 Karma if successful
From: You
To: Friend
Subject: Career question for you
11
100% of 11 Pros

11 answers


Updated Translate

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

Ilaria recommends the following next steps:

https://medium.com/@isaaclyman/steps-to-better-code-e6c3cce0c7f9

3
100% of 3 Pros
Updated Translate

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.


1
100% of 1 Pros
Updated Translate

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!!!!!

"

0
Updated Translate

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.

0
Updated Translate

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

0
Updated Translate

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.

0
Updated Translate

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.

0
Updated Translate

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

0
Updated Translate

Rohit’s Answer

Planning.
Feasibility analysis.
Product design.
Coding.
Implementation and Integration.
Software Testing.
Installation and Maintenance.

0
Updated Translate

Stephanie’s Answer

Hey Jaelany,

There is a beautiful process called SDLC (Software Development Life Cycle) that helps with proper planning and execution of a software project. I used this a lot throughout my college career for many projects for software engineering/developing. Work also shares some of these practices but there is done with a greater team of business and technology that help make this work, versus in school you are pretty much responsible for guiding this process the whole way through. Learning this has helped me understand the work flow from getting it started to developing to maintaining. Here are the "stages" and what they entail:

SDLC Stages -

1. Planning and Requirement Analysis: What is the problem that you are working on creating a solution for? Is it a new creation or are you improving a current system? What are the risks involved that may need to be handled during implementation? What audience are you targeting? These are the kinds of questions you want to ask to properly assess the project's scope.

2. Defining Requirements: This is where you come up with a document that relays all the requirements you came up with, which will be approved or asked to provide more information by the customer, stakeholder, or professor - if done with school.

3. Software Design: When going about any implementation process, write down your thought process before just hitting the ground running starting to code. For me, I find this part very helpful to write out what I am trying to accomplish, work out it's flow, then start to code building off that foundation I laid out for myself. There are also some good online tools to practice that. There's something called UML (Unified Modeling Language) that is a type of software design with many different models that is very nice for taking on challenges and helping you to better visualize what it is you plan to implement.

4. Software Development: Now the code begins where you start to develop based off your system requirements. On the business side, there will be guidelines set in place like styling conventions and programming languages used. Whereas, in school, you get the opportunity to create your own way which is nice because you get to explore building your product and taking on full control of the development process yourself.

5. Testing: Now that you've written code, you gotta make sure it works correctly. Not only are you writing what's called unit tests, which is more code to test your already written code, but you are actually pretending to be the user also in that you test your software how a user would if they were trying it out. You want to find all the ways you can break your software while also finding ways to secure it.

6. Deployment and Maintenance: After your system has passed all tests and checked every requirement, it is now time to put that work into production and start marketing your audience. As time passes, and feedback is given, or someone catches a bug, that is when enhancements and maintenance come about in maintaining your products viability.

Whether it's with work, school, or even personal projects, this process is really helpful when starting a project from the ground up! Along with this are different types of software development methodologies that guide you on how to approach and go through these stages (Waterfall Model, Agile - Scrum, Prototype, etc.).

0
Updated Translate

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.


0