- Rancangan
- Penerapan
- Integrasi
Ketika saya baru memulai karir saya dalam pengembangan profesional, saya tidak mengerti mengapa open source diperlukan. Saya juga tidak mengerti proyek sampingan. Lagi pula, mengapa memberi pekerjaan yang berharga gratis? Selama bertahun-tahun, melalui bekerja pada proyek-proyek open source, serta bekerja dengan Apex.AI, ROS 2 dan Autoware.Auto, saya sampai pada pemahaman tentang open-source.
Insinyur senang menciptakan. Orang ingin pengakuan dan terima kasih.
Ketika Anda menggabungkan faktor-faktor ini bersama-sama, Anda memiliki jalur ke sumber terbuka. Jika saya membangun sesuatu untuk memenuhi kebutuhan kreatif saya, mengapa tidak membiarkan semua orang menghargai karya saya dan menemukan penggunaan praktis dan nilai di dalamnya? Lagi pula, saya tidak melakukan ini untuk uang.
Sedangkan untuk proyek sampingan, saya menyadari daya tarik mereka hanya setelah saya mulai mengembangkan secara profesional dan lebih hati-hati mendekati berbagai aspek pekerjaan saya. Untuk membuat produk andal yang akan dibayar orang, sering kali perlu membatasi alur kerja secara artifisial. Analisis desain. Ulasan kode. Standar pengkodean, panduan gaya, metrik cakupan uji, dan sebagainya dan seterusnya. Jangan salah paham - ini semua adalah hal-hal baik yang kemungkinan besar diperlukan untuk mengembangkan produk yang berkualitas. Hanya saja terkadang pengembang menginginkan sedikit kebebasan. Pengembang mungkin ingin membuat apa yang diinginkannya, keinginannya, dan kapan pun dia mau. Tidak ada rapat, ulasan, atau kasus bisnis.
Jadi bagaimana Anda menggabungkan aspek-aspek ini ketika datang untuk mengembangkan algoritma yang aman atau berkualitas tinggi? Sebagian besar daya pikat dunia open source adalah kebebasan, dan praktik yang membantu memastikan kode yang lebih andal dikembangkan membatasi kebebasan itu.
Jawaban yang saya temukan adalah mengikuti disiplin yang terbuka dan konsisten, dan secara bebas menggunakan banyak alat keren yang berasal dari dunia open source.
Merencanakan proyek sumber terbuka
Insinyur membutuhkan keahlian khusus untuk mengatasi masalah ini. Insinyur perlu fokus, mereka membutuhkan keterampilan pemecahan masalah yang baik. Insinyur juga harus dapat memisahkan masalah dan memiliki keterampilan dasar yang solid yang diperlukan untuk mendapatkan pengetahuan tentang semua hal di atas.
Keterampilan khusus ini dapat membuat kita insinyur menjadi agak kewalahan.
Untuk semua kemampuan teknis yang dimiliki insinyur, mereka pada akhirnya terbatas pada kemampuan mereka. Saya berpendapat bahwa sebagian besar pengembang tidak dapat mengingat seluruh proyek saat menulis setiap baris kode. Selain itu, saya berpendapat bahwa sebagian besar pengembang tidak dapat memprogram dan menyimpan proyek yang lebih luas di kepala mereka tanpa melupakan tujuan bisnis umum.
Di sinilah sihir hitam manajemen proyek ikut berperan.
Meskipun kami, pengembang, mungkin memiliki hubungan yang agak kontroversial dengan manajer SDM, teknis, atau proyek, harus diakui bahwa semua orang ini melakukan pekerjaan penting. Perwakilan terbaik dari profesi manajemen memastikan bahwa pengembang tidak melupakan tugas-tugas penting, dan gangguan menjengkelkan tidak menghentikan kita dari penembakan masalah dengan semua senjata.
Dan sementara kami memahami pentingnya manajer yang berbeda, orang-orang dengan keterampilan ini biasanya tidak terlibat dalam proyek sumber terbuka khas yang tujuannya untuk bersenang-senang.
Jadi apa yang harus kita lakukan?
Nah, kami para pengembang dapat membuat tangan kami kotor dan menghabiskan sedikit waktu untuk merencanakan ke depan.
Saya tidak akan membahas percakapan ini, karena pada posting sebelumnya saya membahas secara rinci tentang tahap perencanaan desain dan pengembangan. Intinya adalah bahwa dengan mempertimbangkan desain dan arsitektur, yang biasanya terdiri dari banyak komponen, dan membentuk beberapa dependensi, dalam proyek Anda sendiri, Anda membentuk desain sendiri, dan mengumpulkan komponen-komponennya secara terpisah.
Kembali ke aspek perencanaan proyek, saya suka memulai dengan komponen dengan dependensi paling sedikit (pikirkan sebentar!) dan kemudian terus bekerja, menambahkan rintisan implementasi di mana diperlukan untuk menjaga pengembangan berjalan. Dengan urutan kerja ini, Anda biasanya dapat membuat banyak tiket (dengan beberapa dependensi di dalamnya sesuai dengan dependensi arsitektur Anda - jika pelacak tugas Anda memiliki fungsi seperti itu). Tiket ini mungkin berisi beberapa catatan umum yang berguna untuk diingat sebelum Anda menyelami tugas apa pun secara lebih rinci. Tiket harus sekecil dan sespesifik mungkin. Mari kita hadapi itu - fokus dan kemampuan kita untuk mempertahankan konteks terbatas. Semakin rinci tugas pengembangan dipecah, semakin mudah - jadi mengapa tidak mencoba membuat tugas-tugas sulit sesederhana mungkin?
Seiring perkembangan proyek Anda, tugas Anda adalah mengambil tiket sesuai prioritas dan menyelesaikan tugas yang diberikan kepadanya.
Jelas, ini adalah versi manajemen proyek yang sangat disederhanakan. Ada banyak aspek lain untuk manajemen proyek yang benar seperti sumber daya, perencanaan, kasus bisnis yang bersaing, dan sebagainya. Manajemen proyek dalam open-source bisa lebih sederhana dan lebih bebas. Mungkin, dalam dunia pengembangan sumber terbuka, ada kasus manajemen proyek penuh.
Pengembangan terbuka
Setelah mengetik setumpuk tiket, telah menyusun rencana kerja, dan setelah memahami semua detailnya, kita dapat melanjutkan pengembangan.
Namun, banyak faktor kebebasan yang ada di barat liar pengembangan terbuka tidak boleh dalam pengembangan kode aman. Anda dapat menghindari banyak jebakan dengan menggunakan alat open source dan dengan beberapa disiplin (dan punya teman).
Saya seorang pendukung besar disiplin sebagai cara untuk meningkatkan kualitas kerja (setelah semua, disiplin berada di posisi ke-6 dalam peringkat saya di StrengthsFinder) Dengan disiplin yang cukup untuk menggunakan alat sumber terbuka, mendengarkan orang lain, bertindak berdasarkan hasil, dan tetap berpegang pada alur kerja, kita dapat mengatasi banyak kelemahan yang merayap dengan pendekatan koboi dari dunia sumber terbuka.
Singkatnya, penggunaan alat dan praktik berikut (yang, dengan beberapa peringatan, dapat dengan mudah diterapkan dalam proyek apa pun) membantu meningkatkan kualitas kode:
- Tes (atau lebih baik lagi, pengembangan uji coba)
- Analisis statis
- Integrasi Berkelanjutan (CI / CD)
- Ulasan Kode
Saya juga akan memberikan sejumlah prinsip yang saya patuhi saat menulis kode secara langsung:
- KERING
- Penggunaan penuh bahasa dan perpustakaan
- Kode harus dapat dibaca dan sangat menyilaukan.
Saya akan mencoba menghubungkan teks ini dengan implementasi aktual dari algoritma pelokalan NDT , yang diselesaikan dalam 10 permintaan penggabungan oleh kolega saya yang baik, Yunus . Dia terlalu sibuk dengan pekerjaan langsung, jadi aku bisa menggantungkan diri pada diriku beberapa medali imajiner dengan menulis tentang karyanya.
Selain itu, untuk mengilustrasikan beberapa proses dan praktik, saya akan memberikan contoh pengembangan algoritma open-source untuk pengontrol MPC . Itu dikembangkan dalam gaya yang sedikit lebih longgar (koboi) di sekitar 30+ permintaan penggabungan , tidak termasuk suntingan tambahan dan perbaikan yang dilakukan setelah pekerjaan utama selesai.
Pengujian
Mari kita bicara tentang pengujian.
Saya memiliki hubungan yang panjang dan sulit (menurut standar saya) dengan pengujian. Ketika saya pertama kali mendapat posisi sebagai pengembang dan mengambil proyek pertama, saya benar-benar tidak percaya bahwa kode saya berfungsi, dan karena itu saya adalah yang pertama di tim yang mulai menulis setidaknya beberapa tes unit yang berarti. Namun, saya benar bahwa kode saya tidak berfungsi.
Sejak itu, hubungan saya yang penuh gejolak dengan pengujian telah melalui banyak tikungan dan perubahan layak film semalam. Terkadang aku menyukainya. Terkadang aku membenci itu semua. Saya sudah menulis terlalu banyak tes. Terlalu banyak salin-tempel, terlalu banyak tes yang berlebihan. Kemudian pengujian menjadi pekerjaan rutin, bagian lain dari pengembangan. Pertama saya menulis kode, dan kemudian saya menulis tes untuk itu, ini adalah urutan hal.
Sekarang saya memiliki hubungan normal dengan pengujian. Ini adalah bagian integral dari alur kerja saya, apa pun aplikasi yang saya kerjakan.
Apa yang berubah bagi saya adalah teknik pengembangan berbasis tes yang saya mulai gunakan dalam proyek mpc saya.
Saya secara singkat berbicara tentang pengembangan yang digerakkan oleh tes pada teks sebelumnya, tapi di sini ada deskripsi lain dari proses tersebut:
- Kembangkan spesifikasi (use case, persyaratan, dll.).
- Menerapkan API / arsitektur
- Tulis tes berdasarkan API dan spesifikasi desain; mereka harus gagal.
- Menerapkan logika; tes harus lulus
Ada beberapa iterasi dalam proses ini (tes jangan gagal pada bertopik, implementasi gagal tes, API bisa canggung, dll), tetapi secara keseluruhan, saya pikir itu bisa sangat berguna.
Saya sudah bicara banyak tentang perencanaan sebelum implementasi, dan pengembangan berbasis tes memberi Anda kesempatan itu. Poin pertama dicatat. Kemudian Anda berpikir tentang arsitektur dan API, dan memetakannya untuk menggunakan case. Ini memberi Anda peluang besar untuk lebih dekat ke kode, tetapi masih berpikir tentang masalahnya secara lebih luas. Poin kedua dicatat.
Kemudian kami beralih ke tes menulis. Ada beberapa alasan untuk manfaat tes menulis sebelum implementasi, dan saya pikir semuanya penting:
- Tes harus ditulis sebagai objek prioritas pertama, bukan sebagai add-on.
- , – .
- API , .
- , , , , .
Secara keseluruhan, saya pikir manfaat pengembangan yang digerakkan oleh tes sangat besar, dan sekali lagi saya sangat menyarankan semua orang untuk setidaknya mencobanya.
Ayo kembali ke Autoware. Auto. Yunus, meskipun tidak berpegang teguh pada metode pengembangan yang digerakkan oleh tes, menulis tes untuk setiap permintaan penggabungan selama pengembangan NDT. Pada saat yang sama, volume kode uji sama dengan (dan kadang-kadang bahkan melebihi) volume kode implementasi, dan ini bagus. Sebagai perbandingan, SQLite , yang mungkin merupakan tolok ukur untuk pengujian (tidak hanya oleh standar proyek open source), memiliki kode pengujian 662 kali lebih banyak daripada kode implementasi... Di Autoware.Auto kami belum sepenuhnya pada tahap ini, tetapi jika Anda melihat riwayat permintaan penggabungan terkait dengan NDT, Anda dapat melihat bahwa volume kode uji perlahan-lahan merangkak naik hingga mencapai cakupan 90% (meskipun sejak itu telah turun karena desain lain dan kode eksternal).
Dan itu keren.
Demikian juga, proyek mpc saya memiliki tes untuk semuanya, termasuk tes itu sendiri . Selain itu, saya selalu hati-hati melakukan pengujian regresi untuk memastikan bahwa bug sudah diperbaiki dan tidak muncul lagi.
Saya orang baik-baik saja.
Analisis statis
Banyak konsep yang ingin tahu bahwa definisi yang dimasukkan di dalamnya dapat diperluas secara signifikan. Sebagai contoh, pengujian jauh melampaui tes fungsional tulisan tangan. Bahkan, pengecekan gaya atau perburuan bug juga dapat dianggap sebagai bentuk pengujian (ini pada dasarnya adalah inspeksi, tetapi jika Anda memperluas definisi, ini bisa disebut pengujian).
"Tes" semacam itu agak menyakitkan dan sulit untuk dikerjakan. Lagi pula, validasi, validasi untuk tab / spasi sejajar? Tidak, terima kasih.
Tetapi salah satu hal yang paling menyenangkan dan berharga tentang pemrograman adalah kemampuan untuk mengotomatisasi proses yang menyakitkan dan memakan waktu. Pada saat yang sama, kode dapat mencapai hasil lebih cepat dan lebih akurat daripada siapa pun. Bagaimana jika kita dapat melakukan hal yang sama dengan bug dan konstruksi yang bermasalah atau rentan kesalahan dalam kode kita?
Ya, kita bisa - dengan alat analisis statis.
Saya menulis tentang analisis statis cukup lama di posting blog sebelumnya , jadi saya tidak akan membahas manfaat dan alat yang dapat Anda gunakan.
Di Autoware.Auto kita menggunakan versi yang sedikit lebih kecil dari set ament_lintdari teman dekat kami di ROS 2. Alat ini banyak membantu kami, tetapi mungkin yang paling penting adalah pemformatan kode otomatis kami untuk menghilangkan perselisihan gaya - alat yang tidak memihak memberi tahu kami apa yang benar dan apa yang salah. Jika Anda tertarik, saya akan perhatikan bahwa format dentang lebih ketat daripada tidak dapat dipercaya .
Dalam proyek mpc, saya melangkah lebih jauh. Di dalamnya, saya menggunakan bendera Weverything dari kompiler Dentang , di samping semua peringatan dari dentang rapi dan analisa statis Dentang . Anehnya, pengembangan komersial membutuhkan beberapa opsi untuk dinonaktifkan (karena peringatan yang berlebihan dan kebingungan konseptual)). Ketika berinteraksi dengan kode eksternal, saya harus menonaktifkan banyak pemeriksaan - mereka menyebabkan kebisingan yang tidak perlu.
Pada akhirnya, saya menyadari bahwa menggunakan analisis statis yang luas tidak sangat mengganggu perkembangan normal (dalam hal menulis kode baru dan setelah melewati titik tertentu pada kurva pembelajaran)
Sulit untuk menghitung nilai analisis statis, terutama jika Anda menggunakannya dari awal. Intinya adalah sulit untuk menebak apakah ada kesalahan sebelum diperkenalkannya analisis statis atau tidak.
Namun, saya percaya bahwa menggunakan peringatan dan analisis statis adalah salah satu hal di mana, bahkan ketika digunakan dengan benar, orang tidak dapat memastikan bahwa mereka melakukan apa pun.. Dengan kata lain, Anda tidak dapat yakin tentang nilai dari penganalisa statis ketika dinyalakan, tetapi heck, Anda akan melihat itu tidak ada di sana segera.
CI / CD
Seperti halnya saya suka pengujian ketat dan analisis kode statis / dinamis, semua pengujian dan pemeriksaan tidak ada artinya jika tidak dijalankan. CI dapat memenuhi tantangan ini dengan overhead yang minimal.
Saya pikir semua orang setuju bahwa memiliki infrastruktur CI / CD adalah bagian penting dari pengembangan modern, serta menggunakan sistem kontrol versi dan memiliki standar pengembangan (setidaknya panduan gaya). Namun, nilai dari pipa CI / CD yang baik adalah operasinya harus dapat direproduksi.
Pipa CI / CD minimal harus membangun kode dan menjalankan tes sebelum memasukkan kode ke dalam repositori Anda. Lagipula, tidak ada yang mau menjadi lelaki (atau perempuan, atau persona) yang memecahkan kebaktian atau semacam ujian dan harus memperbaiki semuanya dengan cepat dan memalukan. CI (dan karenanya insinyur DevOps tersayang Anda) melindungi Anda dari rasa malu ini.
Tetapi CI dapat melakukan lebih banyak untuk Anda.
Dengan pipa CI yang kuat, Anda dapat menguji sejumlah kombinasi sistem operasi, kompiler, dan arsitektur (dengan beberapa batasan, mempertimbangkan pengujian kombinasi ). Anda juga dapat melakukan pembangunan, menjalankan pengujian, dan operasi lain yang bisa terlalu intensif sumber daya atau rumit bagi pengembang untuk melakukan secara manual. Anda tidak bisa melompati kepala Anda.
Kembali ke pernyataan asli, memiliki pipa CI / CD (yang kami gunakan di Autoware.Auto ) dalam proyek open-source Anda akan membantu mengendarai pengembangan yang tidak terkelola. Kode tidak akan dapat masuk ke proyek jika tidak membangun atau lulus tes. Jika Anda mematuhi disiplin pengujian yang ketat, Anda selalu dapat memastikan bahwa kodenya berfungsi.
Di Autoware.Auto, CI:
- Mengumpulkan kode
- Menjalankan tes (gaya, pemeriksaan linter, tes fungsional).
- Mengukur cakupan tes
- Pastikan kode tersebut didokumentasikan
Pada gilirannya, CI saya dengan tergesa-gesa menyusun dalam proyek mpc:
- Mengumpulkan kode
- Melakukan pemindaian (Analisis statis dentang)
- Menjalankan tes (tetapi tidak menghentikan CI jika tes gagal).
Saluran pipa CI yang disatukan oleh insinyur DevOps yang berpengalaman (seperti J.P. Samper atau Hao Peng kami !) Dapat melakukan lebih banyak lagi. Jadi hargai insinyur DevOps Anda. Mereka membuat hidup kita (sebagai pengembang) jauh lebih mudah.
Ulasan Kode
Benchmark, analisa dan CI sangat bagus. Anda dapat menjalankan tes, menganalisis semuanya, dan memastikan bahwa tes ini dilakukan menggunakan CI, bukan?
Sayangnya tidak ada.
Sekali lagi, semua tes di dunia tidak berharga jika mereka buruk. Jadi, bagaimana Anda memastikan tes Anda baik?
Sayangnya, saya tidak punya jawaban ajaib. Bahkan, saya akan kembali ke teknik teknik lama, peer review. Secara khusus, untuk meninjau kode.
Secara umum diyakini bahwa dua kepala lebih baik dari satu. Bahkan, saya berpendapat bahwa konsep ini didukung tidak hanya oleh literatur, tetapi juga oleh teori.
Ensemble metodedalam pembelajaran mesin menggambarkan teori ini. Dipercayai bahwa menggunakan ansambel metode adalah cara cepat dan mudah untuk meningkatkan kinerja model statistik (contohnya metode peningkatan yang terkenal ). Demikian pula, dari sudut pandang statistik murni, varians lebih rendah (dengan asumsi) semakin banyak sampel yang Anda miliki. Dengan kata lain, Anda lebih cenderung lebih dekat dengan kebenaran jika Anda menghubungkan lebih banyak karyawan.
Anda dapat mencoba teknik ini dengan contoh langsung dengan melakukan latihan membangun tim . Versi yang kurang menyenangkan mungkin melibatkan menebak statistik acak secara individu dan dalam suatu kelompok.
Mengesampingkan teori dan tim, review kode adalah alat yang penting dan kuat. Tidak mengherankan, tinjauan kode adalah bagian integral dari setiap proses pengembangan profesional, dan bahkan direkomendasikan oleh standar ISO 26262.
Semua ini menunjukkan bahwa selalu ada bahaya bahwa satu anak akan memiliki tujuh pengasuh anak. Selain itu, kadang-kadang tinjauan kode dapat menyebabkan kesulitan tertentu.
Namun, saya pikir ulasan kode bisa menyenangkan dan tidak menyakitkan jika resensi dan peer-review mengingat yang berikut:
- Anda bukan kode Anda.
- Anda sedang berbicara dengan orang lain.
- Bersikap sopan
- Setiap orang bekerja menuju tujuan yang sama; review kode tidak mewakili kompetisi apa pun (meskipun kadang-kadang terjadi dalam pemrograman )
Banyak orang yang lebih pintar dan lebih baik daripada saya telah menulis tentang bagaimana melakukan tinjauan kode dengan benar, dan saya mengundang Anda untuk melihat pekerjaan mereka . Hal terakhir yang bisa saya katakan adalah bahwa Anda harus melakukan review kode jika Anda ingin kode Anda lebih dapat diandalkan.
KERING
Saya masuk ke detail tentang proses dan alat yang dapat digunakan untuk membuat lingkungan pengembangan: pemeriksaan dan alat yang melakukan pemeriksaan dan memastikan bahwa kode cukup baik.
Selanjutnya, saya ingin beralih ke pembicaraan singkat tentang kecakapan pemrograman dan berbagi pemikiran tentang proses dan maksud di balik penulisan masing-masing baris kode.
Ada beberapa konsep yang telah membantu saya meningkatkan kode saya. Salah satu konsep itu adalah kemampuan untuk mengingat niat, semantik, dan keterbacaan, yang akan saya bicarakan nanti. Lainnya adalah pemahaman tentang OOP dan pemisahan masalah . Ide penting terakhir adalah KERING ( Jangan Ulangi Diri Sendiri ) atau prinsip "Jangan ulangi dirimu sendiri."
KERING adalah apa yang diajarkan di sekolah dan, seperti banyak hal lainnya, kami menempatkan pemikiran ini di rak paling jauh dan tidak menempelkan pentingnya hal itu di luar ujian (setidaknya untuk saya). Tetapi, seperti halnya banyak hal lain di sekolah, kita tidak belajar hal seperti itu saja. Sebenarnya, ini adalah praktik yang baik.
Sederhananya, jika Anda sering menyalin dan menempel kode, atau sering menulis kode yang serupa, ini merupakan indikasi yang sangat baik bahwa kode berulang dapat menjadi fungsi atau bagian dari beberapa abstraksi.
Tapi KERING lebih jauh daripada memeriksa bahwa beberapa kode harus dipindahkan ke fungsi. Konsep ini juga dapat berfungsi sebagai dasar untuk beberapa keputusan arsitektur.
Meskipun pendekatan ini berpotongan dengan beberapa konsep arsitektur (seperti aliasing, konektivitas, dan pemisahan masalah), contoh bagaimana DRY diterapkan pada arsitektur dapat dilihat di proyek mpc saya. Selama pengembangan pengontrol mpc, saya perhatikan bahwa saya harus menduplikasi beberapa kode jika saya pernah menulis pengontrol lain. Ini tentang kode boilerplate untuk melacak status, posting, langganan, konversi, dan sejenisnya. Dengan kata lain, sepertinya itu adalah tugas yang terpisah dari pengontrol mpc.
Ini adalah indikasi yang baik bahwa saya harus memisahkan desain umum dan fungsionalitas ke dalam kelas yang terpisah . Pengembalian dana ada dua: pengontrol mpc adalah 100% fokus pada kode yang terkait dengan mpc, dan denganmodul yang terkait dengannya hanyalah templat konfigurasi. Dengan kata lain, karena arsitektur abstraksi, saya tidak perlu menulis ulang semuanya ketika bekerja dengan pengontrol yang berbeda.
Dunia terdiri dari nuansa abu-abu, sehingga keputusan desain ini harus diselidiki dengan hati-hati dan pola pikir yang benar. Kalau tidak, Anda bisa melangkah terlalu jauh dan mulai membuat abstraksi yang tidak diperlukan. Namun, jika pengembang memperhatikan konsep-konsep yang model abstraksi ini, KERING adalah alat yang kuat untuk membentuk keputusan arsitektur. Menurut pendapat saya KERING adalah konsep utama untuk menjaga kode Anda bersih dan padat.
Bagaimanapun, salah satu manfaat utama dari kode adalah kemampuannya untuk melakukan tugas yang berulang, jadi mengapa tidak mengalihkan pengulangan ke fungsi dan kelas yang dirancang dengan baik?
Penggunaan penuh bahasa dan perpustakaan
KERING, menurut saya, adalah konsep yang begitu penting dan luas sehingga poin ini benar-benar hanya merupakan kelanjutan dari percakapan KERING.
Jika bahasa Anda mendukung sesuatu, maka umumnya Anda harus menggunakan implementasi inline, kecuali jika Anda memiliki alasan yang sangat bagus untuk memilih keluar. Dan C ++ memiliki banyak hal yang terintegrasi .
Pemrograman adalah keterampilan dan ada perbedaan besar dalam tingkat keterampilan. Saya hanya melihat sekilas betapa tingginya keterampilan ini, dan secara umum saya menemukan bahwa orang-orang yang menciptakan standar lebih baik dalam menerapkan pola-pola umum daripada saya.
Argumen serupa dapat dibuat untuk fungsionalitas perpustakaan (meskipun mungkin tidak begitu kategoris). Orang lain telah melakukan hal yang sama, dan mungkin pada level yang baik, sehingga tidak ada alasan untuk menemukan kembali roda.
Namun demikian, ini, seperti banyak yang lain, paragraf ini adalah rekomendasi, dan bukan aturan yang kaku dan mendesak untuk diterapkan. Meskipun tidak ada gunanya menciptakan kembali roda, dan sementara implementasi standar umumnya sangat baik, tidak ada gunanya mencoba memeras sepotong persegi ke dalam lubang bundar. Pikirkan dengan kepalamu.
Kode yang bisa dibaca
Konsep terakhir yang membantu saya meningkatkan keterampilan pemrograman saya adalah bahwa pemrograman tidak begitu banyak tentang menulis kode tetapi tentang komunikasi. Jika tidak berkomunikasi dengan pengembang lain, maka komunikasi dengan diri Anda dari masa depan. Tentu saja, Anda perlu memikirkan ingatan, matematika, dan kompleksitas Big O, tetapi begitu Anda menyelesaikannya, Anda harus mulai memikirkan niat, semantik, dan kejelasan.
Ada buku yang sangat terkenal dan banyak direkomendasikan tentang topik ini, Clean Code , jadi tidak banyak yang bisa saya tambahkan tentang topik ini. Berikut adalah beberapa informasi umum yang saya rujuk ketika menulis kode dan melakukan tinjauan kode:
- Usahakan agar kelas Anda tetap jelas dan fokus:
- Minimalkan snagging
- ()
-
- -
- ? ()
Sumber hebat lain yang mengatasi masalah semacam ini adalah Pedoman Inti ISO C ++ .
Saya akan tegaskan kembali bahwa tidak satu pun dari prinsip-prinsip ini yang revolusioner, baru atau unik, tetapi jika penulisan prinsip-prinsip tersebut memiliki nilai (atau seseorang akan mengatakan "aha" setelah membaca ), maka saya tidak membuang-buang waktu dan lalu lintas untuk menulis posting ini. ...
Melihat kembali
Ini adalah beberapa alat, prinsip dan proses yang kami gunakan dalam mengembangkan dan mengimplementasikan algoritma lokalisasi NDT, serta ketika bekerja pada pengontrol MPC. Banyak pekerjaan yang dilakukan, menyenangkan, tidak begitu menarik untuk dibicarakan.
Secara keseluruhan, kami sangat memanfaatkan alat dan praktik yang saya sebutkan, tetapi kami tidak sempurna.
Jadi, misalnya, ketika mengerjakan NDT, kami tidak mengikuti idiom pengembangan yang digerakkan oleh pengujian (meskipun kami memiliki semuanya dengan sempurna diuji!). Pada gilirannya, saya memang mengikuti teknik pengembangan test-driven pada MPC, tetapi proyek ini tidak mendapat manfaat dari CI yang lebih kuat yang dibangun ke Autoware. Selain itu, proyek MPC tidak bersifat publik dan karena itu tidak menerima manfaat dari tinjauan kode.
Kedua proyek dapat mengambil manfaat dari pengenalan analisis statis, pengujian yang lebih rinci, dan umpan balik yang lebih banyak. Namun, kita berbicara tentang proyek yang dibuat oleh satu orang, jadi saya pikir pengujian dilakukan dan umpan balik yang diterima sudah cukup. Ketika datang ke analisis statis, bentuk yang lebih baik dan lebih dekat umumnya jatuh ke ranah minat pengembangan produk dan menjauh dari komunitas pengembang open-source (meskipun ide-ide menarik mungkin muncul di cakrawala ).
Saya tidak memiliki apa-apa untuk dikatakan tentang pengembangan simultan dua algoritma - kami bekerja dengan kemampuan terbaik kami, mengikuti prinsip-prinsip yang saya jelaskan di atas.
Saya pikir kami telah melakukan pekerjaan yang sangat baik untuk menguraikan masalah besar menjadi potongan-potongan kecil (meskipun komponen MR dalam algoritma NDT bisa lebih kecil), dan telah melakukan pengujian ekstensif. Saya pikir hasil awal berbicara sendiri.
Gerakan maju
Setelah implementasi, saatnya untuk integrasi. Penting untuk terhubung ke sistem yang lebih besar dengan komponen kompleksnya sendiri. Sistem ini akan mengambil input Anda, mencernanya, dan menghasilkan hasil dari algoritma Anda. Integrasi mungkin merupakan bagian paling sulit dalam mengembangkan suatu algoritma, karena Anda perlu melacak keseluruhan rencana sistem dan memperbaiki masalah tingkat rendah. Kesalahan apa pun di banyak baris kode Anda dapat mencegah algoritme Anda untuk berintegrasi.
Saya akan membahas ini di pos ketiga dan terakhir dari seri ini.
Sebagai pratinjau, saya akan mengatakan bahwa selama proses pengembangan, tidak ada kesalahan besar yang ditemukan selama penggunaan dan integrasi pengontrol mpc. Benar, ada beberapa masalah dengan penulisan skrip , perakitan,tes , input data validasi dilewati , dan ada juga masalah dengan ketidakcocokan pengaturan QoS , tetapi tidak ada yang mengerikan dalam kode.
Bahkan, ia dapat menjalankan (melewati ketidakcocokan QoS dan opsi pengaturan) hampir di luar kotak .
Hal yang sama berlaku untuk algoritma NDT, yang mengalami sejumlah masalah kecil seperti ketidakstabilan kovarians , kesalahan dalam mencari string dalam kode yang ada, dan peta yang tidak selaras. Apapun, itu juga mampu bekerja di luar kotak .
Tidak buruk untuk produk yang dirancang untuk dilihat semua orang.
Berlangganan saluran:
@TeslaHackers — Tesla-, Tesla
@AutomotiveRu — ,
: