window.pipedriveLeadboosterConfig = { base: pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', version: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster on jo olemassa') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() Miksi Kotlin on mahtava, mutta pysyt kuitenkin Javassa - The Codest
Codest
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Toimialat
    • Fintech & pankkitoiminta
    • E-commerce
    • Adtech
    • Terveysteknologia
    • Valmistus
    • Logistiikka
    • Autoteollisuus
    • IOT
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
  • Tietoa meistä
  • Palvelut
    • Ohjelmistokehitys
      • Frontend-kehitys
      • Backend-kehitys
    • Staff Augmentation
      • Frontend-kehittäjät
      • Backend-kehittäjät
      • Tietoinsinöörit
      • Pilvi-insinöörit
      • QA insinöörit
      • Muut
    • Se neuvoa-antava
      • Tilintarkastus & konsultointi
  • Arvo
    • TOIMITUSJOHTAJA
    • CTO
    • Toimituspäällikkö
  • Tiimimme
  • Tapaustutkimukset
  • Tiedä miten
    • Blogi
    • Tapaamiset
    • Webinaarit
    • Resurssit
Työurat Ota yhteyttä
Takaisin nuoli PALAA TAAKSE
2022-05-18
Ohjelmistokehitys

Miksi Kotlin on mahtava, mutta pysyt silti Javassa?

Codest

Marcin Perlikowski

Vanhempi Java-kehittäjä

Jos olet Java-kehittäjä, sinulla on todennäköisesti ainakin jonkin verran kokemusta muista ohjelmointikielistä. Jotkut meistä aloittivat ohjelmointiseikkailunsa jollakin muulla kielellä, kuten C/C++, JavaScript, C#, Python tai ehkä jopa Pascalilla tai Basicilla. Jotkut kuitenkin aloittivat Javalla eivätkä vain koskaan kiinnittäneet kovinkaan paljon huomiota muihin kieliin, muistellen ikävästi sitä yhtä kertaa, kun heidän piti nopeasti koodata jotain frontend-puolella.

Riippumatta siitä, mihin ryhmään kuulut, on olemassa syy, miksi pysyt mukana Java. Enkä syytä sinua. Se on luultavasti kehittynein, yleisin ja täydellisin ekosysteemi koko maailmassa. yritys maailmaan. Kielessä on mukavasti räätälöityjä valmiuksia, jotka ovat jossain oikealla alueella liiallisen ja liian vähäisen välillä. Uusia ominaisuuksia lisätään hitaasti mutta tasaisesti, jolloin kieli pysyy pääosin ohjelmointimaailman uusien suuntausten tasalla.

Tiedätkö Lombok kuitenkin? Jos et tunne, suosittelen kokeilemaan. Jos pidät siitä, minulla on jotain juuri sinulle kokeiltavaa. Kokonaan uusi kieli, joka ominaisuuksiltaan tekee Lombokista tarpeettoman. Sen nimi on Kotlin.

Kotlin? Tarkoitatko Androidin kieltä?

No kyllä, mutta itse asiassa ei

Google itse siunasi Kotlinin Androidissa niin, että siitä tuli alustan de facto-kieli. En keskity tässä artikkelissa tähän, mutta Android on todellakin paikka, jossa tapasin Kotlinin ensimmäistä kertaa.

Työkaverini oli kehittämässä sovellusta silloiselle nykyiselle projektiyksin. Määräajat lähestyivät kuitenkin nopeasti, joten minut valtuutettiin auttamaan häntä niiden täyttämisessä. Siirryn nyt ajassa taaksepäin tuohon hetkeen. Ja... YUCK! Miksi hän käyttää jotain outoa kieltä, joka kuulostaa kuin ketsuppimerkki!? Se näyttää kamalalta!

Miksi ennen jokaista funktiota kirjoitetaan "fun"? Ihan kuin en jo tietäisi, mikä se on. Lisäksi minulla on jo hauskaa kanssa Java joka tapauksessa. Ja missä on paluutyyppi? Lopussa? Oletko hullu? Mitä tuo on, osoitatko jotain funktiolle? Siinä ei ole mitään järkeä! Kaikki näyttää vain siltä, että Java lisävaiheilla! Odota, mihin luokkaan tämä metodi kuuluu? Minne piilotit sen, senkin ketsuppi-ääninen, Java jäljittelevä tekosyy ohjelmointikielelle? Voi ei. Voi ei, et tehnyt. ONKO TUO GLOBAALI FUNKTIO? Nyt riittää, olen valmis, soitan poliisille.

