Com'è comune per una squadra scrivere tutto internamente? [chiuso]

Un atteggiamento di mai che utilizza librerie di terze parti è assurdo. Scrivere tutto è un uso orribile del tempo della tua azienda, a meno che non vi sia un rigoroso obbligo commerciale che ogni riga nella base di codice sia stata scritta da un dipendente dell'azienda - ma quello è uno scenario insolito, specialmente per un'azienda del settore privato come hai descritto.

Una risposta più razionale e completa potrebbe essere stata che avrebbero usato solo librerie di terze parti che:

• Soddisfare le esigenze del codice che altrimenti si sarebbero scritti da soli
• Sono disponibili con una licenza compatibile con il modello di business della società
• Test inclusi
• Ha superato una revisione del codice

Se quei criteri sono stati soddisfatti (e nella mia esperienza la revisione del codice è molto flessibile soprattutto in presenza di buoni test), non stai più "facendo affidamento su nessun altro" - stai facendo affidamento su esistenti, disponibili, e preferibilmente codice robusto.

Se il codice è open source, nel peggiore dei casi, la libreria di terze parti diventa non mantenuta. Ma a chi importa? I test dimostrano che la libreria è adatta alle tue esigenze!

Inoltre, l'avversione a librerie di terze parti consolidate ostacola seriamente la produttività del programmatore. Supponiamo che la società stia scrivendo applicazioni web e abbia rifiutato di utilizzare (ad es. JQuery), quindi ha scritto la propria libreria alternativa per il cross-browser per semplificare la manipolazione del DOM. Con la quasi certezza possiamo supporre che la loro implementazione:

• Avrà un'API estranea agli sviluppatori che già conoscono jQuery
• Non sarà ben documentato come jQuery
• Non avrà risultati Google pertinenti in caso di problemi nell'utilizzo della libreria
• Non sarà testato sul campo come jQuery

Tutti questi punti sono importanti ostacoli alla produttività del programmatore. Come può un'azienda permettersi di rinunciare a una produttività del genere?

Hai aggiornato la tua domanda per chiederti se è appropriato far apparire in una seconda intervista. Lo è assolutamente.

Forse hai erroneamente interpretato la risposta dell'intervistatore nella prima intervista, o forse l'intervistatore ha semplicemente spiegato in modo errato la posizione dell'azienda e un nuovo intervistatore può chiarirlo.

Se spieghi che sei preoccupato per la loro posizione sulle librerie esterne, ci sono almeno due possibili risultati:

• Sono aperti a cambiare e la tua preoccupazione per il loro processo ti fa sembrare migliore rispetto ad altri candidati.
• Non sono aperti ai cambiamenti e pensano a te come "il tipo di sviluppatore che non vorremmo assumere". Non importa, non è il tipo di posto in cui vuoi lavorare comunque.

Sembra incredibilmente non competitivo. Ho lavorato in negozi che hanno deciso di saltare le librerie open-source standard come Hibernate e lanciare le proprie a causa di alcune funzionalità "critiche" mancanti. Alla fine il software è stato incredibilmente costoso da costruire e mantenere. Naturalmente la spesa della biblioteca interna è stata grossolanamente sottostimata. E mentre la libreria interna è stata scritta, le librerie standard sono avanzate rapidamente, aggiungendo nuove funzionalità che non erano disponibili nella libreria interna. Alla fine, il lavoro che avrebbe richiesto un'ora utilizzando una libreria standard richiedeva invece due giorni. Ed è stato un male per le carriere dello sviluppatore, dato che il mondo li ha superati. Eviterei un negozio del genere. Mi piace consegnare e non ho la pazienza di riscrivere quando potrei riutilizzare.

Il negozio ha una malattia chiamata Non inventato qui . È una buona ragione per interrompere immediatamente l'intervista e andarsene. Questo può essere curato solo da una pulizia top-down della casa che è molto improbabile che accada.

Per rispondere alla tua domanda, è purtroppo molto più comune di quanto tu possa pensare ed è sicuramente un motivo di preoccupazione.

Sì, sicuramente preoccupati! Che puzza di arroganza e (mi dispiace essere duro) stupidità. Qualsiasi programmatore con mezzo cervello userà una libreria come signalR invece di scriverlo da solo. Non ha assolutamente senso sprecare tempo a risolvere un problema che è già stato risolto. Cercherò di scoprire più informazioni prima - potrebbero aver frainteso te (potrebbe essere difficile anche se le interviste sono finite!)

Ho un paio di amici che hanno entrambi (brevemente) lavorato in case software con la sindrome non inventata qui . Quindi la mentalità è là fuori.

Un'osservazione che entrambi fecero riguardava la cultura dell'approccio promosso nei team di sviluppo. Entrambi hanno finito per lavorare con persone che erano piuttosto insulari in termini di prospettive sullo sviluppo del software e persone che non erano davvero motivate a imparare cose nuove e a spingere per la qualità. Indipendentemente dal livello in cui ti trovi nella tua carriera, ti piacerebbe sempre lavorare da qualche parte dove hai la possibilità di imparare cose nuove dai tuoi pari. Questo tipo di ambiente, tuttavia, sembra generalmente non essere trovato in luoghi che desiderano rotolare tutto da soli.

Non è comune dove vivo, e conosco molte aziende anche se colleghi. Direi che è un immediato "no grazie" da parte mia.

