- Agile – modern software development is called agile, whereas the older way of doing it was called waterfall. The longer you take to finish an app, the higher the cost will be. This is why waterfall development is falling out of style, and more people are adopting agile (or at least their own personal interpretation of agile).
- Software doesn’t exist in a vacuum. You have to consider reality, like time limitations. If you didn’t have time as a limiting factor, you could do all sorts of things with coding. But because life is short, and time is money, time management and scheduling need to be considered during development. Sometimes it might mean cutting corners or excluding features in a program and only concentrating on the bare essentials, and only adding in extras if time allows for it.
- Agile consists of sprints, which are short periods when you try to accomplish certain tasks, like getting certain features or testing done for a software product. Agile emphasizes rapid development and faster release cycles. Waterfall is all about features, but agile is about time-to-market. Some claim that agile is better for security too because agile can be applied to security fixes for software too, not just the initial development.
Agile: lots of small and frequent software releases/updates. Modern.
Waterfall: very few infrequent software releases that have a lot of new stuff in each one. Old-fashioned.
- DevOps – Software developers are part of a development team or dev. IT people do IT operations, or ops. DevOps is the attempt to bridge the gap between these two separate roles or departments within an organization. Better communication and coordination between development and operations can help the development cycle. Some places incorporate security into DevOps, calling it DevSecOps. However, some people just say DevOps and include security in it as well.
- Kanban – there’s a way to keep track of goals using something called kanban. A big example of kanban software is Trello, which lets you make boards. Each board is for a different project or department. Within a board, you have multiple lists. Each list has a name, like a category. Some good examples to have could be completed, in progress, and to do. In each list, you can make cards for things that belong in that category. You can drag cards between lists. So when you first come up with a feature for an agile sprint, you put it int the to-do list. Then when you work on it, you drag it to the in-progress one. When it’s done, you put it in the final list. Multiple people can contribute to a single trello board.
- Kanban software allows for straightforward and effective project management. It is beneficial for software development, but you can apply it to pretty much anything.
- Design document – an explanation and possibly a diagram that explains what the program will do and how to break it up into smaller pieces called modules or classes.
- Mockup – A non-functional drawing that shows what the program will eventually look like.
- Something I learned in a college class about Swift/iOS was the concept of making mockups for your program before you start coding it. Just like how you make a structure/skeleton for a paper and do research before jumping right into writing it, you have to do something similar for coding. In an undergrad Java class I took, we learned about UML. However, UML is still very formal, and something I like to do now is make mockups in Keynote, which is like the macOS equivalent to Powerpoint. Another option is to use Photoshop or GIMP, or some diagram or shape software. You could even use MS Paint if you really wanted. It doesn’t really matter which specific thing you use, but especially if you’re doing a program with a GUI, you need to come up with ideas for what it will look like. If there are conditions or extra screens, you can express that with flow charts, or extra slides in a Keynote presentation to show what different things look like, such as when someone clicks on a button, or what an error message will be like.
- This mockup process makes the coding easier because you know exactly what you want to make. Software engineering is more than just coding; it’s also planning, time management, communication, design, code reviews, performance reviews, meetings, and version control. It’s not just typing code in an IDE.
- Use case – what software is intended to be used for.
- Edge case – an unusual case for something. Maybe an edge case for a program is that the user puts the wrong input in, or when they try to upload a file, they give the wrong filetype. Maybe for a program that edits an image, they choose a filename of an image that doesn’t exist. Think of how the user can mess up. Users can and will mess up. Your software has to account for user errors, hardware errors (such as a file being corrupted because of a bad drive), or even attempts at hacking, especially if you’re getting into web development. Think: what am I expecting to happen, but what’s an edge case for something bad that could happen, and how do I account for that and stop it?
Extensibility – the ability for software to have additional capabilities added to it. When you code, you should have the foresight to think about how you could make it easier for you (or a coworker or open source contributor) to add more functionality to it later. Being diligent is great and all, but in the case of overengineered extensibility features, it can sometimes be misplaced effort, especially for personal projects as opposed to code for work. Some might argue and say obsessing over extensibility is a waste of time, but on the other hand, if you’re writing important stuff that might need to be maintained over a long period, you might as well try to make it easier to read and add to. Small and straightforward programs that won’t be used for much can ignore extensibility, but enterprise software needs it.
- Refactoring – rewriting your code to do the same things it does now, but in a more efficient way. When you have spaghetti code, you might want to consider refactoring it so that it will be easier to maintain and extend.
- Undocumented features – features of software that aren’t written about in the official documentation, maybe not even in code comments, so it’s hard to know that it even exists.
- Cross-platform – a program that can run on multiple operating systems is called cross-platform.
- Sandbox – a separate area for something that is sectioned off. This can be for security, privacy, or stability. A sandbox can be used for testing something or playing around. A malware analyst might use sandbox software to prevent the malware they’re analyzing from spreading to their computer outside of the analysis environment. If you’re making an iOS app in Xcode on a Mac, you can use a type of sandbox for Swift called a Swift Playground, which is an easy way to get right into coding Swift without much effort.
Dependency – something that a program relies on. Without all the dependencies, software can’t run. It might also need to be configured in a very specific way. If you write a program in Python, then Python is a dependency for it. MacOS and Linux come with Python preinstalled, but Windows does not. If you write a Java program, someone can only run it if they install Java first, because that’s a dependency. If you write a shell script that uses multiple non-standard command line tools, those are dependencies. Keeping track of dependencies is good.
- Sometimes, you can run into an “it works on my machine” issue because you as the developer have specific versions of the dependencies on your computer, but a user has different versions. Let’s say there’s dependency A and dependency B. You have dependency A version 1.5 and dependency B version 4.6 installed on your computer. A user running your software has dependency A 1.5 and dependency B version 4.2. It might not run because they have a different version of dependency B. Then you will be confused because they will tell you that they have the dependencies installed and it’s not behaving the way it’s supposed to. Fortunately, modern technology such as containers can alleviate this issue. Containers package up your software with all of the specific versions of its dependencies, ensuring that it can run on another person’s machine.
- One thing I learned is that JDK 11 no longer includes JavaFX, even though it was supported in previous versions. You have to install it separately now (OpenJFX) because I guess Oracle only wants the JDK to be for core stuff and any optional modules will no longer be a part of it. So instead of setting up some separate complicated dependency, I just decided to recreate the older stuff I had before, using the old JDK 8 and changing the IntelliJ project structure not to use Java 11, even though I have it installed. Probably not a good thing to use older versions of Java. I’m not alone in this though.
- Dev, test, and production (a.k.a. prod) – the three places your code will run. First, you run it on your development machine when you’re in the process of writing it. Then you run it on a test machine, sometimes called a staging server. From there, if it passes tests to make sure it’s stable and bug-free, it will be pushed to production. Don’t make changes directly to production. When something has been adequately tested and is a candidate for being added to production servers, it is referred to as “production ready.”
- Reading vs. writing – writing code is a lot easier than reading. But working on other people’s open source projects will force you to read other people’s code more. It’s imperative that you learn how to read other people’s code. It’s not as easy as it sounds. You understand your own personal thought process. But looking through someone else’s code is harder because everyone thinks in a different way.