<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2014-12-29 21:39 GMT+01:00 enrico franchi <span dir="ltr"><<a href="mailto:enrico.franchi@gmail.com" target="_blank">enrico.franchi@gmail.com</a>></span>:<br><br></div><div class="gmail_quote">Avevo cannato questa tua, pardonez moi<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""></span><div>Visto quello che escludi piu' sotto dalla definizione di codice mantenibile, credo che abbiamo definizioni diverse di mantenibile. Per esempio, per me, codice mantenibile senza test e' un ossimoro. Tanto per dirne una.</div></blockquote><div><br></div><div>I test, come farli fare alla persona, sono un passaggio evolutivo, la famosa esperienza. Io ho parlato di mettere in condizione di scrivere applicazioni con una supervisione.<br></div><div> <span class=""></span><div>E io su questo sono completamente in disaccordo. </div><span class=""><div dir="ltr"> </div></span>1. python di base (funzioni, cicli, if, compagnia)<div>2. oggetti e programmazione ad oggetti (sembra difficile ragionare con Django senza ragionare con gli oggetti)</div><div>2b. come organizzare le dipendenze in modo sensato, moduli e oggetti, interfacce fra gli stessi (non in senso Java, in senso di come si parlano)<br></div><div>3. Django</div><div>4. HTTP (voglio dire, dovra' ben sapere quando una chiamata ti torna un 200, un 404, un 401, un 403, gli altri 4xx e i 3xx)</div><div>Fino qui si<br><br>5. HTML/Templating, verosimilmente con CSS e quel minimo di Javascript che tende a saltare fuori ovunque<br><br></div><div>No, perdonami, ma io separo frontend e backend. La parte "browser" la fa una figura diversa e per essere formata richiede altri tempi (javascript senza contare poi css e compagnia, e' motlo piu' complesso.). Io parlavo di Python e Django.<br></div><div><br></div><div>5b. Forms e compagnia<br><br></div><div>Anche qui non e' strettamente necessario. Io le forms non le ho mai usate in progetti fino ad ora. Sono belle, sono comode, ma non indispensabili.<br></div><div><br></div><div>6. Come si gestiscono e come non si gestiscono gli errori, quando usare None, quando tirare un'eccezione, quando fare altro. Come gestire le eccezioni, quando rilanciarle, quando gestirle, quando fare cosa<br><br></div><div>Le eccezioni si, fanno parte del linguaggio<br><br></div><div>7. Testing (che non vorremo mica sviluppare senza test, spero)<br><br></div><div>Si i test li prepara e esegue una persona diversa, Con il tempo e l'esperienza imparera'. Ma per scrivere dei buoni test devi prima conoscere bene il linguaggio ed il framework<br><br></div><div>8. Grosso modo come funziona uno stack web<br><br></div><div>Che e' abbastanza nromale<br><br></div><div>9. Quel poco di SQL (o meglio, di db relazionali) che ti serve per capire come accidenti Django salva e legge dati, fra le altre varie cose per non inchiodare tutto appena la gente comincia ad usare il servizio<br><br></div><div>Per questa fase gli basta di sare eseguire le query con gli statement dell'ORM. Le raw query servono solo in casi particolari che esulano, per la fase iniziale.<br><br></div><div>10. Quel poco di dbms che ti serve</div><div><br>Ok, normale<br><br>11. Come funzionano le fixtures e come si scrivono i test che interagiscono con il db<br><br>No perche' qui pure siamo nel "e' compito di altra persona", in questa fase-<br><br>12. cosa loggare e cosa non loggare, quando, come leggere e capire un log</div></div></div><br></div><div class="gmail_extra">Beh fa parte della programmazione, senza log non fai debug<br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra">Carlos<br></div><div class="gmail_extra">-- <br><div class="gmail_signature"><div dir="ltr">EZLN ... Para Todos Todo ...</div></div>
</div></div>