Spoilerivaroitus: en soittanut lainvalvontaviranomaisille. Halusinpa tai en, minun oli mukautettava Java-keskeistä ajattelutapaani toisen kielen huomioon ottamiseksi. Eihän se kuitenkaan ole niin paha, eikö niin? Se on edelleen JVM-kieli, varmasti se on vain eri Java. Ehkä jopa hienoilla lisäominaisuuksilla? Vastahakoisesti aloin työstää projektia.

Java lisävaiheiden kanssa

Jos Java on niin loistava, miksi Java 2:ta ei ole olemassa? Vitsit sikseen, Niin ajattelin itsekseni. Teeskentelen, että Kotlin on Java 2. Uusi syntaksi ja kaikki, mutta minun on vain opittava tarpeeksi, jotta saan projektin valmiiksi. Voi pojat, olin väärässä.

Kokeiltuani sitä vain päivän tai kaksi, tajusin nopeasti, että sekä Kotlin että Java eivät ole niin joustavia. Jos niitä yrittää taivuttaa toisiaan kohti, toinen niistä katkeaa väistämättä kahtia. Tuli selväksi, että Kotlin on asia erikseen, ja se, että se toimii JVM:llä, ei merkitse ohjelmoijan näkökulmasta juuri mitään. (Sivuhuomautuksena mainittakoon, että se voi myös transpileerata JavaScript, tai kääntää natiiviksi binääriksi).

Suunnitelma B sitten. Itse asiassa tutustu kieleen. Jos lukee dokumentteja ensimmäistä kertaa, kokeneen Java-ohjelmoijan selkärangan läpi tulee väristyksiä. Esimerkiksi:
- aiemmin mainittu ylätason eli globaali konteksti
- lopussa määritetyt parametri- ja palautustyypit

fun sum(a: Int, b: Int): Int {
   return a + b
}

funktiorunko voi olla lauseke (tasa-arvomerkin avulla).

 fun sum(a: Int, b: Int) = a + b

if-lause voi antaa tuloksen

 val y = if (x == 1) {
 "one"
 } else if (x == 2) {
 "two"
 } else {
 "other"
 }

Okei, minun täytyy vain tottua siihen. Vain erilainen syntaksi. Mitä muuta sinulla on tarjota, herra Kotlin?

 value?.method() // execute if not null

Okei, eroon pääseminen if (arvo == null), piste sinulle. Mitä muuta sinulla on?

fun check(list: List, alternative: Boolean) = when {
 list on LinkedList -> print("linked")
 vaihtoehto -> print("vaihtoehto")
 list.size > 50 -> print("iso")
 else -> print("muu")
 }

Hmm kiva, voisi olla kätevää välttää, jos muut blokkaavat, mutta vaikuttaa silti kikkailulta.

 object SingularObject: Counter() {
 var a = 14
 fun test() = if (a > 10) "enemmän" else "vähemmän"
 }

Okei, tuo näyttää todella hyödylliseltä, pidän siitä! Toisaalta voin luoda singletonin myös Javassa. Ehkä se ei ole näin tyylikäs, mutta se ei ole mitään uutta. Onko sinulla ässiä hihassa? Todellisia kovia kamaa?

 var s: String = null // ei käänny, ei-null-tyyppi.

Odota... mitä?

Miljardin dollarin virhe

Kuvittele koodipohja, jossa sinun ei tarvitse huolehtia nollaturvallisuudesta. Kuvittele, että pidät itsestäänselvyytenä sitä, että jokainen viittaus todella sisältää jotain merkityksellistä. Kuvittele olevasi varma, että kaikki nollaan liittyvät ongelmat on hoidettu etukäteen.
Kuvittele enää. Kotlinissa kaikki viittaukset eivät ole oletusarvoisesti nollattavissa. Jos haluat tehdä siitä nollattavissa olevan, sinun täytyy tehdä tietoisesti tehdä tämä päätös, ja nimenomaisesti ilmoittaa sen koodi:

 var s: String? = null

