Reflect on Software Engineer
10 Dec 2023
Intro
From the whole course of ICS 314, we covered many topics that I think are very beneficial to any software engineer. While we may have just covered a lot of web dev in this semester there were minor software lessons that I think any software engineer should take away from this course. One of the main lessons that I think any software developer should have taken away from this course is the fact that to create anything you have to do your research. The second thing I think any software engineer should take away from this course is the importance of version control. The next thing would be coding standards, and how helpful they are for libraries and when working with a group of people. Finally, I think another important lesson that should be taken away from this class is testing and continuous development practices (Dev Ops in general).
The Importance of Research
If you did no research this whole semester on any of the projects for this class I seriously don’t know how that would be possible. Whether the research was being done with official documentation from libraries to using ChatGPT you had to search things up (I myself used the official documentation for my research). I think it’s important to develop a bunch of ways to do research whether looking at the open source code to looking at tutorials they all will help on whatever project you work on in the future. By looking at these sources of material you create a skill that you will have to use when working in any software industry. Everyone has different writing styles and different ways they represent what they are explaining so it becomes a skill to understand documentation when it is written.
With this skill comes the other skill of being able to create better documentation. By looking at a variety of different ways you can document a code base you also learn better ways you can document your own code. What kind of comments should I add so people understand the function? How do I represent an API in my documentation so they know how it works? These are questions that by looking at other people’s documentation you can see what works and what does not and develop better documentation because of it. While this may not have been a direct lesson taught in class it is a great underlying lesson that I think people should take away from the class.
Why Version Control
Version control is one of the most important things that could have been taken away from this class. The version control we used in class is Git which is used at almost every tech company nowadays. For people who don’t know what version control is or what Git is, it’s kind of like how when you edit a document in Google Docs on the top you have a history button, and when you click on it you can see all the revisions that happened on the document. It’s very similar to that but with some more features. In Git you can branch off from a project, kind of like creating a copy of the Google Docs document. This allows you to edit it as much without making any major changes to the actual document. Then we have a way to then merge these two projects back together so that way after you verify everything works the actual project now has your changes as well.
Version control makes it easy to manage a project when you have multiple people working on a project. Allows everyone to work on a feature of the project without having to deal with conflicts too much. It also allows you to keep a history of work done so if someone makes a big change that breaks the project you can always revert to a previous point. This is the main reason why Git is so widely used and why big tech companies like Google use it.
Coding Standards
Throughout development on all our projects we always had a coding standard that we had to use. The way this was forced on us was Eslint. Eslint is a very helpful tool so people keep a coding convention used throughout a project. This was also a good helpful way to force us to learn a good coding standard. Almost every company has a coding standard they use that you will have to learn and follow when working with them. Whether they use camel case when naming variables (for example let className or let ClassName), to use all capital letters when dealing with constants (for example const PI = 3.13) these are standards that you will need to follow in any project. These standards make it easy so people can better predict what values mean, and follow a convention if your code base turns out to be a library that other people will use. It’s good that you set a standard so that way it’s easier for the end user in the end. Didn’t you find it interesting when we used libraries such as Bootstrap all their components were camel case with the first letter being capitalized as well? Didn’t it make it easier to guess what a component name could be called so you didn’t have to look at the documentation constantly? These coding standards are very helpful and a good lesson for any software engineer.
Continuous Development / Agile Development
In this course we also so a hybrid of continuous development and agile development. The project was divided up into stories each of which had a section of tasks that needed to be completed by the stories deadline. This is a prime example of agile development which is where the project is broken down into sections that need to be completed. Some companies use agile development in their actual workplace having meetings every week to see if everyone is still on track to finishing their task for the story. This is a great lesson and example of agile development that will help us in the future if we ever work at a company that uses this method.
On top of agile development, we also used continuous development which is where the main branch is constantly updated with new changes and that is constantly pushed to production servers. This allows new features that are being developed to be sent to consumers right away after it’s finished being created. While not many companies do continuous development since it takes time for code to be reviewed they do something very similar. Whatever is on the main branch is usually put through a test and if it passes then it is deployed automatically to all the servers on their network. While we didn’t implement the automatic update when pushed to main we did something very close and demonstrated easily how we could do that with githubs server actions. This was a very good example of how dev ops in companies work to make sure that work is following a standard, testing and verifying everything works, and creating a system to easily deploy the code once everything is verified.
In the end, I don’t think I was much of a fan of agile development, but I do get to say there are a bunch of benefits of this method. This method allows for constant feedback and also provides a way to split the project up for multiple group members. Which is very beneficial if your team is pretty big. I also see how it is very helpful so people can break down a large project into smaller projects making things more digestible when creating it.
Conclusion
In all the lessons that we learned in this class while it may have focussed heavily on web dev, it taught us a lot about software engineering in general. It taught us good lessons and forced us to learn new ideas, and new methods making development a lot easier.