View source for Architectural decision records

The purpose of this page is to keep a record of large technical decision, to track their progress and rational.

== Template ==

The template for an architectural decision is as follows <ref>https://adr.github.io/</ref>:

<blockquote>
In the context of <use case/user story u>, facing <concern c> we decided for <option o> and neglected <other options>, to achieve <system qualities/desired consequences>, accepting <downside d/undesired consequences>, because <additional rationale>.
</blockquote>

<references />

== Decisions ==

todo, definition of done, https://www.ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html

Add new decisions at the top.

TODO: Add Psalm to entire application

TODO: SonarQube

{| class="wikitable"
! Date || Author || Topic || Decision
|-
| 2023-06-21
|style="white-space: nowrap;"|Olle Haerstedt || New question editor
|In the context of '''new question editor and styling'''<br>facing the problem of divering design between legacy admin and QE<br>we decided to remove Bootstrap<br>and neglected keeping and overriding Bootstrap<br>to achieve <pros><br>accepting <possible drawback><br>because <some reason> TODO
|-
| 2022-11-06
|style="white-space: nowrap;"|Olle Haerstedt || New question editor
|In the context of '''new question editor'''<br/>facing the problem to choose a new tech stack<br/>we decided for ReactJS + REST API<br/>and neglected Vue, Angular, RPC, SOAP<br/>to achieve a modern and common tech stack<br/>accepting that we will have to rewrite the side-menu Vue component eventually, and write a new REST module<br/>because side-menu is not that much code, and React is a more established framework (maybe?); and REST we need anyway to support more third-party integration
|-
| 2021-11-05
|style="white-space: nowrap;"|Olle Haerstedt || CI
|In the context of '''continuous integration''',<br/>facing lack of evidence-based code metrics,<br/>we decided to apply a maximum function size of 60 LOC for new code,<br/>accepting that some exceptions will likely occur over time,<br/>but overall the code quality will improve by such a restriction considering recommendations from NASA code guide and research.
|-
| 2021-06-16
|style="white-space: nowrap;"|Olle Haerstedt || Fat models
|In the context of '''fat models''',<br/>facing lack of testability,<br/>we decided to move code to dependency injected service classes<br/>to achieve higher testability with unit-tests,<br/>accepting that readability might be slightly reduced (circular coupling between new service classes and old models, at least temporarily),<br/>because preventing regressions is more important right now.
|-
| 2021-06-16 || Olle Haerstedt
|style="white-space: nowrap;"|New features
| In the context of new features,<br/>facing high degree of regressions,<br/>we decided to always add integrity tests to new features<br/>to prevent regressions and ensure adherence to specification,<br/>accepting that we might need to help external contributors with scaffolding and guidance, also accepting the extra development time,<br/>because testing is one of the best ways to prevent regressions long term and as the software changes and is touched by multiple developers.
|-
| 2020-01-01 || Team || Controller refactoring
| In the context of '''controller refactoring''',<br/>facing non-idiomatic Yii code (renderWrappedTemplate)<br/>we decided for refactoring of controllers and neglected other technical debt,<br/>to achieve idiomatic Yii code,<br/>accepting a long-term effort,<br/>because applying the Yii 1.1 framework correctly is important to lower the bar for new developers. 
|}