Selamat datang di episode lain dari kumpulan pengetahuan Microsoft di M365FM Setiap bawa jalan dan merupakan itu Topik hari ini adalah topik yang hampir semua orang pernah dengar Tetapi hanya sedikit yang benar-benar memahaminya Yaitu rekayasa platform Anda mungkin pernah mendengar tentang DevOps Gagasan bahwa pengembang dan tim operasi bekerja sama dengan lancar Tetapi di suatu tempat, di sepanjang jalan, janji-janji itu menjadi kaca Pengembang akhirnya melakukan pekerjaan operasi sistem itu rusak Di akhir episode ini, Anda akan memahami apa yang salah dengan DevOps Apa sebenarnya platform pengembang internal itu Bagaimana jalur emas memberi tim jalan yang jelas untuk diikuti Dan mengapa tim teknik terpintar sudah membangunnya Kekacauan yang ditinggalkan DevOps Mari kita kembali ke awal mulai DevOps adalah ide hebat dengan tujuan sederhana Meruntukkan tembok antara pengembang dan operasi Tidak perlu lagi melemparkan kode ke dinding dan berharap yang terbaik Geser ke kiri, pindahkan pengujian, keamanan, dan operasi lebih awal dalam proses Pengiriman lebih cepat, lebih sedikit serah terima, lebih banyak kepemilikan Di atas kertas itu tampak sembur Dalam prakteknya ada yang salah Ship ke kiri, tidak hanya mengalihkan tanggung jawab Tetapi juga menumpuknya Pengembang yang dulus kode dan mengajukan tiket kini memiliki infrastruktur keamanan Pemantauan, Kubernetes, jalur CIPR-CD, manajemen rahasia Dan sekitar 15 layanan cloud yang belum pernah mereka dengar sebelumnya Satu orang menangani semua itu sambil tetap membangun produk yang sebenarnya Beginilah tampilannya dalam kehidupan nyata Sebuah tim ingin membuat lingkungan baru untuk menguji suatu fitur Sebelum DevOps, mereka mengajukan tiket denung Setelah DevOps, mereka memilikinya sendiri Yang kedengarannya bagus secara teori Tetapi sekarang mereka perlu menulis modul transform Mengonfigurasi kluster Kubernetes, menyiapkan aturan jaringan Memasang pemantauan, mencari tahu manajemen rahasia Dan memastikan kebijakan keamanan diterapkan Apa yang dulunya merupakan tiket yang memakan waktu satu jam bagi orang lain Kini memakan waktu tiga hari bagi pengam Selama tiga hari mereka tidak menulis kode produk Mereka menangani file YAML Dan mendebak mengapa load balancer tidak merutekan lalu lintas dengan benak Keban mentalis ini sangat besar Setiap tim akhirnya membangun alur kerja, skrip penerapan, dan dashboard pemantauan mereka sendiri Dan karena semua orang kewalahan sudut-sudutnya terpotong Keamanan dilewati karena tengkat waktunya adalah hari Jumat Tagihan cloud berlipat ganda tanpa ada yang menyadarinya Karena tidak ada yang ingat untuk mematikan lingkungan pengujian Dan ketika sesuatu rusak pada pukul 2 pagi Pengembang yang membangunnya adalah satu-satunya yang dapat memperbaiki Ini tidak berkelanjutan Dan inilah mengapa hal ini menjadi lebih penting dari sebelumnya Kompleksitas cloud terus berkembang Setiap tahun ada lebih banyak layanan, lebih banyak alat, lebih banyak keputusan yang harus diambil Dan sekarang alat pengkodean AI memungkinkan pengembang mengirimkan kode lebih cepat dari sebelumnya 10, 20, bahkan 30 kali lebih banyak kode per hari Banyak kode per hari Namun semua kode itu masih merupakan infrastruktur keamanan dan pemantauan Lebih banyak kode tanpa sistem yang lebih baik hanya berarti kekacauan yang lebih cepat Jika Anda merasa tenggelam dalam YAML dan Terraform, Anda tidak sendirian Ini bukan kegagalan pribadi Ini sistem ini Model tersebut merusak apa sebenarnya rekayasa platform itu Lebih perbaikan Ini disebut rekayasa platform dan berikut cara paling sederhana untuk memahaminya Disiplin ini menciptakan lapisan internal yang menyerap kompleksitas bagi para pengembang Bayangkan berjalan ke gedung perkantaran besar Anda tidak perlu khawatir tentang siapa yang memiliki akses ke lantai mana Rencana keamanan mana yang berfungsi atau di mana pintu keluar darurat berada Meja resepsionis menangani semua itu untuk Anda dan Anda tinggal masuk dan mulai bekerja Itulah tepatnya yang dilakukan rekayasa platform untuk para pengembang Daripada setiap pengembang harus menjadi ahli dalam Kubernetes, Terraform, jaringan, dan keamanan tim platform pusat Menciptakan lapisan yang mengelola semua kompleksitas itu Pengembang mendapatkan antarmuka yang sederhana Mengklik tombol, menjalankan perintah, mengisi formulir, dan platform akan mengurus semuanya Namun, ini tidak sama dengan DevOps DevOps memberitahu setiap tim untuk memiliki infrastruktur mereka sendiri Tetapi rekayasa platform mengatakan bahwa itu adalah sebetulnya Sebaliknya, tim platform menyediakan jalan beraspal Cara yang standar, teruji, dan aman untuk menangani tugas-tugas umum Mereka membangun dan memelihara jalan sementara tim produk hanya mengendari Hasil inti dari rekayasa platform adalah sesuatu yang disebut platform pengembang internal Atau disingkat EDP Anggap saja sebagai sistem layanan mandiri yang mengotomatiskan semua pekerjaan berulang itu Penyediaan infrastruktur, aloci IPCD, pemeriksaan keamanan, pemantauan Semuanya sudah terpasang dan terstandarisasi Berikut contoh konkret Ketika pengembang ingin menerapkan layanan baru tanpa platform Mereka akan menghabiskan waktu berhari-hari untuk menyiapkan infrastruktur, menulis alur, dan mengonfigurasi pemeriksaan Dengan IDP, mereka cukup mengeklik terapkan di UI atau menjalankan satu perintah Dan platform akan menangani semuanya Penyediaan, pengujian, pemantauan, penerapan semuanya dalam hitungan menit, bukan hari Apa dinyanyi bagiannya?

