Cara Menghindari Kutukan Optimasi Dini

Ini hampir layak jaminan, sungguh. Dari pemula hingga ahli, dari arsitektur hingga ASM, dan mengoptimalkan apa pun mulai dari kinerja mesin hingga kinerja pengembang, kemungkinan besar Anda dan tim Anda gagal mencapai tujuan Anda sendiri.

Apa? Aku? tim saya ?

Itu tuduhan yang cukup kuat untuk diratakan. Mari saya jelaskan.

Optimalisasi bukanlah cawan suci, tetapi bisa sama sulitnya untuk diperoleh. Saya ingin berbagi dengan Anda beberapa tip sederhana (dan segunung perangkap) untuk membantu mengubah pengalaman tim Anda dari salah satu sabotase diri menjadi salah satu harmoni, pemenuhan, keseimbangan, dan, akhirnya, pengoptimalan.

Apa itu Optimasi Prematur?

Pengoptimalan prematur mencoba mengoptimalkan kinerja:

1. Saat pertama kali mengkodekan suatu algoritma
2. Sebelum tolok ukur mengonfirmasi, Anda perlu
3. Sebelum membuat profil, tentukan di mana masuk akal untuk repot mengoptimalkan
4. Pada tingkat yang lebih rendah dari yang ditentukan oleh proyek Anda saat ini

Sekarang, saya seorang optimis, Optimus.

Setidaknya, saya akan berpura-pura optimis saat menulis artikel ini. Untuk bagian Anda, Anda dapat berpura-pura nama Anda Optimus, jadi ini akan berbicara lebih langsung kepada Anda.

Sebagai seseorang di bidang teknologi, Anda mungkin terkadang bertanya-tanya bagaimana mungkin $year , namun, terlepas dari semua kemajuan kami, entah bagaimana standar yang dapat diterima untuk $task menjadi sangat memakan waktu. Anda ingin kurus. Efisien. Luar biasa. Seseorang seperti Pemrogram Rockstar yang dituntut oleh lowongan pekerjaan itu, tetapi dengan pemimpin. Jadi ketika tim Anda menulis kode, Anda mendorong mereka untuk melakukannya dengan benar pertama kali (bahkan jika "benar" adalah istilah yang sangat relatif, di sini). Mereka tahu itu cara Para Coder yang Pintar, dan juga cara Mereka yang Tidak Perlu Membuang Waktu Refactoring Nanti.

Aku merasakannya. Kekuatan perfeksionisme terkadang juga kuat dalam diri saya. Anda ingin tim Anda meluangkan sedikit waktu sekarang untuk menghemat banyak waktu nanti, karena semua orang bekerja keras melalui bagian mereka dari "Kode Buruk yang Ditulis Orang Lain (Apa yang Mereka Pikirkan?)." Itu SCOPWWHWTT singkatnya, karena saya tahu Anda menyukai akronim yang tidak dapat diucapkan.

Saya juga tahu Anda tidak ingin kode tim Anda menjadi kode untuk diri mereka sendiri atau orang lain.

Jadi mari kita lihat apa yang bisa dilakukan untuk membimbing tim Anda ke arah yang benar.

Apa yang Harus Dioptimalkan: Selamat Datang di This Being an Art

Pertama-tama, ketika kita memikirkan pengoptimalan program, seringkali kita langsung berasumsi bahwa kita sedang berbicara tentang kinerja. Bahkan itu sudah lebih kabur daripada kelihatannya (kecepatan? penggunaan memori? dll.) jadi mari kita berhenti di situ.

Mari kita membuatnya lebih ambigu! Hanya pada awalnya.

Otak jaring laba-laba saya suka membuat keteraturan jika memungkinkan, jadi dibutuhkan setiap ons optimisme bagi saya untuk mempertimbangkan apa yang akan saya katakan sebagai hal yang baik .

Ada aturan sederhana optimasi (kinerja) di luar sana yang berbunyi Jangan lakukan itu . Ini terdengar cukup mudah untuk diikuti secara kaku tetapi tidak semua orang setuju dengannya. Saya juga tidak sepenuhnya setuju. Beberapa orang hanya akan menulis kode yang lebih baik daripada yang lain. Mudah-mudahan, untuk setiap orang, kualitas kode yang akan mereka tulis dalam proyek baru umumnya akan meningkat seiring waktu. Tapi saya tahu bahwa, bagi banyak programmer, hal ini tidak akan terjadi, karena semakin banyak mereka tahu, semakin banyak cara mereka akan tergoda untuk melakukan pengoptimalan sebelum waktunya.

