Parliamo dei progetti comuni nell'editore - perché e dove stanno andando - pagina 6

 
Alexey Volchanskiy:

Oggi ho formato qualcuno in MQL5 e lui ha creato un progetto da zero senza il mio aiuto. È davvero molto semplice, di cosa si preoccupa la gente... Non devono aver mai avuto a che fare con progetti prima d'ora.

Ho avuto alcuni bug con il magazzino fino a quando non ha iniziato a funzionare correttamente e non ho mai capito dove fossero i miei errori.

Ora, diciamo che sto cercando di capire se dividere tutta la mia libreria in progetti separati, o fare tutto in uno. Se lo divido in separati - allora, in teoria, l'accesso alle singole sezioni della libreria è semplificato, ma allo stesso tempo alcuni file rientrano in più progetti contemporaneamente - posso farlo?

 
Ilnur Khasanov:
Non posso davvero relazionarmi con l'editor, ora che ci sono progetti di squadra, ci sarà un task tracker? Cosa sarà in termini di organizzazione del team, impostazione dei compiti, revisione del codice?
No, non abbiamo intenzione di farlo.
 
George Merts:

No, sto solo "soffiando sull'acqua" - ho sempre avuto qualche problema con il magazzino, finché non ha iniziato a funzionare correttamente, e non ho mai capito quali fossero i miei errori.

Ora, diciamo che sto cercando di capire se dividere tutta la mia libreria in progetti separati, o fare tutto in uno. Se lo divido in separati - allora, in teoria, l'accesso alle singole sezioni della libreria è ordinato, ma finisce per avere alcuni file in più progetti contemporaneamente - posso farlo ?

Se lo stai facendo solo per te stesso, la libreria dovrebbe essere spostata in un progetto separato all'interno della directory MQL5 e lavorare.

Se volete progetti comuni, fate un progetto di libreria separato e progetti di lavoro separati. Dai progetti di lavoro, fate riferimento al progetto della libreria vicina tramite percorsi relativi.

 
Renat Fatkhullin:

Potresti creare un thread simile su Tester?

 
Quali sono i vantaggi del servizio del singolo sviluppatore in discussione rispetto ai classici?
 
Alexey Volchanskiy:

)))))))))))))) era una battuta di umorismo? Facciamo un bugzilla nel meta-editor).

Beh, non bugzilla - ci sono molte soluzioni. Lo stesso visual studio ha degli strumenti, tfs è specificamente integrato nell'editor.
Immaginate di essere il comandante del progetto, avete diversi partecipanti che vi inviano codice sul progetto. Come guardereste il loro codice, fareste dei commenti, ecc. Come fisserete i compiti specifici per ogni membro del team? Come farete a tenere traccia di chi ha aggiunto cosa e quando?
Questo non è davvero un problema - ci sono molti servizi esterni.
 
fxsaber:
Quali sono i vantaggi del servizio del singolo sviluppatore in discussione rispetto ai classici?

double advantage = 0.00; // for face-to-face progger ))))
 
fxsaber:
Quali sono i vantaggi del servizio discusso per lo sviluppatore individuale rispetto ai classici?

1) Creerà programmi complessi e li gestirà convenientemente. Niente più problemi con un solo file.

2) Impareranno ad usare i sistemi di controllo delle versioni. La maggior parte di loro non li ha mai usati prima.

3) Impareranno a lavorare su progetti comuni.

4) Sarà più facile preparare e pubblicare i prodotti in un appstore e il codice per un kodobase.

5) Sarà più facile lavorare come freelance, quando il cliente può non solo monitorare il progresso, ma anche partecipare al processo di sviluppo

6) I progetti pubblici sono un altro posto per mostrare le proprie capacità come autore e collaboratore/contribuente ad altri progetti

7) Aumentare le loro capacità di programmazione: +1 sul controllo delle versioni, +1 sul lavoro di gruppo


Questo è ciò che si trova in superficie.

 
Ilnur Khasanov:
Beh, non bugzilla - ci sono molte soluzioni. Lo stesso visual studio ha degli strumenti, tfs è specificamente integrato nell'editor.
Immaginate di essere il comandante del progetto e di ricevere del codice da diversi collaboratori di un progetto. Come guardereste il loro codice, fareste dei commenti, ecc. Come fisserete i compiti specifici per ogni membro del team? Come farete a tenere traccia di chi ha aggiunto cosa e quando?
Questo non è davvero un problema - ci sono molti servizi esterni.

Sto scherzando.

MQ non sprecherà risorse per stronzate che servono allo 0,1% degli utenti

 
Renat Fatkhullin:

1) Sarà in grado di creare programmi complessi e gestirli comodamente. Niente più problemi con un solo file.

2) Impareranno a usare i sistemi di controllo delle versioni. La maggior parte delle persone non li ha mai usati.

3) Impareranno a lavorare su progetti comuni.

4) Sarà più facile preparare e pubblicare prodotti nell'appstore e codici per codobase

5) Sarà più facile lavorare come freelance, quando il cliente non solo può seguire i progressi, ma anche partecipare allo sviluppo

6) I progetti pubblici sono un posto in più per dimostrare le tue abilità come autore e collaboratore/contribuente ad altri progetti

7) Migliorare le loro capacità di programmazione: +1 sul controllo di versione, +1 lavoro di gruppo


Questo è ciò che si trova in superficie.


4-6 Puoi approfondire? Sarò in grado di gettare la KB senza l'attuale burocrazia?