Processo di pensiero generale per domande sull'intervista "Come costruiresti questo sito Web / app" [chiuso]

Ho raccolto un sacco di domande di intervista come "Descrivi come progetteresti un'applicazione per un album fotografico", "Descrivi come progetteresti questa particolare caratteristica di questo particolare sito Web" (ad es. Mi piace su Facebook, raccomandazione su Amazon, carrello della spesa, gioco di black jack). Quindi, se ci fossero milioni di questa cosa? Cosa cambieresti?

Sembra che questo si aspetti uno schema di database o un mucchio di definizioni di classe (o entrambi?). Ho imparato a conoscere i database a scuola, ma in realtà non ho mai progettato un'applicazione e non ho mai saputo da dove cominciare, se i progetti che ho creato sono "buoni" e cosa posso cambiare per renderlo scalabile.

Esiste un approccio generale o un processo di pensiero durante la progettazione di questi sistemi? E problemi / problemi generali che sembrano emergere molto nella progettazione che dovrei cercare di evitare? Qualcuno potrebbe forse guidarmi attraverso uno (o preferibilmente tutti, confrontando le esigenze di ciascuno) di questi e spiegare:

1) Come si ottengono le entità necessarie? 2) Come decidi su quali relazioni avrà tutto? 3) Come si incorpora l'ottimizzazione delle prestazioni nel proprio progetto? 4) Faccio questo usando classi o database? Fa la differenza (ad esempio, avrei una classe che non può davvero essere tradotta in una tabella di database, per esempio?)

Il motivo principale che sto chiedendo è perché stavo attraversando "Cracking the Coding Interview" e le mie risposte erano completamente diverse da quelle dell'autore - avevo idee molto diverse su quali classi fossero importanti.

IL MIO TENTATIVO: con l'app di condivisione delle foto, avrei sicuramente le classi / tabelle: foto e utente.

Quindi, penso che se stiamo cercando di creare uno schema, ci sarebbe una tabella che collega foto e utente se assumiamo che ogni persona nella foto sia collegata alla foto (questa tabella è necessaria? In caso contrario, è ancora pratica comune avere una tabella separata per relazioni molti-a-molti o no?).

Ma se stiamo cercando di adottare un approccio orientato agli oggetti, forse invece avremmo una classe chiamata album che fa tutto il lavoro e ha tutte le informazioni dalle altre due tabelle / classi. Questa è una cosa che ho notato nel libro - ci sono un sacco di classi e poi una classe che praticamente ha tutte le informazioni e collega le altre classi - è comune? Ad esempio, nei miei esempi precedenti, sembra che si applicherebbe?

Spero solo che seguano alcune regole / linee guida generali perché in questo momento non ho idea di come sia una buona architettura per un sistema di grandi dimensioni.

Il punto di tali domande è valutare se si dispone delle competenze del mondo reale nella scrittura di un'applicazione software. Hai imparato un po 'di teoria, ma le conoscenze teoriche possono andare solo così lontano. L'unico modo per comprendere veramente lo sviluppo del software è farlo.

Non ci sono scorciatoie per questo, perché non ci sono risposte stock a domande come "quali entità sono necessarie?" Invece, devi applicare la tua esperienza di vari strumenti e paradigmi, e come funzionano insieme, per trovare una soluzione pratica al problema in questione.

Una domanda del tipo "Faccio questo usando classi o database?" suggerisce che ti manca una conoscenza di base di cosa sono e come funzionano le cose. Le classi sono un paradigma per l'organizzazione del codice; i database sono un metodo di archiviazione dei dati. Sono due concetti intrinsecamente non correlati (sebbene possano lavorare insieme). Questa non è una o / o domanda.

Non intendo essere duro, ma penso che sia necessario sviluppare la tua esperienza di programmazione per avere successo in un simile colloquio di lavoro. Hai certamente il potenziale: la tua discussione sull'app di condivisione di foto ha alcune delle idee giuste ed è diretta nella giusta direzione. Ma devi imparare come funziona in prima persona. Il modo migliore per prepararsi al colloquio è in realtà creare un'applicazione dall'inizio alla fine. Un'app di condivisione di foto sarebbe un progetto di dimensioni adeguate, oppure potresti scegliere qualcos'altro. La tua conoscenza si espanderà davvero quando vedrai come tutte le parti possono lavorare insieme per creare un'applicazione funzionante.

Sembra che questo si aspetti uno schema di database o un mucchio di definizioni di classe (o entrambi?)

Penso che tu sia troppo concentrato sui dettagli qui. Con questa domanda, il reclutatore non si aspetta una descrizione completa di tutte le classi che scriveresti (altrimenti ti chiederebbero di codificarlo, non di parlarne).

La tua risposta deve prima riguardare il quadro generale: architettura, livelli, livelli, persino il ciclo di vita del progetto e il processo di sviluppo che metteresti in atto. Non esitate a fare domande sui requisiti e sull'ambiente in cui l'applicazione dovrebbe essere eseguita per adattare la vostra risposta. Come ha sottolineato dan1111, non esiste una ricetta generale per una corretta progettazione dell'applicazione. Tutti i disegni dipendono dal contesto.

Solo se il recruiter inizia a porre domande davvero specifiche, dovresti entrare nei dettagli su quali classi, entità o tabelle di database utilizzeresti sotto il cofano.

Inoltre, se hai poca esperienza, è normale dire "Ti mostrerò una soluzione usando il tipo di design dell'applicazione che mi è stato insegnato e usato fino ad ora. Conosco questo e gli altri approcci che posso descriverti nel complesso, ma non li ho mai applicati. Sono anche aperto a scoprire e applicare gli altri ".

Non c'è niente di sbagliato nel riconoscere che ci sono solo così tanti strumenti nella tua cassetta degli attrezzi che la tua esperienza ti consente di avere - in effetti, è meglio che sputare una risposta provata che non hai idea di come funzioni nella pratica.

Ho pensato di fare un breve commento sulla tua prima domanda:

1) Come si ottengono le entità necessarie?

La prima cosa che faccio per un nuovo progetto è, su una lavagna bianca o un grande pezzo di carta bianco, scrivere tutte le cose fisiche e concettuali su quel particolare progetto a cui io e il mio team possiamo pensare. È una sessione di brainstorming.

I nomi tendono ad essere oggetti, i verbi tendono ad essere casi o metodi d'uso.

Fisico: foto (ovvio!), Tipo di visualizzazione, sistema, file di foto, formato file, utente, data ....
Concettuale: aggiungi, elimina, salva / archivia, recupera, ordina, modifica, visualizza / visualizza foto ....

Crea connessioni tra sostantivi e verbi. L'utente aggiunge una foto. (Bene - c'è un caso d'uso!)

Vorrei anche suggerire di guardare UML e Design Patterns e come possono essere usati in OOD generico. (Nota: non ho menzionato una lingua o un database da nessuna parte sopra. Non scegliere una lingua e quindi fare il tuo OOD. Fai il tuo OOD in modo tale che il design possa essere implementato da qualsiasi OOL.