Reflection: Liam Brew - SSW-345-Team-5/Discord-Bot GitHub Wiki

Design

When planning the design methods for my project, I frequently referred back to the lecture slides as they provided a good overview for all of the major topics. I had some prior experience in building Discord apps, so I had a good idea of what to use for this project and used the slides when necessary as if they were a form of documentation. I found the design patterns series of lectures to be especially useful. While I didn't implement any of the pattern themselves directly, I designed the system in accordance with many of the pattern-related best practices, such as using encapsulation to hide API keys and and delegation to ensure individual command autonomy.

The most difficult aspect of system design for this project was interfacing between the multiple systems it contained. The bot made use of Discord, the Alpha Vantage Stock Market API, Node.js, Python, a Google Cloud Database and Amazon Web Services, so getting these all to work together was at times challenging. This required frequent cross examination of documentation across the different tools to ensure compatibility and enable support. Oftentimes, the actual technical implementation of these tools were simple as the majority of the were resolved in the on-boarding leading up to that. Therefore, for the next project I would dedicate more time to adequately modeling system process flows and dependencies beforehand. I believe that doing that would have resolved a lot of issues before they began.

Regarding different design methods, for a future project I would like to make true use of object oriented methodology. This will increase the amount of code that can be recycled, help reduce compatibility errors and provide the program with a more modular architecture. Due to the nature of the API for this project, I was reluctant to implement an object oriented design at first as many of the different methods were vastly different in structure and implementation. By the time all API features were successfully implemented individually, a complete object oriented refactor was unreasonable. While I did make use of Node.js's packages and import system to reduce the amount of rewritten code as much as possible, a do believe that a proper object oriented hierarchy would have made the bot even more efficient.

Implementation

Regarding technical implementation, the most useful platform by far was the Visual Studio Code editor. I used this platform for the duration of the project to facilitate remote real-time pair programming with my team through the use of its Live Share feature. When combined with a video call, this created a highly efficient and collaborative environment. Also, VS Code helped manage localhost Node.js instances for development and testing. Additionally, Node.js itself was crucial to the development of the bot. While the APIs that I used are available in other languages such as Python, none of them match the support and functionality provided by Node.js' package system. I made use of several Node.js-exclusive packages such as API wrappers and process flow management tools that drastically increased the efficiency of this project.

The most difficult aspect of this project was by and large dealing with Node.js' asynchronous nature. Due to the large amount of systems at play, precise timing was required to ensure correct execution of each command. For example, some commands required passing in the results of the stock API call into a Python script for graph generation, and then sending said graph as a Discord message. Therefore, the each stage of the program would have to await the successful termination of the previous stage in order to begin. To make matters more difficult, several of the Node.js modules used where asynchronous while others were synchronous, which required further logical interfacing. To overcome this obstacle the team made extensive use of promises to regulate the process control flow. Looking back, I would have removed the JSON file output and instead have each command's Node.js script pass the API outputs directly into the Python script as a parameter. This would have simplified the process and removed unnecessary file read and write operations. The team did not do this originally as it was helpful to have a physical JSON file to read and manipulate while creating the interacting Python script. Additionally, the team faced API limitations, namely a limited amount of calls per minute. This reduced the functionality of the bot, namely the use of the portfolio reporting command feature, and mandates a limited amount of command invocations per minute.

In the future I would like to use and AWS database instead of the Google Cloud one used for this project. Not only does AWS provide more powerful database services, it is better practice to have as many features as possible on one platform. This will assist the project as these features can better interact with each other, as well as removing a platform and its required support entirely. Additionally, for future projects I would like to make more use of Travis CI for testing and deployment to reduce the amount of manual effort needed for those stages.

Process

Kanban and the associated issues/pull requests/code reviews was a great way of assisting project management and ensuring successful schedule completion. The GitHub board/repository interaction served to drastically ease the burden of management for this project. At the start of development, all features were broken down into specific issues and assigned to issue milestones. These milestones were then completely sequentially in preference of the most immediate. The information that the project board provided by tracking issues and pull requests automatically was extremely powerful and important in determining the overall help of the project's schedule and work breakdown structure.

The most difficult aspect of this project's process was writing documentation. Due to our preference of performing technical work, the team relegated documentation writing to the end of each milestone. This was inefficient, as by that point the team had lost some familiarity with some of the earlier aspect of the project and had to re-familiarize themselves with it. Additionally, I found that writing documentation all-at-once does not provide as specific detail as writing it during/at the completion of each feature's development. Therefore, going forward I would have definitely wrote documentation at the end of every working session reflecting the events of said session. This would serve to help archive important information and better reflect the overall development of the project.

In the future, I would like to try a dedicated and complete agile approach to software engineering. As neither I nor my teammates have taken SSW 555 yet, I believe that we were not able to fully leverage the agile methodology to our advantage. We do know that agile is an extremely powerful approach for this type of development work, and would definitely like gain more experience with it.

Overall

I personally found myself dedicating more time and effort to the pursuit of project components that I found most interesting, which in this case was its technical implementation and project management. Therefore I found that the effort I dedicated to the other aspects of the project, such as process modeling and documentation writing, was lacking. Even though these components were just as the technical work, I did not dedicate the same amount of effort towards their success. I feel that this negatively impacted the project and harmed its efficiency as I occasionally found myself having to redo parts of a previous milestone.

Regarding the benefits of the different implemented practices, I was very pleased with the way that functional programming and kanban-style project management benefited each other for this project. Due to the team's architecture design of having each command being a set of three functions in a single file, it was very easy to plan and assign issues and schedule issue milestones on the project board. The minimum amount of command interdependence meant that commands could for the most part be developed individual of each other, which drastically increased the efficiency of the project's implementation phase.