Bagi banyak programmer… semakin banyak yang mereka ketahui, semakin banyak cara mereka akan tergoda untuk melakukan pengoptimalan sebelum waktunya.

Jadi ini Jangan lakukan itu tidak bisa menjadi ilmu pasti tetapi hanya dimaksudkan untuk melawan dorongan batin khas teknisi untuk memecahkan teka-teki. Bagaimanapun, inilah yang menarik banyak programmer untuk kerajinan itu. Saya mengerti. Tetapi mintalah mereka untuk menyimpannya , untuk menahan godaan. Jika seseorang membutuhkan outlet pemecahan teka-teki sekarang , dia selalu dapat mencoba-coba Sudoku koran Minggu, atau mengambil buku Mensa, atau bermain golf kode dengan beberapa masalah buatan. Tapi biarkan keluar dari repo sampai waktu yang tepat. Hampir selalu ini adalah jalan yang lebih bijaksana daripada pra-optimasi.

Ingat, praktik ini cukup terkenal sehingga orang bertanya apakah optimasi prematur adalah akar dari semua kejahatan. (Saya tidak akan melangkah sejauh itu, tetapi saya setuju dengan sentimen tersebut.)

Saya tidak mengatakan kita harus memilih cara yang paling mematikan otak yang bisa kita pikirkan di setiap tingkat desain. Tentu saja tidak. Tetapi alih-alih memilih yang paling pintar, kita dapat mempertimbangkan nilai-nilai lain:

1. Yang paling mudah untuk dijelaskan kepada karyawan baru Anda
2. Yang paling mungkin lulus tinjauan kode oleh pengembang Anda yang paling berpengalaman
3. Yang paling bisa dipertahankan
4. Yang tercepat untuk menulis
5. Yang paling mudah untuk diuji
6. Yang paling portabel
7. dll.

Tapi di sinilah masalahnya menunjukkan dirinya sulit. Ini bukan hanya tentang menghindari pengoptimalan untuk kecepatan, ukuran kode, jejak memori, fleksibilitas, atau bukti masa depan. Ini tentang keseimbangan dan tentang apakah yang Anda lakukan benar-benar sejalan dengan nilai dan tujuan Anda. Ini sepenuhnya kontekstual, dan terkadang bahkan tidak mungkin diukur secara objektif.

Mengapa ini hal yang baik? Karena hidup memang seperti ini. Ini berantakan. Otak kita yang berorientasi pada pemrograman terkadang sangat ingin menciptakan keteraturan dalam kekacauan sehingga ironisnya kita malah melipatgandakan kekacauan itu. Ini seperti paradoks mencoba memaksa seseorang untuk mencintaimu. Jika Anda pikir Anda telah berhasil dalam hal itu, itu bukan lagi cinta; sementara itu, Anda didakwa dengan penyanderaan, Anda mungkin membutuhkan lebih banyak cinta daripada sebelumnya, dan metafora ini harus menjadi salah satu yang paling canggung yang bisa saya pilih.

Bagaimanapun, jika Anda pikir Anda telah menemukan sistem yang sempurna untuk sesuatu, yah…nikmatilah ilusi selama itu berlangsung, saya kira. Tidak apa-apa, kegagalan adalah kesempatan bagus untuk belajar.

Pertahankan UX dalam Pikiran

Mari kita jelajahi bagaimana pengalaman pengguna cocok di antara prioritas potensial ini. Lagi pula, bahkan menginginkan sesuatu untuk berkinerja baik, pada tingkat tertentu, adalah tentang UX.

Jika Anda sedang mengerjakan UI, apa pun kerangka kerja atau bahasa yang digunakan kode, akan ada sejumlah boilerplate dan pengulangan. Ini pasti bisa berharga dalam hal waktu programmer dan kejelasan kode untuk mencoba menguranginya. Untuk membantu seni menyeimbangkan prioritas, saya ingin berbagi beberapa cerita.

