Level 6 · In practice

6.3Best practices & pitfalls

Goal: adopt the right construction, data and delivery reflexes, and recognise the common pitfalls.

Estimated time: 10 min · If you only have 5 min: read “The essentials in 30s” + the diagram.

The essentials in 30 seconds

Prepare: a clean analysis and linked controls are worth more than accumulated patches.
Protect: transactions, permissions, backups and tests on a clean machine prevent data loss and risky deliveries.
Document: an incident log and tracked versions turn a solo project into a maintainable application.

Yacine's thread — the reflexes that held

After several years on the trading application, Yacine has kept a few simple reflexes: analyse before coding, link controls rather than tinkering, bound queries, wrap writes and test-run every delivery. The pitfalls, meanwhile, always come back the same way: haste and undocumented shortcuts.

Best practices are not rules for looking good: each one prevents a known outage or waste of time.

What makes the difference

Two applications can have the same screen and a very different fate. What separates them comes down to discreet choices: a clear analysis, linked controls, bounded queries, transactions and a serious test run. These choices don't show in the demo — they show six months later.

The classic pitfalls

Most avoidable incidents come from shortcuts: coding before analysing, filtering on the screen side instead of the database, forgetting permissions, delivering without a test on a clean machine or updating without a backup. Each seems to save an hour; each can cost a day.

Holding over time

A maintainable application is recognisable by its documentation and traceability: an incident log, tracked versions, backups and known deployment procedures. It is also what allows a new developer to take over the project without breaking everything.

✓ Do

Design the analysis (files, items, relationships, keys) before opening the first window.
Link the controls to the items and master HAjoute, HModifie and HEnDehors.
Filter and bound queries on the database side, and check indexing.
Wrap sensitive writes in transactions and define permissions by role.
Test-run every version on a clean machine and back up before any update.

✗ Avoid

Coding the windows first and improvising the data afterwards.
Sorting and filtering in WLangage over the whole file instead of the database.
Leaving permissions at screen level only, with no server-side check.
Sending the executable alone without dependencies or a test on a clean workstation.
Updating in production without a backup or any possible rollback.

Common misinterpretation: “Best practices slow you down.” No. They cost a few minutes today and save days of diagnosis tomorrow. The real cost is the production outage on a Friday evening, with no backup and no rollback.

Text version of the diagram (SEO / screen readers / translation): 1) Analyse before coding. 2) Link the controls and check the records. 3) Filter and bound on the database side, index. 4) Wrap writes and define permissions. 5) Test-run on a clean machine. 6) Back up before any update. Lesson: reliability comes from repeated reflexes, not from a one-off feat.

Ready-to-say script — defending a test run (30 s)

“Before delivering, I test-run on a clean machine: login, input, modification, deletion, permissions and printing. That's what avoids discovering a problem at the customer's site.”

Keep this to justify testing time to a hurried manager.

Ready-to-say script — explaining a backup (30 s)

“I always back up before an update, and I check that the restore works. Without that, a failed conversion can cost a month's data.”

Useful for framing an intervention in production.

Copy-paste template — delivery checklist

1. Analysis up to date + migration tested on a copy
2. Linked controls + saving path OK
3. Bounded queries + indexes checked
4. Role-based permissions tested with real profiles
5. Test run on a clean machine (installation included)
6. Backup done + rollback planned
7. Numbered version + delivery note

Copy-paste template — filtering rule

// Do: filter on the database side
SQLExec("SELECT * FROM Produits WHERE Famille = {pFamille}")
// Avoid: fetch everything then filter
HLitRecherche(Premier, Produits)
TANTQUE HEnDehors(Produits) = Faux
    SI Produits.Famille = pFamille ALORS ...
    HLitSuivant(Produits)
FIN

Very small business / small budget

Keep the essentials: clear analysis, linked controls, backup before update and a minimal test run on a clean workstation.

SME in Oran

Adapt to local realities: heterogeneous hardware, short user training and written procedures in simple French.

Remote / multi-site

Strengthen traceability: numbered versions, centralised logs and a documented remote update procedure.

Cross-cultural

Make implicit rules explicit (permissions, backups, test run) so they survive a change of team.

Caution: Generic reminder: an update or a deployment touches real data. Back up before any intervention, test the conversion on a representative copy and plan a rollback. Protecting customers' personal data is subject to legal obligations that vary by country: find out about the applicable law and seek advice — this guide is not legal advice.

48h challenge — apply it tomorrow

Take a real delivery and apply the checklist: analysis up to date, bounded queries, tested permissions, test run on a clean machine and prior backup.

Section exit checklist

I know the reflexes that make an application reliable and the pitfalls to avoid.
I have a reusable delivery checklist and filtering rule.
I have done the 48h challenge or scheduled its date.

Self-assessment 1-5: do I sacrifice the test run to save an hour?do I always back up before an update?

← Previous : Recurring issues (playbook) (V3)Next : Toolkit (V3) →

Check your understanding

Which reflex most reduces delivery incidents at the customer's site?

💡

Best practices are not rules for looking good: each one prevents a known outage or waste of time.