Chapter 6

The database is arguably the most essential part to many software projects. It is where the bulk of the important data from users is stored and able to be reused when needed. Part of the data science curriculum at the College of Charleston is centered databases and the management of large data-sets. With that being said, I have slight experience in several SQL queries and other database techniques from the DATA 210 class. The command line is a useful tool when querying data-sets, and trying to find trends in data. One interesting thing about data-bases is that the information stored inside "persists", or is able to exceed the lifetime of the actual program. The data is still able to be used and modified even if the program no longer is viable. Databases are stand alone things that coincide with programs to serve as a data storage. One is able to store  and organize vast amounts of data with relatively simple commands. One such type of organization are tables, which have a fixed number of columns and varying number of rows. An important concept to consider when implementing tables is the idea of normalization. Normalization allows tables to be queried and compared using a standardized language. Tables are able to be quickly queried because the information has its own key which is referenced when searching. This chapter has served as good review for database management, and the specific queries that we learned in Data 210 at the College of Charleston. I have had many conversations with my father about the great importance of databases, and how a company will pay good money to have a database specialist. This is something that I have considered as a career, citing the need for more database professionals in the field. I feel as though as data-scientist with an expertise in database management should go hand in hand, and would make for an essential part of any team.

Chapter 5

Domain classes are a vital part of any software project, and should be considered carefully during the software development process. This object oriented approach to client solutions is what generally makes larger projects more manageable, and often times what makes it even possible. It is always a good idea to break your program up into various classes that contain specific instance variables and functions relative to that class, but also implement some kind of inheritance hierarchy. There are two approaches to coding domain classes in one's program; one being reusing legacy code, or code that has already been established and tested by other developers, and the more labor intensive alternative, starting from scratch. Downloading and modifying previously written code seems the most simple, and safe option when trying to code these classes, but sometimes this proves to be difficult if such classes do not exemplify your specific needs. That is the job of the developer, to determine what the clients needs are and to best serve them with the tools at hand. This chapter has been a good refresher for me in terms of classes in a project, and their specific attributes. Another big concept posed in this chapter is the idea of unit testing, and maintaining an effective testing strategy for your code. I have the most experience in testing throughout the process, or in other words, testing each piece of code and function before moving on. Building on this, the chapter introduced the idea of test driven development, or gathering testing requirements before anything concrete is actually coded. The second implementation of testing seems to be the most rigorous and time consuming, but allows for the most success. Test suites, which are a collection of unit tests, play a pivotal role in the testing process. They allow for the individual testing of specific modules in a program to determine if everything is working as it should. This chapter has provided me with beneficial review in terms of classes and unit testing, as well as introduced me to new concepts and specific frameworks continuing to build my skills as a software developer.

Release early and often

Proper documentation is an extremely vital part of good software. The longevity and viability of said software is greatly dependent on good documentation practices for which future contributors can read and fully comprehend to better maintain and alter the code. In a perfect world, there would be no need for documentation as said in chapter 8, every individual would be have the same coding conventions and would be able to understand any piece of code written by anybody. But sadly that is not the case, everybody has their own way of doing things; naming conventions, spacing and indentations are a couple of instances that allow for stylistic  independence/ expression (Java specifically). Although many are taught to name their variables and methods with clarity and obvious purpose, some time constraints or other factors prevent developers from doing so. There is legacy code out there with simple variable or method names designated as such to save time and to get the code working. The idea of getting the code to work first and cleaning up later is prevalent in the field, but many projects such as government contracting do not allow for this to occur. These contracting jobs are in the market for code that does what they need it to do, no government projects will pay a team to go back and clean up the code, and make it more readable. Harsh deadlines and requirements make it hard for developers to take the time to make readable code, they are just looking to meet the deadlines and complete the sprints on time. Although this is the reality of some projects, it is still imperative that said developers take that extra time to document their code, making the lives of future maintainers, or the developers themselves much easier in the long run. Proper documentation practices can go a long way in this field, and many people will be greatly appreciative for it. One must write code that is relatively easy to understand or have documentation that adequately describes what the purpose of the software. Developers should maintain good developer documentation in the code base, ensuring the future understanding of every function and module. Technical writing is the same as any other kind of writing, know your audience and be as clear and concise as possible.