Di satu pekerjaan, perusahaan tempat saya bekerja menggunakan sistem perusahaan sumber tertutup yang didasarkan pada tumpukan teknologi yang berpendirian. Bahkan sangat beropini sehingga vendor yang menjualnya kepada kami menolak melakukan kustomisasi UI yang tidak sesuai dengan opini stack, karena sangat menyakitkan bagi developer mereka. Saya tidak pernah menggunakan tumpukan mereka, jadi saya tidak mengutuk mereka untuk ini, tetapi faktanya adalah bahwa pertukaran "baik untuk programmer, buruk untuk pengguna" ini sangat rumit untuk rekan kerja saya dalam konteks tertentu sehingga saya mengakhiri hingga menulis add-on pihak ketiga yang mengimplementasikan kembali bagian UI sistem ini. (Itu adalah pendorong produktivitas yang sangat besar. Rekan kerja saya menyukainya! Lebih dari satu dekade kemudian, ini masih menghemat waktu dan frustrasi semua orang di sana.)

Saya tidak mengatakan bahwa opini adalah masalah itu sendiri; hanya saja terlalu banyak itu menjadi masalah dalam kasus kami. Sebagai contoh tandingan, salah satu daya tarik besar Ruby on Rails adalah bahwa ia memiliki opini, dalam ekosistem front-end di mana seseorang dengan mudah mendapatkan vertigo karena memiliki terlalu banyak pilihan. (Beri saya sesuatu dengan pendapat sampai saya dapat menemukan pendapat saya sendiri!)

Sebaliknya, Anda mungkin tergoda untuk menobatkan UX sebagai Raja Segalanya dalam proyek Anda. Tujuan yang layak, tetapi izinkan saya menceritakan kisah kedua saya.

Beberapa tahun setelah keberhasilan proyek di atas, salah satu rekan kerja saya datang kepada saya untuk meminta saya untuk mengoptimalkan UX dengan mengotomatisasi skenario kehidupan nyata berantakan tertentu yang kadang-kadang muncul, sehingga dapat diselesaikan dengan satu klik. Saya mulai menganalisis apakah mungkin untuk merancang algoritme yang tidak memiliki positif atau negatif palsu karena banyaknya kasus tepi yang aneh dari skenario tersebut. Semakin saya berbicara dengan rekan kerja saya tentang hal itu, semakin saya menyadari bahwa persyaratan itu tidak akan membuahkan hasil. Skenario itu hanya muncul sesekali—katakanlah setiap bulan—dan saat ini butuh beberapa menit untuk diselesaikan oleh satu orang. Bahkan jika kami berhasil mengotomatiskannya, tanpa bug, akan membutuhkan waktu berabad-abad untuk pengembangan dan waktu pemeliharaan yang diperlukan agar terbayar dalam hal waktu yang dihemat oleh rekan kerja saya. Orang-orang yang menyenangkan dalam diri saya mengalami saat yang sulit untuk mengatakan "tidak", tetapi saya harus memotong pembicaraan.

Jadi biarkan komputer melakukan apa yang bisa dilakukan untuk membantu pengguna, tetapi hanya sampai batas yang wajar. Bagaimana Anda tahu sejauh mana itu?

Pendekatan yang ingin saya ambil adalah membuat profil UX seperti pengembang Anda membuat profil kode mereka. Cari tahu dari pengguna Anda di mana mereka menghabiskan waktu paling banyak untuk mengklik atau mengetik hal yang sama berulang kali, dan lihat apakah Anda dapat mengoptimalkan interaksi tersebut. Bisakah kode Anda membuat beberapa tebakan terpelajar tentang apa yang kemungkinan besar akan mereka masukkan, dan menjadikannya sebagai default tanpa input? Selain dari konteks terlarang tertentu (konfirmasi EULA tanpa klik?), ini benar-benar dapat membuat perbedaan pada produktivitas dan kebahagiaan pengguna Anda. Lakukan beberapa pengujian kegunaan lorong jika Anda bisa. Terkadang, Anda mungkin mengalami kesulitan menjelaskan apa yang mudah dibantu komputer dan apa yang tidak… tetapi secara keseluruhan, nilai ini mungkin sangat penting bagi pengguna Anda.

Menghindari Pengoptimalan Prematur: Kapan dan Bagaimana Mengoptimalkannya

Terlepas dari eksplorasi konteks lain kami, sekarang mari kita asumsikan secara eksplisit bahwa kami mengoptimalkan beberapa aspek kinerja mesin mentah untuk sisa artikel ini. Pendekatan yang saya sarankan juga berlaku untuk target lain, seperti fleksibilitas, tetapi setiap target akan memiliki gotcha sendiri; poin utama adalah bahwa mengoptimalkan sebelum waktunya untuk apa pun mungkin akan gagal.