Anda berhenti menjadi ahli dalam semua infrastruktur Dan mulai menjadi spesialis dalam produk Anda yang sebenarnya Pekerjaan Anda kembali ke membangun fitur yang penting bagi pelanggan Anda Bukan mendebak mengapa file status trafom Anda rusak, setelah intinya Platform pengembang internal dalam bahasa yang disederhan Jadi mari kita uraikan apa sebenarnya platform pengembang internal itu Ini yang menggabungkan semuanya menjadi satu sistem Pipeline CI, per CD, tempat infrastruktur, kebijakan keamanan, pemantauan, dan pencatatan Alih-alih enam alat terpisah Anda harus menyambungkannya bersama Udah analoginya Anggap saja seperti memasak dari awal dibandingkan menggunakan mesin penjual otomansi Memasak dari awal berarti membeli bahan, memotong sayuran, mengukur bumbu, memantau kompor, por Banyak keputusan, banyak langkah, banyak cara untuk mengacaukan Mesin penjual otomatis memberi Anda hasil dengan menekan satu tombol Lebih sedikit keputusan, hasil lebih cepat, kualitas konsisten IDP adalah mesin penjual otomatis Pengembang tidak perlu tahu bagaimana infrastruktur disediakan atau di mana rahasia disimpan Mereka cukup menekan tombol Apa yang ada dalam mesin penjual otomatis?

Pembuatan intinya cukup standar Tempat CI, per CD untuk pembuatan yang konsisten Penyediaan infrastruktur untuk lingkungan otomatis Yang memutar rahasia sehingga kredensial tidak mengambang di file konfigurasi Dan pencatatan dengan kemampuan observasi bawaan sehingga Anda dapat memecahkan masalah tanpa mengacak-acak Semuanya telah dikonfigurasi sebelumnya, diuji dan dipelihara oleh tim platform Berikut contoh konkretnya Pengembang mengetik buat layanan baru ke dalam baris perintah atau mengeklik tombol di portal Di balik layar, IDP menjalankan repository baru dengan struktur yang tepat Menyiapkan alur pembangunan yang menjalankan pengujian secara otomatis Menyebarkan layanan ke lingkungan pengembangan Dan menambahkan titik akhir pemiksaan kesehatan dengan pencatatan Semua itu terjadi dalam hitungan menit Pengembang tidak pernah menyentuh satu pun berkas teraform atau mengonfigurasi manifest gubernates Cukup mengetik perintah dan layanan pun berjalan Mengapa ini penting?