Non rigurgiterò i buoni punti già fatti, ma aggiungerò una cosa.

Hanno appena reso le assunzioni molto più difficili.

• Tutte le nuove assunzioni hanno una curva di apprendimento ancora più ripida rispetto alla parte principale del software / dominio
• I migliori candidati verranno rimandati perché non vorranno che le loro abilità diventino inutilizzate.
• È improbabile che le persone restino a lungo quando si rendono conto di quanto sia difficile non utilizzare i loro strumenti preferiti e il turnover del personale è costoso

Ora naturalmente ci saranno persone a cui piace la sfida, ma penso che sarebbero in minoranza.

E allo stesso modo, ci saranno alcune aziende che operano su "scala Internet", Amazon, Facebook, ecc., dove hanno folle esigenze di personalizzazione, ma ancora una volta sono in minoranza.

Non credo che una società di software possa sopravvivere oggi senza fare affidamento su software di terze parti e / o open source e, per rimanere competitivi, ovviamente devono tenere attivamente traccia delle nuove tecnologie. Ci sono spesso buone ragioni, tuttavia, per prendere almeno una visione piuttosto difensiva su di esso.

Ad esempio, se vendi software e richiedi di fornire assistenza 24 ore su 24, 7 giorni su 7 e sei anche legalmente responsabile del corretto funzionamento del tuo software, allora devi avere un'idea molto precisa di cosa accadrà se c'è un problema con il tuo software, ad esempio, in una fabbrica in cui 1 ora di downtime di produzione può costare diversi milioni di dollari, e quindi un bug serio si trova in quella libreria open source che stavi usando. Credimi, eseguirai valutazioni molto approfondite del software in questione.

Da quello che hai scritto, tuttavia, questo scenario non sembra essere il nocciolo della questione.

Se sei una società basata sulla tecnologia di una certa dimensione, allora sembrerebbe che svilupperai sempre di più la tua tecnologia, ad esempio: google sviluppa molto se non la maggior parte, se non tutto il loro software, mentre l'open source la maggior parte nel perseguimento di renderlo uno standard del settore.

Per le aziende più piccole, sembrerebbe una totale perdita di tempo quando cercano di spedire un prodotto specifico con la propria logica di business, e nella mia esperienza non ho visto che le piccole e medie imprese lo facciano.

Diventa più complicato quando parli di codice base altamente specializzato, ad esempio: algoritmi di crittografia - alcune persone hanno una comprensione di base su come funzionano, ma le parti complesse di implementare una soluzione in realtà potrebbero sembrare come te stesso nel piede a meno che non si assuma un crittografo specializzato in tali cose.

Alcune aziende consentono la libertà di creare i propri progetti open source, il che sembra più appropriato.

Personalmente non andrei in un posto con tale cultura.

Ciò che hai è un'ottima opportunità per andare alla seconda intervista e porre loro alcune domande difficili. Non so cosa fa l'azienda, quindi è difficile dire perché questa sembra una scelta strana. Puoi utilizzare il commento di @Daniel Pryden in merito all'utilizzo di librerie di terze parti da parte di Google.

Qualsiasi software che utilizzi, sia esso interno o di terzi, presenta vantaggi e svantaggi. Non usare uno strumento perché non è in-house, anche se è lo strumento migliore per il lavoro che mostra una certa mentalità chiusa e che non incoraggerà mai l'innovazione e la creatività.

Forse, forse, tu sei la persona che introduce questo cambiamento. Buona fortuna con tutto.

Ovviamente dovresti andartene. Non l'ho visto menzionato qui, ma la ragione principale per passare il lavoro è perché non guadagnerai molto nelle competenze trasferibili.

Immagina alla tua prossima intervista quando ti chiedono quali tecnologie hai lavorato e puoi solo menzionare bare bare C ++. Sembra un livello universitario

Le grandi aziende scrivono tutto da soli.

Ci sono diversi vantaggi nello scrivere da solo:

1. Hai la garanzia di possedere il software da solo
2. Puoi calcolare correttamente gli importi di lavoro che sono stati generati nella creazione di
3. La ripetizione dei passaggi diventa possibile anche se la volta successiva le librerie non sono disponibili
4. Riduce il bloat richiesto
5. Non stai ripetendo ciò che altri hanno già fatto
6. Hai la certezza di avere abbastanza persone per mantenerlo
7. Puoi modificare ogni parte del software
8. Le dimensioni del software sono limitate dalla quantità di risorse che hai

Ecco come si rompono i punti se usi la libreria di qualcun altro:

1. Qualcun altro possiede la lib
2. Non sai quanto sforzo è stato fatto per creare la lib
3. La tua prossima versione del prodotto è impossibile da creare sulla nuova piattaforma poiché le stesse librerie non sono più disponibili
4. La capacità di implementare i requisiti dipende dal fatto che la lib l'abbia implementata anni fa
5. Anche qualcun altro usa la stessa lib, ottenendo gli stessi limiti e funzionalità
6. Dato che non hai creato le librerie, non hai abbastanza persone per mantenere tutto il software nel tuo prodotto
7. I lib sono binari, non modificabili. Anche se l'origine è disponibile, non hai abbastanza persone per modificare quella grande quantità di codice.
8. Mantenere il codice che hai creato + le librerie è uno sforzo maggiore di quanto avessi inizialmente stimato