Ymmärrän, että suhtaudutte ehkä epäilevästi koko ajatukseen tässä vaiheessa. Olet tottunut mitätöitäviin viittauksiin. Pidät sen takaraivossasi koodatessasi. Olet oppinut, missä sinun on oltava varovainen. Ajatukseni ovat täsmälleen samat. Tulossa Java, se tuntui aluksi todella oudolta. Kuten, mitä järkeä siinä on? Se ei taikomalla saa kaikkia asiaan liittyviä ongelmia katoamaan. Minun täytyy vain lisätä "?" joka paikkaan, kuulostaa työläältä.

Mutta päätin sukeltaa syvälle kieleen. Tehdään se sinun tavallasi, herra. Kotlin. Aloin pyrkiä poistamaan niin monta nollattavaa muuttujaa, kenttää ja parametria kuin mahdollista. Askel askeleelta opin käyttämään kielen ominaisuuksia, jotka helpottivat nollattavien viittausten poistamista, esimerkiksi safe call "?." -operaattoria, elvis "?:" -operaattoria, delegoituja ominaisuuksia, let-metodia ja paljon muuta.

Ajan myötä sain aikaan sen, että jotkut luokat sisälsivät vain kenttiä ja metodiparametreja, jotka eivät olleet nollia. Periaatteessa tiesin, että jos luokka oli onnistuneesti instantioitu, metodien nollattavuus voitiin melkein unohtaa. Se oli autuaaksi tekevää. Ajan myötä arvostin tätä yhä enemmän. Lopulta en kuitenkaan pitänyt sitä tappavana ominaisuutena, Java tuntui yhä kodilta. Kunnes...

Paluu

Hanke lähestyi loppuaan. Tutustuin Kotliniin yhä paremmin, ja tämän tiedon myötä koodista tuli yhä siistimpää, luettavampaa ja tiiviimpää. Parannukset saattoi nähdä paljain silmin commit-historiassa. Aika on kuitenkin vihdoin koittanut. Kun uudesta kielestä jäi yllättävänkin mukavia muistoja, oli aika sanoa hyvästit ja palata takaisin suloiseen mukavuusalueeseen Java. Tai niin minä luulin.

Tiedätkö sen tunteen, kun alat arvostaa jotain juuri sillä hetkellä, kun se on poissa? Kun et tajua, miten paljon luotat johonkin, ennen kuin et voi enää käyttää sitä? Se oli paras esimerkki tuosta tunteesta, jonka olen luultavasti koskaan elämässäni kokenut.

Kun palasin kirjoittamaan koodia Java, olin melkein kauhuissani joidenkin ominaisuuksien puuttumisesta. Aivoni ikään kuin olisivat alitajuisesti ja virheellisesti jälkiasentaneet Kotlinin ominaisuuksia Javaan. Koin tilanteita, joissa aloin itse asiassa toteuttaa jotain, mutta tajusin, ettei se toimi tällä kielellä. Parhaassa tapauksessa voisin kirjoittaa sen Kotlinin tapaan, mutta siitä tulisi tilaa vievä, lukukelvoton ja/tai se vaatisi liikaa boilerplatea.

Nollaturvallisuus oli tietenkin ominaisuus, jota kaipasin eniten. Yllätyin kuitenkin siitä, kuinka monista pienemmistä asioista tuli minulle luonnollisia: nimetyt parametrit, ominaisuudet getterien ja setterien sijaan, "==" yhtäläisyyksinä ja "===" viittauksellisena yhtäläisyytenä, kvalifioitu "this", laajennusfunktiot, implisiittinen singulaarinen lambda-parametri, "_" käyttämättömille lambda-parametreille, dataluokat, scope-funktiot, Kotlinin stdlibin funktiot, operaattorit ja paljon muuta. Ja se, miten kaikki sopii hienosti yhteen. Vertailun vuoksi Java tuntui... primitiiviseltä.

Se tuntui itse asiassa niin pahalta, että aloin harkita Kotliniin siirtymistä kokonaan. Teoriassa se on täysin yhteensopiva Javan kanssa, voit vain lisätä Kotlin-tuen olemassa olevaan projektiin ja alkaa kirjoittaa uusia luokkia. Kotlinin puoli osaa "puhua" Javalle, eikä Javan puoli edes tiedä, että se "puhuu" toisen kielen kanssa. Ja bytecode-kääntämisen jälkeen JVM:llä ei ole oikeastaan mitään merkitystä.

Tapaa Java-asiantuntija

Todellisuuden tarkistus

