développement logiciel - Offirmo-team/wiki GitHub Wiki

Voir aussi sécurité, open source, programmation fonctionelle, test unitaire, intégration continue, design patterns, concurrence, i18n, développement mobile, développement web, entretien...

Introduction

Motivation

Éthique

Ne pas être complice:

Société

Dé-platforming / censorship

Stories

Sûreté

Sécurité

Voir page dédiée Sécurité.

histoire

pop

apprendre et progresser

veille

https://www.thoughtworks.com/radar/techniques

démarrage

tosort

Techniques

Qualité

Some common lines of defense in software development include:

  • Requirements Gathering
  • Requirements Specification & Review
  • Risk Analysis
  • Test Driven Development (TDD)
  • Software Linting
  • Static Analysis
  • Software Inspection / Code Review
  • Model Simulation
  • Formal Methods
  • Acceptance Testing

expériences

process

débats

patterns

light

dark

  • ...

facts

tosort

Other

Concepts

Principes

Basics of the Unix Philosophy http://www.faqs.org/docs/artu/ch01s06.html

  1. Rule of Modularity: Write simple parts connected by clean interfaces.
  2. Rule of Clarity: Clarity is better than cleverness.
  3. Rule of Composition: Design programs to be connected to other programs.
  4. Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
  5. Rule of Simplicity: Design for simplicity; add complexity only where you must.
  6. Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.
  7. Rule of Transparency: Design for visibility to make inspection and debugging easier.
  8. Rule of Robustness: Robustness is the child of transparency and simplicity.
  9. Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.
  10. Rule of Least Surprise: In interface design, always do the least surprising thing.
  11. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
  12. Rule of Repair: When you must fail, fail noisily and as soon as possible.
  13. Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.
  14. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
  15. Rule of Optimization: Prototype before polishing. Get it working before you optimize it.
  16. Rule of Diversity: Distrust all claims for “one true way”.
  17. Rule of Extensibility: Design for the future, because it will be here sooner than you think.

SOLID (object-oriented design) http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)

  • S - SRP - Single responsibility principle
  • O - OCP - Open/closed principle
  • L - LSP - Liskov substitution principle
  • I - ISP - Interface segregation principle
  • D - DIP - Dependency inversion principle

Paradigmes

OOP

Langages

Évaluer un langage: http://www.pgbovine.net/what-is-a-programming-language.htm

  1. Specification
  2. Implementation
  3. Run-time environment
  4. Standard library
  5. Third-party libraries
  6. Community

Apprentissage

Techniques

Bonnes pratiques

Introduire les bonnes pratiques:

bonner pratiques de gestion de projet

https://github.com/microsoft/vscode/wiki/Development-Process

dev

code review

Nommage

Booleans:

  • No "onboarding" YES "isOnboarding" "hasOnboarding"

À éviter :

  • filterString -> filtre quoi ?
  • effets de bord
  • manager handler
  • double négations
  • switch -> "falltrough"
  • vocabulaire dédié: factory

code propre

Divers

"good taste"

https://medium.com/@bartobri/applying-the-linus-tarvolds-good-taste-coding-requirement-99749f37684a

semver

Exemple pragmatique : https://facebook.github.io/react/blog/2016/02/19/new-versioning-scheme.html

anti-pratiques

Open-source, community

Méthodologie

Modèle économique

Légal

scunthorpe problem

Culture

commitstrip

fun

background music

Divers

Règles de codage

à trier

Blogs

Divers :

Vu :

  • dans une fonction "save" : ifHasBeenUpdated then error. En fait, isHasBeenUpdatedBySomeoneElse

https://www.bountysource.com/

Techniques :

* no commented code or "useless now but maybe useful in the future" code. If it's WIP, then OK but it MUST have a reference to an issue


* https://hackernoon.com/50-data-structure-and-algorithms-interview-questions-for-programmers-b4b1ac61f5b0
* https://dev.to/jhotterbeekx/my-solution-is-the-best-1pjk
* https://dev.to/aviaryan/why-you-should-do-competitive-programming-even-if-a-little-1hf8
* https://scotch.io/bar-talk/5-tips-to-write-better-conditionals-in-javascript
* https://www.python.org/dev/peps/pep-0020/
* http://www.cs.yale.edu/homes/perlis-alan/quotes.html
* https://dev.to/conw_y/towards-zero-bugs-1bop
* https://dev.to/antjanus/my-top-10-programming-proverbs-2a4d
* https://dev.to/emmawedekind/101-tips-for-being-a-great-programmer-human-36nl
* https://dev.to/taillogs/the-best-book-to-read-as-a-developer-1h4m
* https://dev.to/jamesmh/how-to-become-a-senior-developer-3di3
* https://blog.sapegin.me/all/avoid-conditions/