Jadi, dalam hal kinerja, metode pengoptimalan apa yang harus diikuti? Mari kita menggali.

Ini Bukan Inisiatif Akar Rumput, Ini Triple-Eh

TL;DR adalah: Bekerja dari atas. Pengoptimalan tingkat yang lebih tinggi dapat dilakukan lebih awal dalam proyek, dan tingkat yang lebih rendah harus dibiarkan nanti. Hanya itu yang Anda butuhkan untuk memahami sebagian besar arti dari frasa “optimasi prematur”; melakukan hal-hal di luar urutan ini memiliki kemungkinan besar membuang-buang waktu tim Anda dan menjadi kontra-efektif. Lagi pula, Anda tidak menulis seluruh proyek dalam kode mesin sejak awal, bukan? Jadi modus operandi AAA kami adalah mengoptimalkan dalam urutan ini:

1. Arsitektur
2. algoritma
3. perakitan

Kebijaksanaan umum mengatakan bahwa algoritma dan struktur data seringkali merupakan tempat paling efektif untuk dioptimalkan, setidaknya dalam hal kinerja. Namun, perlu diingat bahwa arsitektur terkadang menentukan algoritme dan struktur data mana yang dapat digunakan sama sekali.

Saya pernah menemukan perangkat lunak yang melakukan laporan keuangan dengan menanyakan database SQL beberapa kali untuk setiap transaksi keuangan, kemudian melakukan perhitungan yang sangat mendasar di sisi klien. Dibutuhkan usaha kecil menggunakan perangkat lunak hanya beberapa bulan penggunaan bahkan sebelum jumlah data keuangan mereka yang relatif kecil berarti bahwa, dengan desktop baru dan server yang cukup gemuk, waktu pembuatan laporan sudah sampai beberapa menit, dan ini salah satu yang mereka butuhkan untuk digunakan cukup sering. Saya akhirnya menulis pernyataan SQL langsung yang berisi logika penjumlahan—menggagalkan arsitektur mereka dengan memindahkan pekerjaan ke server untuk menghindari semua duplikasi dan bolak-balik jaringan—dan bahkan beberapa tahun kemudian, versi saya dapat menghasilkan laporan yang sama hanya dalam milidetik pada perangkat keras lama yang sama.

Terkadang Anda tidak memiliki pengaruh atas arsitektur suatu proyek karena sudah terlambat dalam proyek untuk perubahan arsitektur menjadi layak. Terkadang pengembang Anda dapat menghindarinya seperti yang saya lakukan pada contoh di atas. Tetapi jika Anda berada di awal proyek dan memiliki pendapat tentang arsitekturnya, sekaranglah saatnya untuk mengoptimalkannya.

Arsitektur

Dalam sebuah proyek, arsitektur adalah bagian yang paling mahal untuk diubah setelah fakta, jadi ini adalah tempat di mana masuk akal untuk mengoptimalkan di awal. Jika aplikasi Anda akan mengirimkan data melalui burung unta, misalnya, Anda harus menyusunnya ke paket frekuensi rendah dan muatan tinggi untuk menghindari kemacetan yang lebih buruk. Dalam hal ini, Anda sebaiknya menerapkan Tetris secara penuh untuk menghibur pengguna Anda, karena pemintal pemuatan tidak akan memotongnya. (Selain bercanda: Bertahun-tahun yang lalu saya menginstal distribusi Linux pertama saya, Corel Linux 2.0, dan senang bahwa proses instalasi yang berjalan lama mencakup hal itu. Setelah melihat layar infomersial penginstal Windows 95 berkali-kali sehingga saya telah menghafalnya, ini adalah angin segar pada saat itu.)

Sebagai contoh perubahan arsitektur yang mahal, alasan laporan SQL yang disebutkan di atas menjadi sangat tidak terukur sejak awal jelas dari sejarahnya. Aplikasi telah berevolusi dari waktu ke waktu, dari akarnya di MS-DOS dan basis data kustom yang dikembangkan sendiri yang bahkan awalnya bukan multi-pengguna. Ketika vendor akhirnya beralih ke SQL, skema dan kode pelaporan tampaknya telah di-porting satu per satu. Ini memberi mereka peningkatan kinerja 1.000%+ yang mengesankan selama bertahun-tahun untuk disemprotkan di seluruh pembaruan mereka, setiap kali mereka menyelesaikan peralihan arsitektur dengan benar-benar memanfaatkan keunggulan SQL untuk laporan tertentu. Bagus untuk bisnis dengan klien terkunci seperti majikan saya saat itu, dan jelas berusaha memprioritaskan efisiensi pengkodean selama transisi awal. Tetapi memenuhi kebutuhan klien, dalam beberapa kasus, sama efektifnya dengan palu memutar sekrup.