Joten mitä sinä odotat? Jos kieli on niin hyvä kuin sanot, käytä sitä! Ehkä ei kuitenkaan nykyisissä projekteissa, sillä tiedän, että sen pitäisi olla yhteentoimiva, mutta kahden eri kielen sekoittaminen tällä tavalla kuulostaa rumalta.

Okei, uusia moduuleja varten - Kotlin se on. Vai onko? Työskentelet joukkue. Sinun on kuultava heitä ja vakuutettava heidät tämän uuden kielen suuruudesta. Mitä? Eivätkö he pidä siitä? Kuulostaa siltä, etteivät he vain halua nähdä vaivaa sen oppimiseksi. Et voi syyttää heitä, sinäkin olit aluksi epäileväinen.

Projektipäällikkö! Kyllä! Hän ymmärtää varmasti, miten paljon hyötyä Kotlin tuo tiimillemme. Voi sitä mahtavuutta, joka tulee!
-No
-Odota, miksi?
-Joukkue ei tiedä sitä.
-He oppivat!
-He eivät halua oppia.
-Voit tehdä niitä!
-Heidän ei tarvitse oppia.
-Se on totta, mutta ajattele mahdollisuuksia!
-Joo, entä jos ajattelisit ensin ongelmia.

Legendan mukaan on olemassa hanke. Projekti, joka on suuri ja monimutkainen, mutta joka on kirjoitettu hienosti joka osaan. Projekti, jossa kaikki kehittäjät ovat yksimielisiä käytetyistä ratkaisuista. Jossa uudet toiminnallisuudet vain virtaavat sujuvasti ohjelmoijien näppäimistöltä. Jossa virheet ovat harvinaisia ja helppo korjata.

Oletko nähnyt tällaista hanketta? En ole. Jotkin olivat lähellä, mutta useimmat niistä ovat suurta perintökoodin sekasotkua. Ja jos ne eivät ole, niistä tulee todennäköisesti sellainen jossain vaiheessa tulevaisuudessa. Kuvittele nyt, että sekaan lisätään toinen kieli. Se tuo uusia tapoja tehdä virheitä. Se edellyttää, että kehittäjät tietävät, mitä he tekevät. Se on vähintäänkin riski.

Ota nyt huomioon myös kehittäjien rotaatio. Ihmisiä tulee ja menee. Pakotatko jokaisen uuden kehittäjän opettelemaan kokonaan uuden kielen? Ei, se on haitallista. Palkkaatko Kotlin-kehittäjiä ylipäätään? Onnea sen kanssa, hyvän Java-kehittäjän palkkaaminen on tarpeeksi vaikeaa.

Ihmiset ovat yrittäneet. Minun on sanottava, että en ole samaa mieltä useimmista artikkelin väitteistä. Siinä on jonkin verran perusteltua kritiikkiä, mutta mielestäni he eivät käyttäneet Kotlinia tarpeeksi ymmärtääkseen "Kotlinin tapaa". Monet kommentoijat artikkelin alla näyttävät ajattelevan samalla tavalla.

Sillä ei kuitenkaan ole väliä. Veikkaan, että näin tapahtuisi myös sinun projektissasi. "Kokeilin sitä, en pitänyt siitä". Et saa heitä käyttämään siihen enemmän aikaa. Et saa heitä yrittämään uudelleen. Et saa heitä antamaan sille uutta mahdollisuutta. Ja käytännön näkökulmasta katsottuna he saattavat olla oikeassa. Java on vain niin suosittu, että minkään muun käyttäminen JVM:ssä tuntuu tarpeettomalta.

Miksi sitten tämä artikkeli?

Käytit juuri huomattavan paljon aikaa kirjoittaessasi artikkelia, jolla ei näytä olevan mitään pointtia. Miksi yrittäisin opetella kieltä, jos se on mielestäsi joka tapauksessa turhaa?

Minusta se ei ole turhaa. Olen edelleen sitä mieltä, että Kotlin on loistava. Haluan edelleen käyttää sitä (ja käytänkin sitä yksityisissä projekteissani). Jos voisin, siirtyisin siihen ja unohtaisin Javan rajoitukset. Mutta nykyinen todellisuus sanoo, etten voi. Ja haluan yrittää muuttaa sitä.

Tarkoitukseni on, että sinä, rakas lukija, ainakin harkitset mahdollisuutta tulla ulos mukavalta Java-mukavuusalueelta. Koska ehkä, vain ehkä, sinä rakastat Kotlinia yhtä paljon kuin minä. Ja jos rakastat, yksi Kotlinia tunteva kehittäjä lisää. markkinat.

