Saya mengajukan pertanyaan ini ke programmer C ++ karena: a) Hanya seorang programmer C ++ yang dapat menilai manfaat teknis dari contoh-contoh; b) Hanya seorang programmer yang akan merasakan temperamen programmer lain yang menulis kode seperti ini.
SDM dan direktur menyadari ada masalah hanya karena mereka melihat bukti di lapangan. Ini panggilan saya apakah kami memberi programmer pertanyaan lebih banyak waktu. Banyak kesalahan berada pada level yang sangat mendasar - pertanyaan saya (kepada programmer) adalah apakah seseorang yang mengaku sebagai pengembang senior C ++ harus diberi manfaat keraguan berdasarkan sampel kode mereka saat ini. Non-programmer - bahkan orang-orang di luar pemrograman C ++ - tidak dapat membuat penilaian atas hal ini.
Sebagai latar belakang, saya telah diberi tugas mengelola pengembang untuk perusahaan yang sudah mapan. Mereka memiliki pengembang tunggal yang berspesialisasi dalam semua pengkodean C ++ (sejak selamanya), tetapi kualitas pekerjaannya sangat buruk. Ulasan dan pengujian kode telah mengungkapkan banyak masalah, salah satu yang terburuk adalah kebocoran memori. Pengembang tidak pernah menguji kodenya untuk kebocoran, dan saya menemukan bahwa aplikasi dapat bocor banyak MB hanya dengan satu menit penggunaan. Pengguna melaporkan perlambatan besar, dan pendapatnya adalah, "itu tidak ada hubungannya dengan saya - jika mereka berhenti dan memulai kembali, semuanya baik-baik saja."
Saya telah memberinya alat untuk mendeteksi dan melacak kebocoran, dan duduk bersamanya selama berjam-jam untuk menunjukkan bagaimana alat tersebut digunakan, di mana masalah terjadi, dan apa yang harus dilakukan untuk memperbaikinya. Kami berada 6 bulan di jalur, dan saya menugaskan dia untuk menulis modul baru. Saya meninjaunya sebelum diintegrasikan ke dalam basis kode kami yang lebih besar, dan kecewa ketika menemukan kode buruk yang sama seperti sebelumnya. Bagian yang saya temukan tidak dapat dipahami adalah bahwa beberapa pengkodean lebih buruk daripada amatir. Misalnya, dia menginginkan kelas (Foo) yang dapat mengisi objek kelas lain (Bar). Dia memutuskan bahwa Foo akan memegang referensi ke Bar, misalnya:
class Foo {
public:
Foo(Bar& bar) : m_bar(bar) {}
private:
Bar& m_bar;
};Tetapi (karena alasan lain) ia juga membutuhkan konstruktor default untuk Foo dan, alih-alih mempertanyakan desain awalnya, ia menulis permata ini:
Foo::Foo() : m_bar(*(new Bar)) {}Jadi setiap kali konstruktor default dipanggil, sebuah Bar bocor. Lebih buruk lagi, Foo mengalokasikan memori dari heap untuk 2 objek lain, tetapi ia tidak menulis destruktor atau menyalin konstruktor. Jadi setiap alokasi Foo sebenarnya bocor 3 objek berbeda, dan Anda bisa membayangkan apa yang terjadi ketika Foo disalin. Dan - itu hanya menjadi lebih baik - dia mengulangi pola yang sama pada tiga kelas lainnya, jadi itu bukan slip satu kali. Seluruh konsep itu salah pada banyak tingkatan.
Saya akan merasa lebih mengerti jika ini berasal dari seorang novis total. Tetapi orang ini telah melakukan ini selama bertahun-tahun dan telah sangat memusatkan pelatihan dan saran selama beberapa bulan terakhir. Saya menyadari dia telah bekerja tanpa mentoring atau ulasan sejawat sebagian besar waktu itu, tapi saya mulai merasa dia tidak bisa berubah. Jadi pertanyaan saya adalah, apakah Anda akan bertahan dengan seseorang yang menulis kode yang jelas-jelas buruk?