Joitakin päiviä sitten, Dropbox-kehittäjät viestin kautta sovelluksen virallisessa blogissa paljastivat reitin, jota he aikovat seurata mobiilikehityksen kannalta käyttöympäristösi välisestä sovelluksesta, jossa tiimi on päättänyt luoda yhtenäisen koodipohjan, eri tarkoituksiin tai alustoille.
Lähestymistapa voi olla hyödyllinen pienille joukkueille, joilla on vähän taitoa, mutta tuotantoa tarvitaan mahdollisimman nopeasti. Vuodesta 2013 Dropbox-tiimi on luottanut tähän strategiaan. TOvihje Android- ja iOS-alustoille ainutlaatuisen C ++ -sisäänrakennetun koodipohjan avulla. Viestissä selitetään, miksi yritys suosii nyt Swiftin ja Kotlinin omaa kehitystä.
"Kokoamalla koodipohjamme epätyypillisellä tavalla perimme kustannukset, joista emme olisi joutuneet huolehtimaan, jos olisimme linjassa oletusaseiden kanssa, joita kolmannet osapuolet käyttävät laajasti." Loppujen lopuksi se oli enemmän kalliimpaa kuin koodin kirjoittaminen. kahdesti ", hän sanoi.
Yhtäkkiä, Dropbox-insinöörien palaute osoittaa, että monitasoisen kehitystavan valitseminen tuo mukanaan mukautettujen kirjastojen ja kehysten käyttöönottoon liittyviä lisäkehityskustannuksia.
Puhumattakaan niistä, jotka liittyvät mukautettujen työvälineiden käyttöönottoon tai tarpeeseen kouluttaa tai rekrytoida kolmansia osapuolia, jotka kykenevät sopeutumaan erittäin räätälöityihin ohjelmistopinoihin.
Itse asiassa, korostaa, että C ++: n valinta Android- ja iOS-alustojen väliseen kehitykseen voi johtaa kehittäjille vaikeuksiin joita heillä ei olisi ollut syntyperäisesti.
Hän sanoo esimerkiksi, että kehyksen luominen taustalla toimivien tehtävien hallitsemiseksi voi olla välttämätöntä alustojen välisessä C ++ -kehitysvaiheessa.
Sitä vastoin, Toinen insinööri selittää Dropbox-insinöörin, se ei ole ongelma alkuperäisessä.
Se jopa väittää, että Dropbox-tiimin oli prosessin aikana perustettava JSON-kirjasto C ++ 11: lle sekä toinen NULL-osoittimien käsittelemiseksi.
Yhtiön insinööri meni vielä pidemmälle korostamalla, että hän on siirtymässä ajatukseen siitä, että voidaan rakentaa yksi koodipohja useille alustoille.
Itse asiassa hän vaatii, että kunkin alustan erityispiirteet ovat tekijöitä, joita ei voida välttää.
"Tapa, jolla sovellus toimii taustalla, on alustakohtainen, ja sitä on tarkasteltava alusta alkaen", hän sanoo.
Koodiin vaikuttavien näkökohtien lisäksi on myös työkaluja. Tässä mielessä yrityksen insinööri kehittyy kahdella akselilla: virheenkorjaus ja räätälöityjen työkalujen konfigurointi.
"Natiivi virheenkorjauskokemus on yleensä parempi kuin C ++ kohdealustan oletusarvoisen IDE: n kautta", hän kirjoittaa ja lisää, että "sen lisäksi, että joudumme siirtymään pois käytettävissä olevista työkaluista, joudumme mobilisoimaan kehitystyötä myös toiset pystyvät tukemaan alustojen välistä lähestymistapaa C ++: ssa. «
Lopuksi, koulutuksen ja rekrytointiasioiden osalta Eyal Guthmann kertoo, että monitasoinen seikkailu rakennettiin sellaisten insinöörien ympärille, joilla on vankka tausta C ++: ssa.
Jälkimmäisen lähdettyä muille ryhmille tai yrityksille, yrityksen on ollut yhä vaikeampaa täyttää teknistä aukkoa C ++ -koodipohjan ylläpitämiseksi. Sisäisesti ja ulkoisesti yrityksellä on ollut vaikeuksia kouluttaa ja rekrytoida tällä akselilla, koska näyttää siltä, että hyvin harvat mobiilikehittäjät ovat kiinnostuneita C ++: sta.
Joukkueen siirtämisellä Dropboxista kotimaahan Kotlinin ja Swiftin kautta Androidille ja iOS: lle on etuja.
Itse asiassa C ++ -kieli, samoin kuin C, jota et enää mainitse, toimii yhteisenä nimittäjänä tällaisten ongelmien hallitsemisessa.
Ei ole vaikea kuvitella, että alkuperäinen insinöörien ryhmä integroi sen taustatietojen tiettyjen kriittisten näkökohtien hallintaan. Ainoastaan kysymykset C ++ -liitännän ja kohdealustojen laadusta voidaan esittää pöydälle.
lähde: https://blogs.dropbox.com/