How Aricie Reviews DNN Code Without Slowing Delivery

Aricie builds and supports DotNetNuke solutions, custom business software and training from its offices in Mureils, Paris, Lyon and Grenoble. For Australian teams working with an offshore development partner, a DNN code review must do more than catch syntax errors: it must preserve business intent across time zones, make technical decisions visible and leave a usable record for teams that inherit the product.

DotNetNuke, usually called DNN Platform, combines framework conventions with extension modules, permissions and database access. This is how we conduct DNN code reviews: standards focus on system behaviour and maintainability, while common pitfalls—oversized changes, hidden security gaps and weak release evidence—shape the process.

Agree the Review Boundary

A review starts with the acceptance criteria, not the diff. The reviewer checks the ticket, affected DNN modules, data changes, dependencies and expected user journey. On applications such as Acoléa, Adylic, AricieGrid or Budg-Immos, domain rules matter as much as framework usage: an otherwise clean implementation can still be wrong for a budget, property or advertising workflow.

The pull request is then kept small enough to reason about. Large redesigns are split into staged changes where practical, while generated files and formatting noise are excluded from human attention. A useful standard is that every blocking comment identifies a behavioural risk, security exposure or maintenance cost, with evidence and a suggested path forward. Style preferences that tooling can settle do not delay approval.

Treat Security as Product Behaviour

DNN reviews explicitly inspect authentication, module-level authorisation, tenant isolation, input validation, output encoding, SQL construction, file uploads, secrets and third-party packages. We also check that extension registration, scheduled tasks and event handlers fail safely. The aim is not to endorse automatic security scans; scanners find signals, while reviewers judge exploitability and business impact.

For Australian-facing work, that judgement includes local obligations and buying conditions. Personal information may engage the Privacy Act 1988 and the Australian Privacy Principles; email or SMS campaigns may trigger the Spam Act 2003; and public-sector or regulated contracts can require alignment with the ACSC Essential Eight. Legal advice remains the client’s responsibility, but reviewers flag data flows and control gaps that those requirements make material.

Examine Correctness Under Real Conditions

Functional tests demonstrate intended behaviour, but reviewers also examine boundary values, null paths, concurrency, retries and upgrade behaviour. Database queries need indexing and parameterisation checks, while caches, imports and DNN container operations are assessed for memory use and timeout risk. Compatibility with supported DNN versions and .NET targets is verified against the release matrix.

Review area	Review standard	Common pitfall
Security	Permission tests, threat notes and protected secrets	Trusting the interface to enforce access
Correctness	Tests for successful and failed paths	Checking only successful paths
Data	Reviewed migrations and rollback steps	Changing live schema from feature code
Performance	Query plans, limits and telemetry	Running unbounded tenant queries
Maintainability	Clear boundaries and justified APIs	Bypassing DNN APIs without analysis
Release	Version, configuration and rollback notes	Introducing silent breaking changes

The severity label follows consequence and likelihood. A cross-tenant permission defect is critical, while a confusing naming choice is low severity unless it obscures a real defect. Reviewers distinguish a verified issue from a question and reproduce uncertain findings before requesting changes. This keeps comments precise and reduces the common pitfall of turning a code review into a contest of preferences.

Business experts join where needed. A property workflow, for example, needs validation by someone who understands leases, deposits and maintenance deadlines, while the technical reviewer confirms the implementation. That combination catches domain errors that static analysis cannot see and prevents a plausible test suite from certifying the wrong process.

Make Comments Work Across Locations

Australian development teams may be distributed across Sydney, Melbourne, Brisbane, Perth and regional centres, with reviewers joining around office hours or hybrid schedules. Aricie’s French teams are often eight to ten hours ahead of eastern Australia depending on daylight-saving periods, so decisions should not depend on a live meeting. A written comment should explain the risk, expected behaviour and urgency clearly enough for an absent teammate to act.

Feedback separates blocking defects from suggestions and questions, and the author resolves each thread before approval. CI runs formatting, compilation, unit and integration checks before a human opens the diff; reviewers then add context-sensitive judgement. This balance avoids both extremes: a slow queue of tool-like comments and an automated green tick treated as proof that a DNN release is safe.

Leave a Clear Delivery Record

At approval, the record contains linked acceptance criteria, test evidence, migration notes, configuration changes and any accepted residual risk. Reviews of upgrade paths and third-party licences can prevent surprises during deployment. If a finding is deferred, it needs an owner and target date rather than disappearing into chat. This is especially important when Australian clients, French developers and future maintainers share ownership.

The standard is consistent without being rigid. High-risk changes receive deeper review; low-risk corrections can move quickly. Over time, recurring defects become team guidance, tests or automated checks, so the process improves rather than repeating the same debate. Pitfalls are handled explicitly, including oversized pull requests, unreviewed generated code, vague exceptions and reviews based only on the author’s verbal explanation.

---

Teams ready to strengthen their DNN quality process can contact Aricie to discuss review standards or explore professional training for development teams.