Konsistensi adalah alasan utama Ketika setiap tim membangun alur mereka sendiri dan menduskrip penyebaran mereka sendiri Anda akan mendapatkan konfigurasi kepingan salju 50 cara berbeda, 50 cara berbeda dan melakukan swat Ketika sesuatu rusak, tidak seorang pun dapat mendebaknya Kecuali orang yang membangun Dan jika orang itu meninggalkan perusahaan, semoga berhasil IDP menghilangkannya dengan membuat setiap layanan mengikuti pola yang sama Setiap penyebaran menggunakan alur yang sama Dan setiap tim mendapatkan default yang sama Ketika sesuatu rusak, polanya sudah familiar dan perbaikannya didokumentasikan Ini adalah artinya bagi Anda Jika organisasi Anda memiliki 50 tim yang melakukan penerbapan dengan 50 cara berbeda IDP adalah solusinya Ini tidak berarti tim kehilangan utama Ini berarti bagian yang membosankan, berulang, dan rawan kesalahan menjadi standar Sehingga pekerjaan yang menarik dan kreatif dapat bervariasi Itu adalah pengorbanan yang layak dilakukan Jalur emas jalannya bukan sangkar Mari kita bahas tentang jalur emas Anda mungkin pernah mendengar namanya, tetapi ide yang sederhana Jalur emas adalah alur kerja yang direkomendasikan dan dibuat sebelumnya Yang membuat sebelumnya membuat hal yang benar menjadi hal yang paling mudah dilakukan Tim platform Anda berkata Begini cara yang kami sarankan untuk Anda lakukan Kami telah mengujinya berhasil dan kami akan mendukung Anda jika terjadi kurus Perhatikan kata rekomendasi itu Jalur emas tidak wajib Pengembang dapat keluar dari jalur jika perlu Tetapi jalur tersebut adalah default yang cepat dan aman Jalur tersebut sudah berjalan, didukung, dan didokumentasikan Anda tidak perlu memikirkan semuanya di awal Anggap saja seperti real kereta api, bukan pagar pembatas Pagar pembatas akan menangkap Anda saat menangkap Mereka bereaksi, mereka menghentikan Anda agar tidak jatuh dari tebing Tetapi mereka tidak membantu Anda Real kereta api memandu Anda dengan mulus di sepanjang rute Jadi Anda tidak perlu memutuskan kemana harus berbeda Jalur emas adalah realnya Mereka membawa Anda maju, bukan hanya menangkap Anda saat menangkap Di sinilah banyak tim melakukan kesalahan ini Mereka membangun jalur emas untuk tim platform, bukan untuk pengembang Mereka mengoptimalkan kemurniaan arsitektur atau kepetuhan keamalan Atau beberapa aturan internal yang tidak dipahami oleh siapapun di luar tim platform Hasilnya tampak bagus di papan tulis, tetapi terasa buruk untuk digunakan Pengembang diam-diam menemukan solusi, adopsi menurun Dan tim platform bertanya-tanya mengapa tidak ada yang menghargai semua upaya itu Perbaikan sederhana tetapi surjaku Anda memerlukan jalur keluar Jika jalur tidak sesuai dengan kasus penggunaan pengembang Mereka memerlukan jalur keluar Cara untuk mengesampingkan default membuat alur mereka sendiri Atau keluar dari platform sepenuhnya Dan inilah bagian pentingnya Jika mereka keluar itu bukan kegagalan, itu umpan talik Setiap kali pengembang meninggalkan jalur emas Itu memberitahu Anda sesuatu yang gak Entah jalur tersebut kehilangan fitur yang seharusnya ada Atau kasus penggunaan benar-benar tidak seharusnya ada di sana Kedua sinyal itu berharga Jalur emas yang baik dalam praktiknya terlihat seperti ini Sebuah tim ingin menerapkan layanan bagian baru Mereka menggunakan jalur tersebut Jalur tersebut memberi mereka repository template dengan struktur yang tepat Alur CI presidi standar yang telah diuji Pencatatan dan pemantauan bawaan pengembalian Dengan satu klik jika terjadi kesalahan Semua ini hanya membutuhkan waktu beberapa menit Bukan hari dan karena tim platform memelihara jalur tersebut Ketika terjadi kerusakan, mereka memperbaik Pengembang tidak perlu menjadi ahli debugging alur Artinya bagi Anda, lebih sedikit kejut Anda mengirimkan lebih cepat karena jalur tersebut Anda mengirimkan lebih aman Karena keamanan dan pemantauan sudah tertanak Anda mengirimkan dengan percaya diri karena pengembalian hanya satu klik Jalur tersebut ada untuk membantu Anda Bukan untuk menahanan Mengurangi beban kognitif Disinilah hasil yang sebenarnya muncul Ketika platform menangani pekerjaan berat Pengembang benar-benar dapat fokus pada kode Mereka tidak perlu tahu versi Kubernetes mana yang sedang berjalan Mereka tidak perlu memperbarui modul Terraform Setiap kali penyedia cloud mengubah API Mereka cukup menulis fitur Teknisi platform menyerap kompleksitas itu Mereka perlu dilihat pengembang dan apa yang harus tetap disembunyikan Itu adalah pilihan desain yang nyata, bukan sekedar pilihan teknik Ini tentang mencari tahu detail mana yang penting bagi orang yang menggunakan platform Dan mana yang hanya menambah kebisingan Berikut contoh konkretnya Pengembang yang menerapkan layanan baru Tidak peduli dengan ukuran node cluster, jenis instance, atau ambang batas dan skalaan otomatis Mereka peduli dengan apakah layanan mereka berjalan dan seberapa cepat layanan tersebut meresap Jadi platform mengonfigurasikan semua itu berdasarkan tingkat aplikasi Layanan kecil berikut pengaturan yang tepat Layanan dengan lalu lintas tinggi berikut konfigurasi yang berduk Pengembang tidak membuat pilihan tersebut karena mereka tidak perlu melakukan Mengabendi penting Karena kelelahan berkurang saat pengembang tidak menangani 15 masalah yang berbeda sekaligus Beberapa tim platform yang matang telah memangkas beban kognitif hingga hampir setengahnya Beban mental berkurang 40 hingga 50% Itu perubahan yang sangat besar Itulah perbedaan antara meninggalkan pekerjaan dengan energi yang tersisa dan menatap terminal pada pukul 10 malam Sambil bertanya-tanya mengapa peplanya Namun ilah peringatan Jangan menciptakan ilusi Beberapa tim platform terjebak Mereka menyembunyikan pengaturan tanpa memberi pengembang cara apapun untuk memahami apa yang terjadi di balik layar Itu bukan abstraksi, itu tipuan Dan itu menjadi bumerang saat terjadi kesalahan Pengembang menabrak tembok yang tidak dapat mereka lihat dan tiba-tiba platform terasa seperti kotak hitam yang bekerja melawan mereka Istilah untuk ini adalah abstraksi yang bocor Anda menyembunyikan kompleksitas tetapi pada akhirnya kompleks itu Basis data menjadi lambat Penerapan gagal, kebijakan keamanan memblokir sesuatu yang tidak terduga Dan pengembang tidak memiliki moda mental tentang apa yang terjadi karena platform tidak pernah merikannya kepada mereka Transparansi itu penting Tunjukkan kepada pengembang apa yang perlu mereka ketahui saat mereka perlu mengetahui Jangan hanya menyembunyikan semuanya dan berharap yang terbaik Artinya bagi Anda, lebih sedikit peralian konteks dan lebih banyak status alam Anda tidak memulai pagi dengan bertanya-tanya apakah kluster Kubernetes perlu ditingkatkan Anda memulai pagi dengan mengerjakan fitur yang harus diselesaikan fitur Pekerjaan Anda yang sebenarnya lagi Memperlakukan platform seperti sebuah produk Hari ini kita akan membahas sesuatu yang mengubah cara kerja alat internal Kebanyakan orang mengira tim platform hanyalah tim infrastruktur Padahal tidak, tim platform adalah tim produk Dan pengembang yang menggunakan platform tersebut adalah pelanggan mereka Bukan orang yang mengajukan tim Itu mengubah segalanya Tim produk berbicara dengan pelanggannya Mereka mencari tahu apa yang sebenarnya menyusahkan Mereka memprioritaskan fitur berdasarkan kebutuhan nyata Mereka mengukur adopsi Mereka tidak mengukur adopsi Mereka tidak membangun sesuatu yang pergi Mereka terus melakukan iterasi Jadi seperti apa tim produk dalam prakteknya?

