Anda akan mengatakan apa masalahnya kepada pengembang seluler sebelum apa yang tertulis di backend. Yang utama adalah bahwa API di sana harus nyaman, dapat dimengerti, fleksibel. Tapi kami rasa tidak.
Di AppsConf, kita semua berpikir bahwa kadang-kadang kita perlu melampaui pengembangan seluler dan memompa topi huruf T dalam model bentuk-T. Di sini, misalnya, mengenal bahasa server sedikit lebih dalam daripada: "Saya mendengar bahwa Ruby mati." Dan sedikit lebih luas - yaitu, tidak hanya dengan yang populer, tetapi juga dari baris kedua dan bahkan yang bawah tanah.
Untuk membuat Anda terinspirasi oleh gagasan jalur Pengantar, kami merekam wawancara dengan Nikita Sobolev. Mereka akan berbicara tentang bahasa pemrograman, tetapi ternyata tentang programmer. Jadi, jika Anda berpikir bahwa lebih baik menjadi pengembang yang baik, dan bukan pengembang Android atau iOS, dan terutama jika Anda tidak setuju dengan ini. Jumat adalah waktu untuk berdebat.
- Bagaimana Anda menyukai gagasan seluruh jalur laporan peninjauan tentang berbagai teknologi dari backend ke frontend di konferensi tentang pengembangan ponsel, yang kami sebut Pengantar?
Nikita Sobolev CTO di wemake.services, penulis metodologi Proses Pengembangan Perangkat Lunak Berulang, penyelenggara ElixirLangMoscow, anggota komite program Moskow Python Conf ++ , pembicara yang sering di konferensi IT dan juara untuk kualitas kode .
Menurut pendapat saya, ini adalah trek terbaik di konferensi seluler.
Saya tidak terlalu menyukai gagasan spesialis sempit. Saya jauh lebih dekat dengan gagasan tentang seseorang yang berbentuk T - yaitu, seseorang yang fasih dalam satu hal, tetapi dengan cakrawala yang luas dalam memahami masalah di bidang subjek.
Sayangnya, menurut saya pengembang seluler dalam pengertian ini sendirian. Masalahnya diperparah oleh kenyataan bahwa mereka sangat bergantung pada vendor. Secara kasar, Apple akan menutup - mereka akan pergi dalam cuaca dingin.
Oleh karena itu, saya benar-benar menyukai gagasan jalur Pengantar dan fakta bahwa tamu konferensi diundang untuk melihat-lihat, mencari tahu apa yang dimiliki orang lain, mengadopsi pengalaman mereka dan meningkatkan diri mereka sebagai spesialis dalam hal luasnya pandangan.
- Untuk konferensi apa ide ini relevan?Untuk banyak orang. Saya sudah punya contoh Python. Terakhir kali kami mengundang Go, Elixir dan Julia. Tahun ini saya ingin mengundang front-end dan Haskellist (
omong -
omong, Call for Papers sudah terbuka ). Karena pengembang Python juga berbeda, banyak dari mereka bekerja sebagai tumpukan penuh, ini juga berguna bagi mereka untuk mendapatkan pengetahuan dari luar.
- Apakah Anda pikir pengembang seluler menjadi lebih bersedia untuk melihat-lihat, karena telah menjadi penting untuk pengembangan profesional, atau apakah memang selalu demikian, hanya komunitas telah matang?Sulit bagi saya untuk menilai secara akurat, terakhir kali saya menulis aplikasi seluler pada 2010. Bahasa utama saya saat itu adalah Java, saya mengambil Objective-C dan menulis aplikasi untuk iOS. Saya terinspirasi, saya pikir, sekarang saya akan mulai melakukan semua ini. Tapi tidak: tidak ada manajemen memori, tidak ada perpustakaan, tidak ada manajemen ketergantungan, sistem build menjijikkan. Sejak itu, saya belum hati-hati melihat ke daerah ini.
Dan sekarang saya melihat beberapa tren yang secara alami menarik pekerja seluler ke “pemrograman serius”.
Di masa lalu, bahasa sangat terspesialisasi dalam bidang ini. Objective-C hanya untuk pengembangan Apple. Dan sekarang, misalnya, mereka mencoba menarik Swift ke server dan melakukan sesuatu. Java untuk backend dan untuk Android adalah dua bahasa yang berbeda. Dan sekarang Kotlin kurang lebih sama untuk keduanya. JavaScript muncul di dunia pengembangan aplikasi seluler, dan ini adalah semacam bahasa server, dan pada saat yang sama, bahasa untuk frontend.
Ada satu infrastruktur yang mulai menarik minat orang. Jika sebelumnya (dalam kasus saya ini 2010) pengembangan ponsel benar-benar tidak tersentuh, sekarang semuanya berbeda.
Selain itu, pemulihan hubungan ada di kedua sisi. Integrasi platform yang lebih ketat memberi orang kemampuan dan kebutuhan untuk mengikuti integrasi ini.
- Tetapi jika integrasi itu sendiri pergi ke pengembang seluler, mengapa ia harus memahami bahasa untuk backend?Saya punya jawaban filosofis untuk pertanyaan ini.
Jika Anda ingin menjadi pengembang Android, maka Anda mungkin tidak perlu memahami backend. Dan jika Anda ingin menjadi pengembang - tentu saja, itu perlu.
Pengembang adalah seseorang yang memecahkan masalah dari dunia nyata dengan kode. Dengan demikian, keputusan dapat terjadi di mana-mana, termasuk dalam aplikasi seluler, di server, di frontend. Pengembang yang baik pada dasarnya dapat memecahkan masalah di dunia nyata menggunakan alat pengembangan.
Jelas bahwa ada jalan masuk ke masing-masing alat ini, akumulasi praktik dan sebagainya, tetapi fiksasi yang kaku pada satu teknologi, menurut saya, merugikan individu yang terlibat dalam hal ini.
Setidaknya teknologi menjadi usang. Bahasa yang populer 15 tahun lalu sekarang hampir tidak pernah digunakan. Keterampilan untuk terus-menerus mengembangkan dan mempelajari hal-hal baru, melihat tetangga, sangat penting bagi pengembang mana pun. Secara khusus, penting untuk memahami backend, karena backend adalah dasar untuk seluruh pengembangan, hari ini semuanya entah bagaimana berkomunikasi dengan server.
Selain itu, yang pasti, pengguna mobilitas merasa tidak nyaman dengan pengembang lain yang merasa lebih mudah menemukan bahasa yang sama. Front-end dan back-end masih lebih dekat daripada pengembang aplikasi seluler ke salah satu dari mereka. Laporan saya akan membantu sampai batas tertentu menutup masalah komunikasi manusia, membantu mengintegrasikan.
Seberapa dalam atau dangkal yang perlu Anda pahami adalah pertanyaan lain. Terutama jika kita berbicara tentang pengembang seluler yang, apa pun yang dikatakan orang, perlu menggali lebih dalam bidangnya.
Saya mendukung fakta bahwa Anda perlu secara aktif melihat-lihat dan di masa lalu. Penting untuk mempelajari sejarah perangkat lunak dan pemrograman. Jika Anda tidak tahu ceritanya, maka Anda akan menemukan kembali banyak hal yang telah Anda buat dan tinggalkan untuk alasan yang sepenuhnya objektif. Saya memimpin
saluran telegram di mana saya membagikan tautan ke proyek sumber terbuka yang keren tanpa terikat dengan bahasa, saya mencoba menyoroti ide-ide penting.
- Apakah pengembang aplikasi seluler memiliki cukup gagasan umum atau tidak?Pertama-tama tergantung pada lingkungan. Jika seseorang memiliki kebutuhan untuk secara langsung mempengaruhi backend di perusahaannya: untuk menetapkan tugas yang lebih tepat bagi mereka, untuk berpartisipasi dalam proses, mungkin untuk mengelola orang-orang ini, maka Anda harus memikirkannya secara mendalam.
Tetapi jika Anda hanya terlibat dalam pengembangan ponsel, maka cukuplah untuk memiliki ide yang dangkal tentang apa yang terjadi di sana, bahasa apa, masalah, solusi populer apa. Untuk orang-orang seperti itu,
laporan saya tentang Saint AppsConf juga dihitung. Secara alami, presentasi yang mendalam tidak dapat diberikan dalam satu laporan.
- Apa lagi yang dibutuhkan pengembang untuk menjadi pengembang yang keren?- Kemampuan membaca dan memahami apa yang dibaca.
- Kemampuan menulis, ungkapkan pikiran Anda secara tertulis.
- Kemampuan berbicara untuk mengekspresikan pikiran-pikiran ini secara lisan.
- Kemampuan untuk mendengarkan dan mendengar orang lain.
- Memahami area subjek. Pengembang harus memahami apa yang dia lakukan, karena dia menyelesaikan masalah kehidupan dengan cara teknis.
- Dan tentu saja, pahami tekniknya.
Keterampilan ini, menurut saya, sudah cukup. Segala sesuatu yang lain dapat disimpulkan dari ini, atau dibuang.
- Jadi Anda pikir Anda perlu memahami bidang studi?Terbatas, tentu saja, tetapi perlu. Misalnya, kami secara bersamaan memiliki 3-4 proyek, tentu saja, saya tidak memahami semuanya dengan sempurna, tetapi saya memahami konsep dasar yang saya gunakan. Bagaimana mereka saling berhubungan, bagaimana mereka mempengaruhi uang, di mana biayanya, di mana pendapatan, mengapa semua ini diperlukan untuk bisnis.
Dan saya menyarankan pengembang lain juga. Di perusahaan kami, kami menyusun dokumentasi untuk mereka, cara kerja bisnis, masalah apa yang kami pecahkan, mengapa ini tidak dapat diselesaikan dengan tangan. Kadang-kadang mempekerjakan seseorang sehingga ia pernah, misalnya, pergi melalui direktori barang, lebih murah. Jika kami mengotomatiskan prosesnya, Anda perlu memahami alasannya.
- Mari kita lihat sebuah contoh. Jika Anda menulis layanan pengiriman untuk toko roti, Anda harus memahami cara kerja pengiriman, tetapi Anda tidak harus memahami jenis roti yang dibuat oleh toko roti ini?Dan dalam beberapa jenis roti juga. Karena beberapa roti dapat disimpan selama satu jam, dan sekitar dua hari. Dengan demikian, pengiriman mereka akan berbeda.
- Dalam laporan Anda, Anda berjanji untuk mempertimbangkan beberapa bahasa populer sekaligus, beberapa bahasa dari baris kedua dan beberapa bahasa dari bawah tanah. Akan bahasa apa mereka?Saya tidak akan mengambil bahasa yang peserta konferensi sudah bisa tahu: Kotlin, Java, JavaScript. Tidak masuk akal untuk berbicara tentang mereka jika sebagian besar penonton sudah akrab dengan mereka. Saya memutuskan untuk berbicara tentang bahasa yang dijamin tidak diketahui orang, karena aplikasi seluler tidak menulis sama sekali. Ada banyak pilihan.
Saya pada dasarnya suka bahasa pemrograman. Tanpa tugas tertentu. Saya suka bahasa pemrograman sebagai ide. Beberapa orang berpikir: “Ada serangkaian masalah, mereka dapat digabungkan dan diselesaikan sekaligus. Mari kita membuat bahasa untuk ini. " Dia akan memecahkan daftar masalah tertentu. Dan bahasa lain akan memecahkan masalah lain, karena biasanya semua masalah tidak bisa diselesaikan sekaligus.
Saya benar-benar suka melihat masalah apa yang dipecahkan oleh setiap bahasa dan mengapa hal itu perlu dilakukan dalam praktik. Bahasa itu sendiri menjadi objek seni intelektual bagi saya. Sejumlah besar orang bekerja, berpikir, dirancang, dioptimalkan. Ini sangat menarik, jadi saya mengikuti banyak bahasa pemrograman.
Bahasa-bahasa yang saya pilih untuk laporan memiliki beberapa karakteristik menarik. Pertama, mereka kontroversial. Tak satu pun dari mereka adalah bahasa yang pada akhirnya baik dalam segala hal dalam kesadaran komunitas.
Semua orang tahu bahwa Python lambat, tetapi masih bahasa yang paling populer, digunakan di mana-mana. Saya akan mencoba menjelaskan mengapa itu digunakan.
Dan berbicara tentang Ruby, hal pertama yang orang katakan adalah Ruby sudah mati. Faktanya, pengembang Ruby sekarang lebih dari pada bahasa lain apa pun mengganggu arsitektur dan mengimplementasikan sejumlah besar ide dari bahasa lain - fungsional, berorientasi objek dan membuat sesuatu yang sangat menarik darinya.
Jika kita berbicara tentang Go, maka Go memiliki cakupan penerapan yang sangat sempit, tetapi setelah hype, semua orang mulai menulis tentang itu.
Setiap bahasa yang saya pilih untuk diwakili selama pidato memiliki beberapa jenis konflik.
Sebagai karakter dalam cerita yang bagus. Dan inti dari konflik adalah bahwa beberapa hal bekerja dengan baik, dan beberapa tidak. Konflik ini akan menjadi kepala laporan.
- Apakah Anda pikir Anda perlu memilih bahasa Anda untuk setiap tugas, proyek?Ini adalah ide yang bagus, tetapi tidak berhasil dalam praktiknya. Tepat di mana kita mulai. Ada pemrogram Android, ada pemrogram Python yang, ketika Anda menunjukkan kepada mereka kode Ruby, yang merupakan hal yang sama, hanya dalam profil, mereka berkata: "Oh tidak, semuanya tidak bisa dimengerti, saya tidak ingin mengerti".
Tentu saja, saya ingin orang lebih fleksibel dan dapat memilih instrumen untuk tugas itu, tetapi ternyata orang tahu satu hal dan selalu mengambil alat ini.
Faktor perekrutan juga ditambahkan di sini. Misalnya, di perusahaan kami, kami tidak dapat memilih dari TypeScript dan Python. Tetapi, jika saya perlu menyewa pengembang Elixir, saya akan mencarinya sepanjang hidup saya. Saya tahu pengembang seperti itu, tetapi tidak begitu banyak, dan tidak begitu sehingga saya dapat dengan cepat memikat mereka kepada saya. Oleh karena itu, Anda harus memoderasi ambisi dan beradaptasi dengan pasar dan pelanggan, yang juga memiliki tumpukan terbatas sesuai dengan pasar.
- Anda menjanjikan tampilan subjektif di hampir 10 bahasa yang sama sekali berbeda. Apakah Anda benar-benar akrab dengan mereka semua, apakah Anda menulis sesuatu pada mereka semua?Dengan masing-masing dengan cara yang berbeda, tetapi, tentu saja, saya mencoba semuanya setidaknya sampai batas tertentu.
Sebagai contoh, pada Rust saya menulis open source, dan pada pony saya menulis 15 baris kode, membaca tutorial, mengagumi, dan sekarang saya ingin menunjukkan kepada peserta konferensi. Sehingga mereka pun terinspirasi oleh ide tersebut.
- Jelas, dalam satu laporan Anda tidak akan dapat memberikan gambaran lengkap dan pemahaman masing-masing bahasa. Mengapa orang harus membuka laporan Anda dan tidak mencari di google?Alasannya adalah bahwa ketika orang yang hidup memberi tahu Anda, itu sama sekali berbeda. Laporan sampai taraf tertentu selalu menunjukkan. Ketika orang datang ke pertunjukan, mereka tidak hanya menerima konten, tetapi juga emosi. Saat Anda google, Anda hanya mendapatkan konten. Jika Anda tertarik, Anda tetap akan mencari Google. Dan format ucapan orang yang hidup memungkinkan secara populer dan mudah untuk mendapatkan pengetahuan yang menarik.
- Apa yang akan menjadi elemen utama dari "pertunjukan" Anda?Ada banyak bahasa, semuanya keren, tetapi tidak ada yang bisa ditulis.
Ada banyak bahasa populer untuk menyelesaikan masalah bisnis Anda: perekrutan, pelanggan, perpustakaan. Tetapi mereka semua menjadi populer karena suatu alasan. Sebagai aturan, alasan utamanya adalah mereka sangat sederhana. Mereka didasarkan pada konsep-konsep sederhana yang mudah untuk memulai, tetapi sulit untuk melanjutkan.
Ada bahasa khusus, dan konsep kompleks yang sangat menarik sudah muncul di mana Anda dapat membangun sesuatu yang besar dan andal: Karat dengan kompiler yang sangat baik, Elixir dengan mesin virtual yang benar-benar menusuk baju besi, Haskell dengan sistem tipenya, dll. Tetapi mereka tidak dapat menjadi populer hanya karena ambang masuk yang tinggi.
Sebagian besar pengembang yang ingin mempelajari sesuatu menggunakan bahasa populer dan menulis untuk mereka. Dan pertanyaan mengapa hal lain mungkin diperlukan tidak muncul, karena dalam proyek-proyek yang mereka kerjakan, tidak ada yang lebih rumit yang diperlukan.
Sangat penting bagi pengembang untuk memahami keterbatasan alat ini.
Untuk memahami batasannya, Anda harus bersandar pada dahi Anda, melawan masalah, dan kemudian mundur dan melihatnya dari kejauhan. Hanya dalam laporan orang yang telah bekerja dengan sesuatu selama bertahun-tahun, hal ini memanifestasikan dirinya. Dan saya kenal baik dengan orang-orang ini, saya telah mengumpulkan berbagai kasus dan saya tahu harus beristirahat di mana. Dan saya bisa merangkum pengalaman saya dan pengalaman orang lain.
- Menulis "Halo dunia" di Haskell sudah merupakan prestasi besar, tetapi apakah itu tidak cukup?Ya, Anda harus mendidih di komunitas fungsionaris. Untuk mendengarkan masalah apa yang mereka selesaikan, laporan apa yang mereka buat - sehingga Anda dapat memahami bagian tersebut.
Misalnya, di komunitas Haskellist, masalah entri sangat akut. Mereka masih tidak bisa menyelesaikannya dan membuat bahasa mereka lebih ramah bagi para pemula. Secara historis, Haskell menggunakan sintaks yang sama sekali berbeda dan aturan yang sama sekali berbeda, hanya untuk menulis setidaknya sesuatu. Bahkan pengembang yang berpengalaman pada awalnya akan sepenuhnya tidak jelas apa yang terjadi dalam kode ini.
Dan masalahnya bukan hanya dalam pemrograman fungsional. Jika Anda mulai berkenalan dengan fungsionalitas dengan Elixir, itu akan jauh lebih mudah. Elixir sangat mirip dalam sintaksisnya dengan Ruby. Pada awalnya, Anda tidak akan melihat perbedaannya, Anda dapat menulis dengan cara yang sama seperti di Ruby. Dan baru kemudian menjadi jelas bahwa ini adalah bahasa fungsional. Anda tidak memperhatikan hal ini sampai titik tertentu, dan kemudian Anda menemukan peluang tambahan untuk diri Anda sendiri. Anda mengerti bahwa sebenarnya itu dibangun di atas prinsip yang sama sekali berbeda. Mengetahui dasar ini, menjadi mudah untuk beralih ke bahasa fungsional yang kurang ramah.
Ketertiban itu penting.
- Selain bahasa populer dan bahasa, seperti yang Anda katakan, dari seri kedua, yang setidaknya sampai batas tertentu terdengar, Anda akan memperkenalkan yang sama sekali tidak dikenal. Misalnya, kuda apa ini?Pony adalah bahasa pemrograman open-source, berorientasi objek, aktor-model, kemampuan-aman, kinerja tinggi. Yaitu, sangat diketik, memori aman, bahasa aktor. Dia sangat muda dan sangat menarik.
Pengembangnya membuat bahasa tempat Anda dapat membuat aktor dalam jumlah yang sangat besar, seperti pada Elixir, tetapi aktor ini dijamin aman untuk jenisnya. Batas penerapan bahasa ini masih sepenuhnya tidak dapat dipahami. Tetapi saya akan mengatakan bahwa dia dapat menekan Go, dan saya secara aktif mendukung semua yang dapat menekan Go.
- Jika semua bahasa memiliki kekurangan dan keterbatasan, apa yang harus dilakukan? Apa yang harus dilakukan?Untuk menderita. Dan terus mencari keunggulan teknis. Ini adalah impian yang tidak mungkin dicapai oleh insinyur mana pun, tetapi proses menemukan keunggulan ini adalah tujuan yang hebat.
Saint AppsConf setelah 10 hari. Komite Program memilih 35 laporan dan 12 pertemuan, di antaranya setiap pengembang ponsel akan menemukan gagasan yang berguna untuk memecahkan masalah sehari-hari dan untuk pengembangan profesional dan pribadi mereka. Saya akan bertemu Anda pada 21 dan 22 Oktober di St. Petersburg!
Pertanyaan bonus bagi mereka yang ingin berbagi pengalaman, tetapi karena alasan tertentu belum menjadi pembicara. Anda sering berbicara, mengapa Anda membutuhkannya dan apa yang memotivasi Anda?Saya memiliki tiga tujuan:
- Selamat bersenang-senang, saya sangat suka konferensi, menyenangkan dan menarik.
- Lokal - temukan pengembang dan pelanggan.
- Global - untuk membuat industri kami lebih baik . Saya melihat banyak masalah dan saya ingin memengaruhi secara positif dan membuat yang baik dari yang buruk.
Seorang pembicara di sebuah konferensi dapat memengaruhi suatu industri melalui audiens. Dia dari mimbar dapat membuktikan sudut pandangnya dan memotivasi orang untuk berubah.