What I learned as a Software Developer while creating my product
Tags: softwaredevelopment, codereview, codequality, documentation
Published: 2023-11-28 07:39:58

# Code quality
Before creating the code, it is crucial to prioritize its **quality**.
It should be the foremost consideration in the development process.
To ensure **code quality**, we can utilize automated tools that help with code analysis.
However, it's important to note that automated tools may not cover all the necessary rules.
As a result, manual code review becomes essential to enforce coding standards.
Personally, I have dedicated significant time to code reviewing and checking for adherence to [code style](https://github.com/dimanikulin/fva/blob/master/CodeStyle.md).
Additionally, I have employed **Python** to create additional code checks. 
It is worth mentioning that not all rules can be checked automatically, requiring manual effort in certain cases.

# Code documentation
"*Now, hold on!*" you might ask,
"*Are we jumping straight into coding?*" 
My answer is a resounding "*Nope*".

Before embarking on the coding phase, it is vital to consider **code documentation**. 
Since the **FVA Software** employs two programming languages, it is imperative to establish clear documentation rules for both [C++](https://github.com/dimanikulin/fva/blob/master/CodeDocumentation.md) and **Python**.

Consequently, I have familiarized myself with documenting **C++** code using **Doxygen** markdown and have gained proficiency in generating documentation based on Doxygen markdown. 
It's quite remarkable how confident I am now in configuring **Doxygen**.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ntovcfnpcrikijoevlhk.png)

# Implementation
Finally, we can proceed to the coding phase!
For the development of **FVA Software**, I have chosen the versatile [QT](https://en.wikipedia.org/wiki/Qt_(software)) library, which supports multiple operating systems such as **Windows**, **macOS**, and **Linux Ubuntu**. 
Since the software requires a user interface ([UI](https://en.wikipedia.org/wiki/User_interface)), I initially utilized **QWidgets**, including components like **QWizard** and **QWizardPage**.

However, I soon realized that employing **QML** would offer a more streamlined approach for [UI](https://en.wikipedia.org/wiki/User_interface) implementation.
Therefore, my plan is to transition from **QWidgets** to **QML**.

I was pleasantly surprised by the ease of utilizing **QT** for creating a multimedia content [player](https://github.com/dimanikulin/fva/blob/master/FVAPlayer). 
The flexibility of [QT](https://en.wikipedia.org/wiki/Qt_(software)) allows me to work with multiple [UI](https://en.wikipedia.org/wiki/User_interface) languages. 
To facilitate this, [QT](https://en.wikipedia.org/wiki/Qt_(software)) suggests using the following components:

- [QTranslator](https://doc.qt.io/qt-5/qtranslator.html);
- [QtextCodec](https://doc.qt.io/qt-5/qtextcodec.html);
- [Qlocale](https://doc.qt.io/qt-5/qlocale.html);
- [QtextDecoder](https://doc.qt.io/qt-5/qtextdecoder.html);
- [QtextEncoder](https://doc.qt.io/qt-5/qtextencoder.html).

Additionally, I discovered that working with **SQLite** using [QT](https://en.wikipedia.org/wiki/Qt_(software)) is remarkably straightforward. 

However, I later made the decision to switch from **SQLite** to [CSV](https://github.com/dimanikulin/fva/blob/master/FVACommonLib/fvacsvfile.h) for data storage.

As my project involves working with two programming [languages](https://github.com/dimanikulin/fva/blob/master/README.md#programming-languages), I needed to establish a means of integrating **Python** code into the **C++** application.

Last but not least, I acquired knowledge on how to create a [riff parser](https://github.com/dimanikulin/fva/blob/master/FVACommonLib/fvariffparser.h), adding another valuable capability to the project.

# History of internal metadata formats
The history of **internal metadata** formats in FVA Software reveals the evolution of how the software stored and managed metadata.
Initially, the metadata was kept at the file system level inside the Photo Album.
Each folder in the Photo Album had two files: **folderDescription.json** and **description.csv**.

The **folderDescription.json** file stored information that was common to all files within a folder, such as 
**device ID**, **tags**, **people**, **place**, and **event**.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8wha7ivdthv2hep0lzi5.png)

On the other hand, **description.csv** was used to store information about files under a folder that had different **internal metadata**.
It had columns for 

- Name
- Place
- People
- Device
- WhoTook
- Description
- Scaner

However, this approach of storing metadata at the file system level had limitations in terms of flexibility and maintainability. 
Adding or modifying a column in **folderDescription.json** or **description.csv** would require updating the entire photo album file system structure.

To address these limitations, the decision was made to move the **folderDescription.json** and **description.csv** files to an **SQLite** database. 
The database schema was designed to store the same information as before. 
During the import of new files to the photo album, the **FVA software** created **SQL** updates to the database. 
These **SQL** updates were saved to be able to recreate the **SQL** at any time.
Although this approach improved flexibility and maintainability compared to the file system approach, merging folders in the photo album still caused significant changes in the **SQL** updates.

Finally, it was decided to consolidate all the information into a single **CSV** file for **internal metadata**. 
This **CSV** file does not keep track of which folder a file is stored in, allowing for easier merging of folders without issues.
However, it results in some duplication of information since common information for all files in a folder is simply copied.

"*And what did you learn?*" you might ask.
The lesson learned is that before implementation, it is crucial to consider how easily you will maintain product changes. 

The history of internal metadata formats in FVA Software demonstrates the importance of designing a system architecture that is flexible and maintainable from the start.