I warning

[sharkkk]

In ambito aziendale, nei progetti di un certo rilievo come vengono trattati i warning?

mi spiego, in un progetto i warning sono tollerati, sono la consuetudine, si cerca assolutamente di evitarli e di correggerli...insomma un progetto aziendale abbastanza serio i programmatori sono tenuti a eliminare ogni singolo warning oppure ci sono delle eccezioni?

[lorenzo001]

Non ci sono regole precise. Si considera il warning e ci si mette la "testa" ovvero si valuta se e perché può essere importante ...

Quindi dipende tutto dal tipo di warning.

Ad esempio, quelli che indicano che alcune funzioni sono soggette a "buffer overflow" e che sarebbe meglio non utilizzarle sono da prendersi in seria considerazione.

[sharkkk]

Non ci sono regole precise. Si considera il warning e ci si mette la "testa" ovvero si valuta se e perché può essere importante ...

Quindi dipende tutto dal tipo di warning.

Ad esempio, quelli che indicano che alcune funzioni sono soggette a "buffer overflow" e che sarebbe meglio non utilizzarle sono da prendersi in seria considerazione.

immaginavo fosse cosi ma volevo avere una conferma visto che non ho mai lavorato in ambito aziendale.

una curiosità, rimanendo sempre in tema, come avviene la consegna e lo sviluppo di un frammento di codice da parte del programmatore?

cioè arriva l'analista che ti introduce al problema, ti viene consegnato uno schema, ti viene data una deadline intramontabile pena licenziamento, trattare sulla deadline, insomma se ti va (e anche agli altr) mi daresti la tua esperienza in questi casi?:)

[lorenzo001]

Anche per questo non ci sono regole precise.

Il consiglio è di non informarti su questi aspetti da altri che hanno mille modi di operare (ogni società ha modi anche sostanzialmente diversi di operare) finché non sei al lavoro. Sul campo imparerai il modo di operare della società in cui operi che potrebbe essere molto diverso da quello di un'altra.

(Ad esempio, spesso non esiste affatto un analista e dovrai fare da solo ...)

[sharkkk]

Anche per questo non ci sono regole precise.

Il consiglio è di non informarti su questi aspetti da altri che hanno mille modi di operare (ogni società ha modi anche sostanzialmente diversi di operare) finché non sei al lavoro. Sul campo imparerai il modo di operare della società in cui operi che potrebbe essere molto diverso da quello di un'altra.

(Ad esempio, spesso non esiste affatto un analista e dovrai fare da solo ...)

Certo lorenzo, ma immagino che ci sia almeno una linea di default in cui per lo meno si sappiano quali siano pressapoco i propri "diritti", nel senso che almeno di fondo posso sapere se le cose che mi stanno chiedendo di fare sono o meno congrue rispetto al mio compenso.

Immaginati io che senza nessuna esperienza lavorativa arrivo in un'azienda che mi dice di fare questo in tot tempo senza se e senza ma, che non posso apportare modifiche, ecc ecc..cioè c'e almeno alla base una cosa su cui un programmatore medio deve/può trattare con i propri capi?

o è anarchia/sfruttamento? :D

[lorenzo001]

Le ultime che hai detto ...

[sharkkk]

Le ultime che hai detto ...

ahah :D

presumo quindi che ci voglia una bella dose di carattere per non farsi mettere troppo i piedi in testa dai capi e dai colleghi. in un ambiente cosi anarchico se si mostra di essere troppo buoni penso che si venga solo sovraccaricati di lavoro..e credo a questo punto convenga anche non dimostrare di essere troppo veloce per evitare che poi quella velocità diventi un requisito

[mone.java]

(Ad esempio, spesso non esiste affatto un analista e dovrai fare da solo ...)

