Skip to content

Development Takeaways

Sven Ligensa edited this page Aug 20, 2024 · 3 revisions

For our frontend team, the feature-branch workflow worked well, where a separate branch is created for every additional feature and bug fix, which is merged into the main branch when work on it is finished. A single commit should only cover a single change - which is easier said than done - which makes them more easily retraceable afterwards.

We also recommend first writing code that works and only afterwards refactoring it to be more performant and more readable. Because it does not make sense to polish code which is deleted later anyways. Nevertheless, this approach requires that one has already thought about the "big" things like the framework to be used, how to achieve integration between the parts (like frontend and backend, which is done by API), and how you want to do things on a large scale (which we defined via the UI mock). If you do not do that, you will spend a lot of time polishing and optimizing code which is deleted later anyways.

Large Language Models (LLMs) like ChatGPT and GitHub Copilot do a good job for simple to moderately complex coding and designing tasks. When working with larger files, it seems to be a promising idea to prompt the model to "only show changes", as otherwise a lot of text/code will be generated which is not needed, and it is more difficult to find what was adapted. When substituting whole code files with the versions generated by, e.g., ChatGPT, one should be careful, as sometimes comments are deleted in the response, which is usually not desired. In addition, LLMs are also a capable tool to understand code others have written. This is also the reason, why we describe the project in an overarching manner instead of what individual files or even lines of code do - we believe that the inline comments (especially when combined with the usage of LLMs) is sufficient to understand our code.

Clone this wiki locally