Mereka tidak beroperasi seperti menjaman Pengembang mengajukan tiket Dan tim platform melakukannya secara manual Itu bukan rekayasa platform, itu hanya operasi terpusat dengan nama baru Itu tidak berskala, tidak mengurangi beban kognitif Itu hanya memindahkan hambatan dari satu tim ke tim lain Inilah yang mereka lakukan sebagai ganti Mereka mengukur hal yang benar Saatnya untuk penerapan pertama Kecepatan orientasi untuk anggota tim baru Skor kepuasan pengembang Ini adalah metrik yang memberitahu Anda Apakah platform tersebut benar-benar membantu orang Atau hanya melambat lapisan kompleksitas Spotify yang bagus Tim platform mereka berjalan seperti organisasi produk yang tepat Mereka memiliki peta jalan Mereka memiliki OKR Mereka berbicara dengan pengembang tentang apa yang berfungsi dan apa yang tidak Mereka memperlakukan platform sebagai sesuatu yang harus mendapatkan adopsi setiap hari Dan itulah ide utamanya Platform yang tidak digunakan siapapun Hanyalah sebuah proyek yang hanya mengumpulkan debu di sudut Adopsi adalah validasi utama Jika pengembang memilih platform Anda Daripada membangun alat mereka sendiri Anda telah berhasil Jika mereka menghindarinya Tidak ada keunggulan teknis yang dapat memperbaikinya Apa artinya ini bagi Anda Artinya jika Anda membangun platform Jangan mulai dengan diagram arsitektur Jangan mulai dengan kluster gubernete atau modul platform Mulailah dengan wawancara pengguna Bicaralah dengan pengembang yang akan menggunakan platform Anda Cari tahu apa yang sebenarnya menyakitkan Bangun satu hal yang membecahkan masalah nyata Lalu ulangi Begitulah cara Anda membangun sesuatu yang benar-benar ingin menggunakan orang Mengapa sekarang Gelombang AI Jadi mengapa kita membicarakan hal ini sekarang Mengapa tidak lima tahun yang lalu Jawabannya adalah AI Alat pengkodean AI seperti GitHub Copilot Memungkinkan pengembang mengirimkan kode dengan kecepatan Yang belum pernah kita lihat sebelumnya 10 kali 20 kali lebih banyak kode per hari Daripada yang mungkin dilakukan beberapa tahun yang lalu Kedengarannya luar biasa dan memang begitu Namun ilah masalahnya Semua kode itu masih membutuhkan infrastruktur Masih membutuhkan keamanan Masih perlu disebarkan, diuji, dan dioperasikan Lebih banyak kode tanpa sistem yang lebih baik Tidak akan membuat Anda lebih cepat Itu hanya akan mempercepat kekacauan Jika pengembang Anda sudah tenggelam dalam YAML dan Terraform AI Tidak akan memperbaikinya Itu hanya berarti mereka tenggelam lebih cepat Sambil menghasilkan lebih banyak kode yang perlu didukung Saat ini Sekitar 55 persen organisasi telah mengadopsi rekayasa platform Dalam beberapa bentuk Gartner memperkirakan angka itu akan mencapai 80 persen Pada akhir tahun 2026 Itu bukanlah tren yang lambat Itu adalah perubahan yang sedang terjadi saat ini Perusahaan menyadari bahwa mereka tidak dapat meningkatkan tim teknik mereka tanpa lapisan platform Pendekatan lama yang mengharuskan setiap tim melakukan semuanya sendiri Tidak akan berhasil jika Anda mengirimkan kode dengan kecepatan AI Inilah yang banyak orang lewatkan AI tidak hanya menciptakan kebutuhan akan platform AI juga membantu membangun Tim platform menggunakan AI untuk menghasilkan modul Terraform Menulis dokumentasi Dan mendebak alur kerja Teknologi yang sama Yang menciptakan urgensi juga menyediakan alat untuk menyelesaikannya Sekarang perlu diingat AI memperkuat apapun yang sudah Anda miliki Jika dasar-dasar Anda kokoh, seperti arsitektur yang baik dan platform yang dirancang dengan baik AI membuat Anda dua hingga tiga kali lebih produktif Namun jika fondasi Anda lemah, AI hanya membantu Anda lebih cepat Kesar dengan lebih cepat Konfigurasi yang buruk, celah keamanan, infrastruktur yang rusak Semuanya dikirim ke produksi sebelum ada yang menyadari AI tidak memperbaiki fondasi yang buruk AI mengeksposnya Berikut contoh nyata Perusahaan dengan platform pengembang internal yang baik Dapat membiarkan non-insinyur menyebarkan alat AI dengan Anda Platform menyedakan pekerja pembatas AI menegakkan kebijakan keamanan AI menangani infrastruktur Jadi seorang manajer produk dapat membuat prototipe bertenaga AI Tanpa perlu memahami kubernetes atau jaringan cloud Itu hebat Itulah hal yang membedakan tim yang siap menghadapi era AI dari tim Yang akan tertinggal Artinya ini bagi Anda Jendela untuk membangun platform semakin tertutup Bukan karena teknologinya menghilang Tetapi karena kesenjangan antara tim yang memiliki platform Dan tim yang tidak memilikinya semakin melebar Setiap bulan Anda menunggu Tim yang sudah memiliki platform semakin maju Mereka mengirimkan lebih cepat tidak terlalu kelelahan Dan beradaptasi dengan alat baru dengan lebih cepat Tim yang tidak memiliki platform semakin tertinggal Pilih Anda di tangan Anda Mulailah dengan satu jalur emas Jadi dari mana Anda sebenarnya memulai?