troppo spesso :(

[lorenzo001]

Ovviamente non è sempre come ti ho detto, ci sono sempre delle eccezioni in cui il lavoro è ben organizzato e i ruoli ben definiti, ma non ne ho mai incontrato durante le mie esperienze lavorative.

Se lavori nel pubblico (o per il pubblico) puoi permetterti un po' più di "tranquillità"; per il privato devi sempre lottare ...

[lorenzo.c]

troppo spesso :(

Gia', soprattutto nelle piccole realta', dove sei praticamente abbandonato a te stesso e alla deadline... :rolleyes:

[wingman87]

Nella mia esperienza il programmatore deve giocare il proprio ruolo, non deve né farsi mettere i piedi in testa né imporsi sugli altri.. Spesso chi sta "sopra" non sa nulla o poco di programmazione e comunque, se non sei alle prime armi, ne sa meno di te. Quindi, se sei nella posizione di farlo, devi fare la tua parte anche nei processi decisionali consigliando certe soluzioni piuttosto che altre e sbarrare la strada o trattare per avere più tempo quando si prospettano impegni impossibili da portare a termine in tempo.

[Daniels118]

Quanto ai warning, la mia opinione strettamente personale è che i warning debbano essere generati solo a fronte di una errata configurazione comunque gestibile dal programma. Tutto ciò che non è gestibile o imprevisto deve generare un errore (che non significa necessariamente una terminazione brutale dell'applicazione).

Quanto al ruolo del programmatore, voglio sperare che nessuna azienda, nemmeno la più piccola, metta una persona inesperta a fare l'analista. L'analista può anche non saper scrivere una riga di codice, ma a fronte di un problema dovrebbe sapere più o meno quanto tempo ci mette il programmatore a realizzarlo.
E' abbastanza comune che si chieda più del possibile per avere il normale, ma questa non deve essere una tua preoccupazione, mettici il tempo che serve.

[mone.java]

magari... :sofico:

Confermo in quanto ho sempre lavorato per piccole realtà mi sono spesso trovato a fare il tutto fare... pagando le conseguenze di cattive analisi/analisi inesistenti solo più tardi... :D

[Daniels118]

Confermo in quanto ho sempre lavorato per piccole realtà mi sono spesso trovato a fare il tutto fare... pagando le conseguenze di cattive analisi/analisi inesistenti solo più tardi... :D
Scusa, ma se ti hanno dato il ruolo di tuttofare vuol dire che tu ti sei proposto come persona capace di fare tutto, se avessi detto "per me è troppo" di certo non ti avrebbero affidato quegli incarichi. Se uno se li va a cercare i guai... poi per carità, ci sono pure le situazioni in cui bisogna stringere i denti.

Comunque è bello sentire anche esperienze diverse, io da questo punto di vista posso ritenermi fortunato.

[mone.java]

Scusa, ma se ti hanno dato il ruolo di tuttofare vuol dire che tu ti sei proposto come persona capace di fare tutto, se avessi detto "per me è troppo" di certo non ti avrebbero affidato quegli incarichi. Se uno se li va a cercare i guai... poi per carità, ci sono pure le situazioni in cui bisogna stringere i denti.

Comunque è bello sentire anche esperienze diverse, io da questo punto di vista posso ritenermi fortunato.

Mi è capiato di buttarmi in avventure insieme a gente che ne sapeva meno di me... Della serie c'era il lavoro... nessuno era skillato per farlo e ci siamo "inventati"... Nel mio caso specisi trattava di fare un gestionale web e mi sono buttato su Java EE avendo sempre e solo usato Java SE... Gli altri membri del team improvvisato erano: Uno molto esperto di database ma 0 con java e l'altro molto esperto di PHP e programmazione web ma poco di java... E non è l'unica volta che mi è capitata una cosa del genere, diciamo che mi sono lanciato spesso in avventure... Ho lavorato come uno schiavo ma ho imparato un sacco di cose da errori che altrimenti non avrei commesso.

Infatti non mi sono in quel post ho detto che ho pagato le conseguenze ma non me ne sono lamentato... :D

[airon]

...

Quanto al ruolo del programmatore, voglio sperare che nessuna azienda, nemmeno la più piccola, metta una persona inesperta a fare l'analista. L'analista può anche non saper scrivere una riga di codice, ma a fronte di un problema dovrebbe sapere più o meno quanto tempo ci mette il programmatore a realizzarlo.
E' abbastanza comune che si chieda più del possibile per avere il normale, ma questa non deve essere una tua preoccupazione, mettici il tempo che serve.

Ma come può un analista fare analisi se non sa cosa c'é da fare lato codice? L'esperienza conta fino ad un certo punto.

Tornando in topic, in base alla mia esperienza, anche io dico che dipende dal progetto. Alle volte conviene risolvere anche i warning altre volte no. In ogni caso, un codice ben commentato o specifiche di progetto aiutano sempre.

[Daniels118]

Ma come può un analista fare analisi se non sa cosa c'é da fare lato codice? L'esperienza conta fino ad un certo punto.

Tornando in topic, in base alla mia esperienza, anche io dico che dipende dal progetto. Alle volte conviene risolvere anche i warning altre volte no. In ogni caso, un codice ben commentato o specifiche di progetto aiutano sempre.
Grazie ad una cosa nota come esperienza :)
Detesto doverlo ammettere, ma di solito chi programma in ambito lavorativo non inventa nulla, non si fa altro che applicare un milione di volte gli stessi algoritmi in contesti diversi.

Tornando ai warning, se ci si riferiva a quelli in fase di compilazione, per me è d'obbligo risolverli sempre. In java ci sono delle istruzioni per il compilatore molto utili note come annotazioni, una di queste si chiama SuppressWarnings: se una particolare istruzione genera un warning, ma si è consapevoli che quella istruzione va scritta in quel preciso modo, un'annotazione può sopprimere selettivamente i warning generati per il metodo dove si trova l'istruzione. In questo modo si da maggiore visibilità ad eventuali warnings indesiderati, evitando di ignorare situazioni sfuggite al controllo.