Programació
Tècniques per a la solució de problemes
1. Definir el problema: el punt de partida i l’objectiu
• si el problema te l’ha donat un altre, explica’l amb les teves paraules
• representa el problema amb dibuixos i diagrames
• identifica les coses que no saps
2. Idear un pla
• descomposició: trencar un problema en parts més senzilles (estructura d’arbre)
• generalització: abstracció, identificar patrons i reduir el nombre de conceptes
• Patrons senzills: noms: objectes; verbs: operacions; adjectius: propietats; números: variables
• Patrons de control: bucles, subrutines, regles
• altres tècniques:
• pensament crític: posa en dubte les teves decisions... i si falla?
• resoldre un problema concret
• troba un problema relacionat
• cercar cap enrere des de l’objectiu… com puc arribar?
• dissenyar un model (simplificació, representació, dades, interacció)
3. Executar el pla
4. Revisar i estendre (iteració)
Bones pràctiques per escriure codi
Estàs escrivint codi per llegir-lo en el futur, o bé per un altre...
- Les classes han de ser petites, per sota de 500 línies, i han de tenir un nombre limitat de mètodes
- Els mètodes han de ser petits, per sota de 30 línies, i han de fer una feina concreta
- Has d’escriure el codi perquè s’expliqui a ell mateix, però on no arribis, utilitza comentaris
- No facis línies massa llargues, com a molt de 120 caràcters
- Indenta el codi per cada nivell d’anidament, i intenta no superar els 3-4 nivells
- Si hi ha dades d’entrada, crea-les des del codi per no haver d’introduir-les des del teclat
- Anomena les classes, els mètodes i les variables amb els criteris ja explicats
- Decideix el teu estil i segueix-lo de forma consistent
És dolent el teu codi?
- És massa rígid? Es poden canviar els detalls interns d'aquest mòdul en el futur sense tocar el codi d'altres mòduls i altres capes? El codi rígid és el que té dependències que serpentegen en tantes direccions que no es pot fer un canvi aïllat sense canviar-ho tot al voltant.
- És massa fràgil? Seria difícil trobar llocs on fer canvis i refactoritzar en el futur? El codi fràgil es trenca de formes estranyes i que no es poden predir.
- Hauria de ser una característica reutilitzable? Si ho fos, el codi depèn de mòduls no desitjats que es podrien evitar? Vols una banana, però el que obtens és un goril·la agafant-la i tota la jungla amb ell.
Si mirem de prop, el fil conductor dels tres problemes esmentats és l'acoblament. Els mòduls depenen els uns dels altres de maneres no desitjades i resulten en un codi espagueti.
El codi hauria d'estar desacoblat entre els mòduls i les capes. Les polítiques d'alt nivell i les abstraccions no haurien de dependre de detalls de baix nivell, sinó d'abstraccions: caldria invertir la dependència dels mòduls als llocs necessaris. I escriure classes que només fan una cosa i només tenen un motiu per canviar.
El codi bo hauria d'explicar què està fent. Hauria de ser avorrit de llegir. Tot hauria de ser perfectament obvi. Això és bon codi - Robert Martin.
Els principis de la bona programació
- DRY (Don't repeat yourself): no et repeteixis.
- Principi de l'abstracció: cada peça significant s'ha d'implementar en només un lloc del codi font.
- KISS (Keep it simple): mantenir la senzillesa.
- Evita crear YAGNI (no ho necessitaràs).
- Fes la feina més senzilla que sigui funcional.
- No em facis pensar.
- El principi Obert/Tancat: les entitats software han d'estar obertes a ser esteses i tancades a ser modificades.
- Escriu el codi per qui l'haurà de mantenir.
- El principi de la mínima sorpresa.
- El principi de la responsabilitat única (SRP): un component de codi ha de fer una sola i ben definida feina.
- Minimitzar l'acoblament i maximitzar la cohesió.
- Amagar els detalls de la implementació.
- La llei de Demeter: el codi només s'ha de comunicar amb les seves relacions directes.
- Evitar la optimització prematura: només si funciona i es lent.
- Reutilitzar codi és bo: el fa més llegible.
- Separació d'interessos: àrees de diferents funcionalitats han de tenir pocs solapaments.