Architectural decision records: Difference between revisions
From LimeSurvey Manual
(Created page with "== 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 <co...") |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
The purpose of this page is to keep a record of large technical decision, to track their progress and rational. | |||
== Template == | == Template == | ||
| Line 17: | Line 19: | ||
{| | {| | ||
! Date || Author || Topic || Decision | ! Date || Author || Topic || Decision | ||
|- | |||
| 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 | | 2021-06-16 | ||
|style="white-space: nowrap;"|Olle Haerstedt | |style="white-space: nowrap;"|Olle Haerstedt || Fat models | ||
|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. | ||
| In the context of ''fat models'', facing lack of testability, we decided to move code to dependency injected service classes to achieve higher testability with unit-tests, accepting that readability might be slightly reduced (circular coupling between new service classes and old models, at least temporarily), because preventing regressions is more important right now. | |||
|- | |- | ||
| 2021-06-16 || Olle Haerstedt | | 2021-06-16 || Olle Haerstedt | ||
|style="white-space: nowrap;"|New features | |style="white-space: nowrap;"|New features | ||
| In the context of new features, facing high degree of regressions, we decided to always add integrity tests to new features to prevent regressions and ensure adherence to specification, accepting that we might need to help external contributors with scaffolding and guidance, also accepting the extra development time, because testing is one of the best ways to prevent regressions long term and as the software changes and is touched by multiple developers. | | 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. | |||
|} | |} | ||
Revision as of 17:37, 5 November 2021
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 [1]:
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>.
Decisions
todo, definition of done, https://www.ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html
Add new decisions at the top.
| Date | Author | Topic | Decision |
|---|---|---|---|
| 2021-11-05 | Olle Haerstedt | CI | In the context of continuous integration, facing lack of evidence-based code metrics, we decided to apply a maximum function size of 60 LOC for new code, accepting that some exceptions will likely occur over time, but overall the code quality will improve by such a restriction considering recommendations from NASA code guide and research. |
| 2021-06-16 | Olle Haerstedt | Fat models | In the context of fat models, facing lack of testability, we decided to move code to dependency injected service classes to achieve higher testability with unit-tests, accepting that readability might be slightly reduced (circular coupling between new service classes and old models, at least temporarily), because preventing regressions is more important right now. |
| 2021-06-16 | Olle Haerstedt | New features | In the context of new features, facing high degree of regressions, we decided to always add integrity tests to new features to prevent regressions and ensure adherence to specification, accepting that we might need to help external contributors with scaffolding and guidance, also accepting the extra development time, 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, facing non-idiomatic Yii code (renderWrappedTemplate) we decided for refactoring of controllers and neglected other technical debt, to achieve idiomatic Yii code, accepting a long-term effort, because applying the Yii 1.1 framework correctly is important to lower the bar for new developers. |