Arsitektur sebagian adalah tentang mengantisipasi sejauh mana proyek Anda perlu dapat ditingkatkan, dan dengan cara apa. Karena arsitektur adalah tingkat yang sangat tinggi, sulit untuk menjadi konkret dengan "hal yang harus dan tidak boleh dilakukan" kami tanpa mempersempit fokus kami ke teknologi dan domain tertentu.

Saya Tidak Akan Menyebutnya Itu, tetapi Semua Orang Menyebutnya

Untungnya, Internet penuh dengan kebijaksanaan yang dikumpulkan tentang hampir semua jenis arsitektur yang pernah diimpikan. Ketika Anda tahu saatnya untuk mengoptimalkan arsitektur Anda, meneliti jebakan cukup banyak bermuara pada mencari tahu kata kunci yang menggambarkan visi brilian Anda. Kemungkinannya adalah seseorang memiliki pemikiran yang sama dengan Anda, mencobanya, gagal, mengulangi, dan mempublikasikannya di blog atau buku.

Identifikasi kata kunci bisa jadi sulit dilakukan hanya dengan mencari, karena untuk apa yang Anda sebut FLDSMDFR, orang lain telah menciptakan istilah SCOPWWHWTT, dan mereka menggambarkan masalah yang sama yang sedang Anda selesaikan, tetapi menggunakan kosakata yang sama sekali berbeda dari yang Anda lakukan. Komunitas pengembang untuk menyelamatkan! Buka StackExchange atau HashNode dengan deskripsi selengkap mungkin, ditambah semua kata kunci yang tidak dimiliki arsitektur Anda , sehingga mereka tahu Anda melakukan penelitian pendahuluan yang memadai. Seseorang akan dengan senang hati mencerahkan Anda.

Sementara itu, beberapa saran umum mungkin bisa menjadi bahan pemikiran yang baik.

Algoritma dan Majelis

Dengan arsitektur yang kondusif, di sinilah pembuat kode di tim Anda akan mendapatkan hasil maksimal dari waktu mereka. Penghindaran dasar pengoptimalan prematur juga berlaku di sini, tetapi pemrogram Anda sebaiknya mempertimbangkan beberapa hal spesifik pada tingkat ini. Ada banyak hal yang harus dipikirkan terkait detail implementasi sehingga saya menulis artikel terpisah tentang pengoptimalan kode yang ditujukan untuk pembuat kode garis depan dan senior.

Tetapi begitu Anda dan tim Anda telah menerapkan sesuatu yang tidak dioptimalkan untuk kinerja, apakah Anda benar-benar membiarkannya di Jangan lakukan ? Anda tidak pernah mengoptimalkan?

Kamu benar. Aturan selanjutnya adalah, untuk ahli saja, Jangan lakukan dulu .

Saatnya Menjadi Tolok Ukur!

Kode Anda berfungsi. Mungkin sangat lambat sehingga Anda sudah tahu bahwa Anda perlu mengoptimalkan, karena kode itulah yang akan sering dijalankan. Mungkin Anda tidak yakin, atau Anda memiliki algoritme O(n) dan menganggapnya mungkin baik-baik saja. Apa pun masalahnya, jika algoritme ini layak untuk dioptimalkan, rekomendasi saya pada saat ini adalah sama: Jalankan benchmark sederhana.

Mengapa? Bukankah sudah jelas bahwa algoritma O(n³) saya tidak mungkin lebih buruk dari apa pun? Nah, karena dua alasan:

1. Anda dapat menambahkan tolok ukur ke rangkaian pengujian Anda, sebagai ukuran objektif dari sasaran kinerja Anda, terlepas dari apakah saat ini tercapai.
2. Bahkan para ahli dapat secara tidak sengaja membuat segalanya menjadi lebih lambat. Bahkan ketika itu tampak jelas. Benar -benar jelas.

Tidak percaya padaku pada poin kedua itu?

Cara Mendapatkan Hasil Lebih Baik dari Perangkat Keras $1.400 Daripada Perangkat Keras $7.000