Jika Anda berpikir bahwa Anda perlu membangun seluruh platform pengembang internal dari awal Berhentilah Itulah cara tercepat untuk menghentikan proyek Anda bahkan sebelum dimulai Salah terbesar yang dilakukan tim adalah mencoba membangun semuanya sekaligus Mereka menghabiskan waktu berbulan-bulan untuk merancang platform yang sempurna Mengemas setiap fitur yang dapat mereka pikir Kemudian mereka meluncurkannya dan tidak menyerap Tidak ada yang menggunakannya Mengapa? Karena ini memecahkan masalah yang tidak ditanyakan siapapun Dan untuk memulainya saja Anda perlu membaca manual singkat Begini, jangan lakukan itu Sebaliknya melihat yang kecil Bicaralah dengan pengembang Bukan arsitek, bukan manajer, bukan asumsi Anda sendiri Temukan orang-orang yang menulis fitur setiap hari Banyakan pada mereka di mana-mana Temukan satu alur kerja memakan waktu paling lama Membuat sebagian besar orang frustrasi atau lebih sering dilewati yang seharusnya Lalu, buatlah satu jalur emas untuk menyelesaikannya Mungkin buat dan terapkan layanan mikro baru Mungkin siapkan lingkungan pengembangan dari awal Mungkin kirimkan perbaikan terbaru ke produksi Tanpa merusak apapun Pilih yang paling menyakitkan dan buat jalur yang menghilangkan kendala itu Buat uji dengan pengguna sungguhan Kumpulkan umpan balik, ulangi Lalu tambahkan jalur lain dan jalur lain setelah itu Jangan mencoba menyelesaikan setiap masalah sekaligus Selesaikan satu masalah dengan sangat baik Dan biarkan momentum membawa Anda maju Bagaimana Anda tahu itu berhasil?