Lue lisää:

Parhaat projektityypit Javalle

3 yleistä haastetta startup-yritysten ohjelmistotuotekehityksessä

Oikea tapa löytää parhaat Java-kehittäjät

Aiheeseen liittyvät artikkelit

Ohjelmistokehitys

Tulevaisuuden web-sovellusten rakentaminen: The Codest:n asiantuntijatiimin näkemyksiä

Tutustu siihen, miten The Codest loistaa skaalautuvien, interaktiivisten verkkosovellusten luomisessa huipputeknologian avulla ja tarjoaa saumattomia käyttäjäkokemuksia kaikilla alustoilla. Lue, miten asiantuntemuksemme edistää digitaalista muutosta ja liiketoimintaa...

THECODEST
Ohjelmistokehitys

Top 10 Latviassa toimivaa ohjelmistokehitysyritystä

Tutustu Latvian parhaisiin ohjelmistokehitysyrityksiin ja niiden innovatiivisiin ratkaisuihin uusimmassa artikkelissamme. Tutustu siihen, miten nämä teknologiajohtajat voivat auttaa nostamaan liiketoimintaasi.

thecodest
Yritys- ja skaalausratkaisut

Java-ohjelmistokehityksen perusteet: A Guide to Outsourcing Successfully

Tutustu tähän keskeiseen oppaaseen Java-ohjelmistokehityksen onnistuneesta ulkoistamisesta tehokkuuden parantamiseksi, asiantuntemuksen saamiseksi ja projektin onnistumiseksi The Codestin avulla.

thecodest
Ohjelmistokehitys

Perimmäinen opas ulkoistamiseen Puolassa

Ulkoistamisen lisääntyminen Puolassa johtuu taloudellisesta, koulutuksellisesta ja teknologisesta kehityksestä, joka edistää tietotekniikan kasvua ja yritysystävällistä ilmapiiriä.

TheCodest
Yritys- ja skaalausratkaisut

Täydellinen opas IT-tarkastustyökaluihin ja -tekniikoihin

Tietotekniikan tarkastuksilla varmistetaan turvalliset, tehokkaat ja vaatimustenmukaiset järjestelmät. Lue lisää niiden merkityksestä lukemalla koko artikkeli.

Codest
Jakub Jakubowicz teknologiajohtaja ja toinen perustaja

Tilaa tietopankkimme ja pysy ajan tasalla IT-alan asiantuntemuksesta.

    Tietoa meistä

    The Codest - Kansainvälinen ohjelmistokehitysyritys, jolla on teknologiakeskuksia Puolassa.

    Yhdistynyt kuningaskunta - pääkonttori

    • Toimisto 303B, 182-184 High Street North E6 2JA
      Lontoo, Englanti

    Puola - Paikalliset teknologiakeskukset

    • Fabryczna Office Park, Aleja
      Pokoju 18, 31-564 Krakova
    • Brain Embassy, Konstruktorska
      11, 02-673 Varsova, Puola

      Codest

    • Etusivu
    • Tietoa meistä
    • Palvelut
    • Tapaustutkimukset
    • Tiedä miten
    • Työurat
    • Sanakirja

      Palvelut

    • Se neuvoa-antava
    • Ohjelmistokehitys
    • Backend-kehitys
    • Frontend-kehitys
    • Staff Augmentation
    • Backend-kehittäjät
    • Pilvi-insinöörit
    • Tietoinsinöörit
    • Muut
    • QA insinöörit

      Resurssit

    • Faktoja ja myyttejä yhteistyöstä ulkoisen ohjelmistokehityskumppanin kanssa
    • Yhdysvalloista Eurooppaan: Miksi amerikkalaiset startup-yritykset päättävät muuttaa Eurooppaan?
    • Tech Offshore -kehityskeskusten vertailu: Tech Offshore Eurooppa (Puola), ASEAN (Filippiinit), Euraasia (Turkki).
    • Mitkä ovat teknologiajohtajien ja tietohallintojohtajien tärkeimmät haasteet?
    • Codest
    • Codest
    • Codest
    • Privacy policy
    • Verkkosivuston käyttöehdot

    Tekijänoikeus © 2025 by The Codest. Kaikki oikeudet pidätetään.

    fiFinnish
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek fiFinnish