Jeff Atwood dari ketenaran StackOverflow pernah menunjukkan bahwa terkadang (biasanya, menurut pendapatnya) lebih hemat biaya untuk hanya membeli perangkat keras yang lebih baik daripada menghabiskan waktu programmer yang berharga untuk pengoptimalan. Oke, jadi anggaplah Anda telah mencapai kesimpulan yang cukup objektif bahwa proyek Anda akan sesuai dengan skenario ini. Mari kita asumsikan lebih lanjut bahwa apa yang Anda coba optimalkan adalah waktu kompilasi, karena ini adalah proyek Swift yang besar dan kuat yang sedang Anda kerjakan, dan ini telah menjadi hambatan pengembang yang agak besar. Waktu belanja perangkat keras!

Apa yang harus Anda beli? Jelas, yen untuk yen, perangkat keras yang lebih mahal cenderung berkinerja lebih baik daripada perangkat keras yang lebih murah. Jadi jelas, Mac Pro seharga $7.000 seharusnya mengkompilasi perangkat lunak Anda lebih cepat daripada Mac Mini kelas menengah, bukan?

Salah!

Ternyata terkadang lebih banyak inti berarti kompilasi yang lebih efisien… dan dalam kasus khusus ini, LinkedIn menemukan cara yang sulit bahwa kebalikannya berlaku untuk tumpukan mereka.

Tetapi saya telah melihat manajemen yang membuat satu kesalahan lebih jauh: Mereka bahkan tidak melakukan benchmark sebelum dan sesudahnya, dan menemukan bahwa peningkatan perangkat keras tidak membuat perangkat lunak mereka "terasa" lebih cepat. Tapi tidak ada cara untuk mengetahui dengan pasti; dan selanjutnya, mereka masih tidak tahu di mana hambatannya, jadi mereka tetap tidak senang dengan kinerja, setelah menghabiskan waktu dan uang yang bersedia mereka alokasikan untuk masalah itu.

Oke, saya sudah melakukan Tolok Ukur. Bisakah Saya Benar-Benar Mengoptimalkan ??

Ya, dengan asumsi Anda telah memutuskan Anda perlu. Tapi mungkin keputusan itu akan menunggu sampai lebih/semua algoritme lain diimplementasikan juga, jadi Anda bisa melihat bagaimana bagian-bagian yang bergerak cocok dan mana yang paling penting melalui pembuatan profil. Ini mungkin pada tingkat aplikasi untuk aplikasi kecil, atau mungkin hanya berlaku untuk satu subsistem. Apa pun itu, ingat, algoritme tertentu mungkin tampak penting bagi keseluruhan aplikasi, tetapi bahkan para ahli—terutama pakar—cenderung salah mendiagnosis ini.

Pikirkan sebelum Anda Mengganggu

“Aku tidak tahu tentang kalian, tapi…”

Sebagai bahan pertimbangan terakhir, pertimbangkan bagaimana Anda dapat menerapkan gagasan pengoptimalan palsu ke pandangan yang jauh lebih luas: proyek atau perusahaan Anda sendiri, atau bahkan sektor ekonomi.

Saya tahu, sangat menggoda untuk berpikir bahwa teknologi akan menyelamatkan hari, dan bahwa kita bisa menjadi pahlawan yang mewujudkannya.

Plus, jika kita tidak melakukannya, orang lain akan melakukannya.

Tapi ingat bahwa kekuasaan itu korup, terlepas dari niat terbaiknya. Saya tidak akan menautkan ke artikel tertentu di sini, tetapi jika Anda belum menemukan artikel apa pun, ada baiknya mencari tahu tentang dampak yang lebih luas dari gangguan ekonomi, dan siapa yang akhirnya berperan dalam hal ini. Anda mungkin terkejut dengan beberapa efek samping dari mencoba menyelamatkan dunia melalui pengoptimalan.

Nota bene

Apakah Anda memperhatikan sesuatu, Optimus? Satu-satunya saat aku memanggilmu Optimus adalah di awal dan sekarang di akhir. Anda tidak dipanggil Optimus sepanjang artikel. Saya akan jujur, saya lupa. Saya menulis seluruh artikel tanpa memanggil Anda Optimus. Pada akhirnya ketika saya menyadari bahwa saya harus kembali dan memercikkan nama Anda di seluruh teks, sebuah suara kecil di dalam diri saya berkata, jangan lakukan itu .