Ukur hal yang tepat Waktu dari ide hingga penerapan pertama Jumlah langkah manual yang telah Anda hilangkan Dan tingkat adopsi sukarela Jika pengembang memilih jalur Anda Daripada membangun jalur mereka sendiri, Anda menang Jika mereka menghindarinya, dengarkan dan ubah arah Inilah jebakan yang harus di Jangan jadikan platform sebagai sebuah yang wajib Paksa pengembang untuk mengikuti jalur Anda Dan mereka akan membencinya Mereka menemukan cara untuk menghilang Mereka membuat skrip mereka sendiri dan menyembunyikan jadinya Sebaliknya, buatlah jalur yang mudah Jadikan lebih cepat daripada alternatifnya Jadikan itu pilihan yang jelas Tetapi jangan pernah menjadi satu-satunya Jalur pertama selalu yang tersulit Jalur ini mengajarkan Anda segala hal tentang pemikiran Anda belajar cara berbicara dengan pengguna Cara memprioritaskan Dan bahwa membangun sesuatu yang benar-benar diinginkan Orang jauh lebih sulit daripada memperfungsi Namun setelah Anda melakukannya sekali Jalur kedua menjadi lebih mudah lagi Dan yang ketiga lebih mudah Anda tidak membangun platform dalam satu kesempatan Anda membangunnya satu jalur pada satu waktu Jadi itulah sistemnya Rekayasa platform adalah tentang membangun jalan beraspal Sehingga pengembang dapat fokus pada mengundi alih-alih memperbaiki lo Jika Anda lelah melawan infrastruktur Mulailah dengan menemukan satu jalan emas di tim Anda Hanya satu Bagikan ini dengan seseorang yang perlu mendengarnya Dan berlangganan untuk lebih banyak uraian seperti ini