Bagaimana membujuk pemrogram untuk mengikuti aturan dasar


20

Ada beberapa aturan yang saya harus terus meminta programmer untuk mengikuti sangat sering. Mereka menulis kode dan, jika berhasil, pekerjaan baru saja selesai, untuk mereka. Sebagian besar aturan dasar mungkin:

  • Melakukan perubahan
  • Tidak menulis masalah Model di Tampilan atau Pengontrol
  • Hindari hardcoding

Bisakah Anda ceritakan tentang pengalaman Anda? Bagaimana Anda mengatur ini?


2
Anda harus bertanya di programmers.stackexchange.com. Apakah Anda melakukan review kode? Apakah Anda memiliki alat peninjau kode seperti Crucible? Saya akan merekomendasikan melakukan tinjauan kode menyeluruh dan bersikeras pada semua masalah yang diselesaikan sebelum pekerjaan lain dilakukan.

15
Anda dapat mencoba meninggalkan kepala kuda di tempat tidur mereka yang bekerja di Godfather.
Gaurav

4
Saya sudah sukses besar dengan voltase tinggi. Jarak tempuh Anda mungkin beragam.
Tim Post

2
@Tim: koran yang digulung lebih ramah lingkungan
Steven A. Lowe

@ Sebelas, saya kira itu akan menjadi. Pertama Anda mengarahkan kembali koran tersebut, kemudian daur ulang. Saya kira ada seni untuk mengintimidasi hijau.
Tim Post

Jawaban:


6

Semua pekerja pengetahuan harus ditantang untuk melakukan pekerjaan yang berkualitas. Kualitas akan menderita jika mereka merasa kendala waktu sewenang-wenang ditempatkan pada mereka. Mengapa tidak hanya membuat hal-hal yang "cukup baik" ketika semua orang peduli dengan memenuhi spesifikasi dan memenuhi tenggat waktu?

Daftar keluhan Anda adalah gejala perusahaan yang hanya memberikan penghargaan untuk memenuhi tujuan jangka pendek dan tidak memiliki keinginan untuk menekankan kualitas tinggi. Apakah Anda menjalankan hotel bintang lima atau halte truk?


1
+1 untuk menunjukkan ini adalah masalah budaya dan perlu ditangani dari sudut pandang motivasi.
Alex Feinman

itu adalah baik masalah budaya perusahaan sebagai disinggung oleh JeffO. tetapi kadang-kadang budaya itu dimasak dari bawah ke atas ketika coders dan pengembang tidak memiliki visi untuk kode kualitas atau untuk kebutuhan itu. ketika mereka berada di sekolah Ilmu Komputer, profesor mereka seharusnya menampar mereka di sisi kepala mereka beberapa kali.
robert bristow-johnson

@ robertbristow-johnson - Poin bagus.
JeffO

14

Untuk dapat mengikuti aturan dasar, mereka perlu tahu apa aturannya dan mereka harus menyetujuinya.

Cara untuk mengatasinya adalah dengan bersama - sama membuat dokumen pedoman pengkodean yang dapat disetujui semua orang. Jangan mencoba memaksakan ini pada mereka, itu akan menjadi bumerang jika Anda melakukannya.

Jadi kumpulkan tim dan mulailah bekerja pada definisi umum tentang aturan dasar Anda!

Lakukan itu sebagai bengkel di mana semua suara terdengar. Timebox untuk menghindari diskusi tanpa akhir. Anda mencoba menyatukan beberapa pikiran, jadi Anda mungkin ingin mengatur panggung dengan nada positif bahwa Anda semua harus menghormati dan tetap berpikiran terbuka (penulisan kode bersifat pribadi ...).

Pedoman ini harus diubah terus-menerus setiap kali tim merasa ada sesuatu yang harus ditambahkan atau diklarifikasi.


2
Meskipun saya setuju, saya juga tidak setuju dengan "Jangan mencoba memaksakan ini pada mereka, itu akan menjadi bumerang jika Anda melakukannya." - Ketika semuanya dikatakan dan dilakukan, apakah seseorang menyetujui atau tidak aturan dasar tidak relevan. Bos membuat aturan, mengikuti mereka atau mencari pekerjaan lain. Kami tidak begitu istimewa sehingga hubungan majikan-karyawan tidak berlaku.
Steven Evers

12

Apa peranmu Jika Anda hanyalah pengembang lain dengan minat kuat pada kualitas kode, Anda mungkin tidak memiliki wewenang untuk membuat mereka mendengarkan Anda, dan mungkin Anda harus melambungkan ide-ide ini kepada manajemen untuk menetapkan standar kode yang seharusnya / harus diikuti. Jika Anda seorang manajer / pemimpin tim / arsitek apa pun dan Anda memang memiliki otoritas, maka Anda dapat membangun sendiri praktik-praktik itu. Melembagakan dokumen standar dan proses peninjauan kode untuk menyingkirkan hal-hal ini.

Ini tidak akan menjadi saklar ajaib yang bisa Anda nyalakan; itu akan menjadi proses yang lambat dan tidak akan pernah 100%. Lagipula itu pengalaman saya.


1
Setuju. Ini adalah masalah politik, bukan teknis.

Dan standar kode apa pun harus disepakati setidaknya sebagian oleh grup. Alat-alat seperti StyleCop banyak membantu.
Pekerjaan

Bos saya berusaha untuk mendorong "kualitas kode" -nya, tetapi itu tidak lepas landas, karena orang-orang tidak percaya. memiliki kekuatan tidak selalu jawabannya.
IAdapter

@ 0101 Sangat benar. Kekuatan membantu mendorong pesan. Pesan harus dibuat sehingga akan diterima dan diikuti.
RationalGeek

7

Perlu kombinasi yang masuk akal dari semua jawaban sejauh ini. Pada akhirnya, ketika Anda berbicara tentang sekelompok orang pintar (pengembang), Anda harus memberi mereka alasan mengapa perilaku itu penting dan memberi mereka cukup kontrol atas bagaimana perilaku itu diterapkan sehingga mereka berinvestasi untuk melakukannya dengan benar. Mandat dari atas umumnya longgar dengan orang-orang pintar, karena jika mereka tidak setuju bahwa masalahnya adalah masalah, maka mereka cenderung menghabiskan lebih banyak waktu untuk bekerja di sekitar mandat daripada mengikuti aturan.

Inilah beberapa taktik saya:

Melakukan Perubahan:

Pertama, tim perlu menyepakati kapan komitmen dan apa yang harus dilakukan. Sangat penting adalah pengaturan bangunan yang masuk akal, sehingga orang tidak menunda hanya karena mereka tidak tahu di mana harus meletakkan sesuatu. Dan konsensus tentang kapan / seberapa sering untuk check-in. "Jangan merusak gedung" adalah aturan yang jelas, tetapi bagaimana itu diperiksa, dan siapa yang diberitahu tentang hal itu? Baseline lain adalah "tidak dilakukan jika tidak dicentang".

Sebagian besar pengembang yang saya kenal lebih dari senang untuk memeriksa kode JIKA:

  • Proses check-in mudah
  • Proses sinkronisasi itu mudah (memperhitungkan perubahan dari pengembang lain)
  • Melihat perubahan dan berpindah antar versi itu mudah

Satu hal yang saya perhatikan baru-baru ini adalah bahwa checkin menjadi lebih sering dan tidak terlalu menyakitkan ketika kita beralih ke alat CM baru. Tim kami memelopori Konser Tim Rasional yang sebelumnya menggunakan Clearcase. Saya tidak bermaksud mengiklankan alat, tetapi gelombang baru (untuk saya) streaming checkin dengan banyak penggabungan kecil dan cepat membuatnya jauh lebih menarik untuk checkin lebih awal dan sering.

Membiarkan pengembang bertanggung jawab menghilangkan rasa sakit CM umumnya meningkatkan jumlah checkin yang terjadi.

Mengikuti Arsitektur - Tidak Menulis Masalah Model dalam Tampilan dan Pengontrol

Saya menempatkan bahwa dalam rumpun umum "melakukan arsitektur dengan benar". Saya setuju dengan siapa pun yang mengatakan ulasan sejawat - tekanan sejawat sangat bagus untuk ini. Salah satu cara saya biasanya melihat orang masuk ke flip untuk praktik terbaik di bidang ini adalah ketika rekan-rekan mereka bertanya kepada mereka mengapa mereka melakukannya dengan cara lain (cara yang tidak begitu benar). Secara umum pertanyaan "mengapa" akan membawa orang ke jalan untuk menyadari mengapa mereka harus melakukannya secara berbeda. Ketika orang memiliki alasan yang dipahami dengan baik untuk praktik terbaik, akan lebih mudah untuk mematuhinya.

Juga, jika ada beberapa formalitas yang menghubungkan seseorang dengan suatu keputusan, maka akan lebih mudah untuk menetapkan bug di area itu ... jadi jika seseorang bertanggung jawab untuk memperbaiki bug di area desain yang salah, kebutuhan untuk mendapatkan sesuatu tepat sebelum mereka dapat beralih ke sesuatu yang baru dan menarik dapat menjadi motivator besar.

Hindari Hardcoding

Saya akan mulai dengan standar pengkodean yang jelas dan mengintegrasikan tinjauan standar pengkodean dalam ulasan sejawat. Hard coding adalah salah satu hal yang dapat dengan mudah menjadi kotak centang pada agenda peer review.

Saya khawatir hal semacam ini adalah satu-satunya hal di mana saya melihatnya menjadi peran pemimpin tim untuk menegakkan aturan. Di tim yang saya jalankan, kami biasanya tidak akan membiarkan seseorang pindah sampai mereka telah memperbaiki komentar dari ulasan rekan kode mereka. Dan "no hard coding" adalah komentar peer review yang sering.

Secara umum

Dengan hampir semua latihan terbaik, saya pikir Anda harus memilih pertempuran Anda. Tidak ada tim yang akan menjadi sempurna sempurna. Tetapi Anda bisa mengawasi titik-titik rasa sakit utama Anda dan mulai mengatasinya secara berkelompok. Saya pikir itu menjadi peran pemimpin untuk benar-benar tahu apa yang menjadi titik sakit bagi tim vs kekhasan yang mengganggu dari individu tertentu.

Jika tim Anda tidak melakukan praktik terbaik tertentu, saya pikir pertanyaan pertama adalah "berapa banyak kerusakan yang diakibatkan ini?" jika jawabannya "minimal", maka itu mungkin tidak sepadan dengan waktunya. Beberapa praktik terbaik paling relevan dengan jenis sistem tertentu - meskipun secara keseluruhan baik, mereka mungkin tidak sebanding dengan perjuangan untuk sistem di mana praktik tersebut tidak sering terjadi atau bagian utama dari sistem.

Jika jawaban untuk "berapa banyak damange?" adalah "ALOT !!!", maka Anda dapat mulai membangun sebuah kasus untuk menunjukkan kepada tim bahwa semua rasa sakit dan penderitaan ini dapat dihilangkan dengan memperbaiki satu titik kendur ini dalam praktik terbaik. Kebanyakan orang senang menghindari rasa sakit dan penderitaan dan itu mengubah dialog dari "lakukan ini karena saya katakan kepada Anda", menjadi "kami memutuskan untuk melakukan ini karena itu lebih baik".


Komentar panjang, tetapi pendekatan Anda mengagumkan. Untuk membuat orang mematuhi pedoman ini, mereka perlu percaya bahwa itu bermanfaat. Saya tertarik untuk mendengar beberapa contoh bagaimana ini bekerja untuk tim Anda.
jmort253

Contoh favorit saya adalah pengaturan lingkungan pengujian yang konsisten. Saya tidak HARUS menegakkan Jalan yang Benar. Saya memiliki seorang pria yang bertanggung jawab atas dokumen instalasi. Saya berkata - "itu semua Anda-Anda dapat melakukan apa pun untuk membuat mekanisme instalasi yang memastikan instalasi yang konsisten - semua orang diberi wewenang untuk mengganggumu jika instalasinya kacau". Dalam waktu kurang dari sebulan kami memiliki alat yang solid dan dokumen yang sangat singkat. Dan alat itu dipasang sebagai jalan pintas di setiap desktop. Saya tidak perlu penegakan hukum, instalasi yang tepat sudah merupakan jalan yang paling tidak resistan. Sekarang tujuan kami adalah menghapus pintasan, menjadikannya otomatis.
bethlakshmi

6

Ulasan kode. Hanya terima kode yang ditulis dengan baik yang tidak memiliki kesalahan.


3
Itu bukan solusi untuk masalah yang mendasarinya. Jangan buang waktu dengan ulasan kode, saat Anda bisa memperbaiki masalah penyebab root.
Martin Wickman

Jika Anda bisa memaksa mereka untuk mengerjakan ulang barang berulang kali, kemalasan bawaan mereka akan membuat mereka mulai menyesuaikan diri dari waktu ke waktu.
David Thornley

Setuju, orang hanya perlu bertanggung jawab dan melakukan pekerjaan mereka tanpa diberi tahu. Peninjauan kode setelah setiap perubahan adalah pemborosan waktu.
jmort253

5

Paling sedikit :

  • Buat lebih mudah bagi mereka untuk mengikuti kode (Alat seperti resharper, StyleCop) Jika mudah mereka cenderung mengadopsi.

Selain itu pilih yang berfungsi berdasarkan organisasi Anda, pengembang dan peran Anda dalam tim.

  • Biarkan mereka melakukan perbaikan bug dan ubah permintaan secara teratur
  • Pasangkan program dengan pengembang berpengalaman
  • Ulasan kode secara konstruktif
  • Panduan kode
  • Mulai pelatihan, gunakan buku-buku seperti Code Complete dan The pragmatic programmer.

5

Peran saya adalah Manajer, tetapi sebagai tim kecil saya berkembang dan saya lebih suka mengelola sebagai pelatih.

Elektroda di kursi yang terhubung ke parser kode telah ditunjukkan, tetapi programmer tampaknya tidak takut. Memecat tidak terdengar sebagai pendekatan yang baik, karena itu berarti kehilangan aset yang layak.

Saya akan melihat semua alat itu dan saya tetap terbuka untuk yang lain yang Anda katakan.


3
Jika aset Anda sangat berharga, mungkin masalah ini tidak begitu penting? Anda harus memilih dan memilih pertempuran Anda beberapa kali.
JeffO

Pertanyaan saya adalah tentang meningkatkan apa yang saya miliki, yang lebih sulit tetapi efektif daripada mencari & mengganti
Llistes Sugra

Memecat orang yang tidak akan mengikuti aturan pengkodean BUKAN kehilangan aset bagus, itu menghilangkan kayu mati.
HLGEM

@HLGEM - Kecuali orang yang tidak mengikuti aturan kebetulan adalah seorang ninja kode yang dapat menyelesaikan masalah apa pun di organisasi. House tidak mematuhi aturan, tetapi jika rumah sakit memecatnya, akan ada banyak orang fiksi yang akan mati. en.wikipedia.org/wiki/Gregory_House
jmort253

4

Ada 3 cara kami mengatasi masalah ini:

  1. Analisis statis kode sumber untuk memeriksa masalah dengan konvensi pengkodean. Gunakan alat seperti cppcheck dan yang dari grammatech . Wikipedia memiliki daftar yang bagus: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis . Biasanya sebagian besar sistem kontrol sumber akan memiliki kait di mana Anda dapat memeriksa masalah tersebut secara langsung selama check-in. Untuk kait CVS lihat tautan ini: http://goo.gl/F1gd2 . Kegagalan untuk mematuhi berarti check-in yang gagal, dan lebih dari 3 kegagalan berarti bahwa pengembang harus menjelaskan sendiri kepada tim.

  2. Selama proses pengkodean itu sendiri masalah bendera untuk pengembang. Memiliki skrip khusus yang terintegrasi dengan IDE pilihan Anda adalah cara yang keren untuk melakukan ini. Lihat tautan ini: http://goo.gl/MM6c4

  3. Ikuti proses lincah dan pastikan bahwa tinjauan kode adalah bagian dari sprint


1
+1, saya telah mengkomit kait yang menjalankan apa pun yang telah dimodifikasi melalui belat (dan beberapa serat lainnya) serta alat untuk memastikan saya tidak memasukkan header secara sia-sia, ditambah memastikan lekukan adalah tab bukan spasi, dll.
Tim posting

Solusi teknis tidak akan membantu jika pengembang tidak diwajibkan untuk menggunakannya.
Robert Harvey

2

Inilah rencana 3 langkah saya:

  1. Tembak para programmer
  2. Sewa beberapa Insinyur Perangkat Lunak
  3. ...
  4. Keuntungan!

: D

Dalam semua keseriusan, jika mereka tidak percaya melakukan apa pun selain menulis kode, Anda memerlukan tim yang lebih baik. Seorang programmer tempat saya bekerja menggunakan direktori berbeda di komputer sebagai CM-nya. Kami bertarung dengan programmer mereka selama hampir setahun (karena perubahan akan memperkenalkan bug saat mereka menyalin dan menempel kode lama). Kami akhirnya memecat mereka.


2
  1. Tunjukkan kepada mereka, ketika mereka melanggar aturan dasar.
  2. Tunggu hingga mereka menghasilkan bug yang tidak dapat mereka lacak atau dihadapkan dengan permintaan fitur yang tidak dapat mereka terapkan karena kode mereka yang tidak fleksibel.
  3. Ingatkan mereka tentang apa yang Anda katakan sebelumnya.
  4. Biarkan mereka tenggelam dalam kotoran mereka sendiri untuk sementara waktu.
  5. Luangkan waktu untuk memperbaiki kode yang dimaksud, mengisolasi bug / memberikan infrasturcutre untuk menghubungkan fungsionalitas baru. Luangkan waktu untuk menjelaskan apa yang Anda lakukan.

Atau, hal yang paling kejam tetapi sangat persuasif untuk dilakukan adalah membiarkan mereka mempertahankan basis kode yang ditulis dengan sangat buruk, diberi jadwal yang ketat. : D
Dan kemudian, untuk perubahan, biarkan mereka mempertahankan basis kode yang ditulis dengan baik, dengan jadwal yang ketat.

Secara umum, keengganan untuk mengadaptasi standar tertentu berarti kurangnya pengalaman dalam kerja tim.

Pada akhirnya orang hanya belajar dari kesalahan. JANGAN PERNAH memperbaiki masalah, yang didasarkan pada sikap keras kepala orang lain. Jika itu sangat penting untuk proyek (yaitu perusahaan Anda akan dituntut jika Anda tidak melakukannya dalam N hari), maka tunda dulu proyek itu.


Aku suka ini. Resep yang bagus untuk membuat seseorang membenci Anda. ;)
Roman Zenka

@ Roman Zenka: Mungkin, ya. Tetapi jika pilihannya antara dibenci dan frustrasi, karena Anda memiliki NNPP di tim, saya lebih suka opsi pertama;)
back2dos

Pada titik ini, mereka harus menunda pembayaran gaji.
JeffO

Saya sebenarnya sudah mengusahakannya! Dan mereka tidak membenciku. Kesimpulannya adalah, semua orang nyaman dengan kotorannya sendiri. Dan itu membuat tugas ini sangat sulit.
Llistes Sugra

1

Saya pikir Anda programmer tidak akan mengubah sikap mereka terhadap masalah yang telah Anda sebutkan sampai mereka menyadari bahwa hal-hal itu akan membawa manfaat atau keuntungan bagi mereka. Coba jelaskan kepada mereka mengapa Anda ingin mereka melakukan hal-hal ini. Bahkan lebih baik, biarkan mereka merasakan kelebihannya.


1

Sewa satu Insinyur Perangkat Lunak profesional. Dan kemudian api terlemah. Lalu perlahan-lahan gantikan mereka yang tidak bisa mengadopsi. Memiliki orang-orang seperti itu terkadang membawa lebih banyak kerugian daripada keuntungan dalam jangka panjang.

Gagasan utama di sini, bahwa profesional akan mulai melakukan sebagian besar pekerjaan, dan memecat orang lain tidak akan mengurangi sumber daya manusia yang berharga.


1
Ini adalah cara yang bagus untuk menebus kurangnya keterampilan kepemimpinan dan kemampuan untuk membimbing individu yang kurang berpengalaman. Jika keterampilan persuasi Anda payah, mulailah menembakkan semua orang yang tidak setuju dengan Anda.
jmort253

@ jmort253, Jika saya punya kesempatan, saya akan memecat setiap programmer yang tidak melakukan kontrol versi secara teratur. Dari kata-kata penulis, saya mendapatkan bahwa SEMUA programmer sangat tidak berpengalaman, dan tidak ingin belajar dan meningkatkan diri.
Konstantin Petrukhnov

1

Agak kotor, tapi saya meninggalkan Kode Lengkap di kamar mandi selama beberapa bulan. Tidak yakin itu efektif, tetapi sepertinya ide yang bagus saat itu.


0

Jadi apa konsekuensi dari tidak mengikuti aturan dan penghargaan karena mengikuti aturan? Jika jawabannya sama - tidak ada - semoga berhasil mendapatkan traksi. Saya menyarankan pendekatan berjenjang. Pertama kumpulkan mereka dan diskusikan apakah mereka setuju dengan aturan. Langkah selanjutnya adalah memasukkannya dalam ulasan kode. Anda juga dapat mencoba wortel dan tongkat. Sesuatu seperti siapa pun yang meninggalkan file diperiksa semalam harus membawa donat ke pertemuan mingguan berikutnya. Wortel bisa siapa saja yang mengikuti aturan selama sebulan penuh mendapat akhir pekan di Vegas. Untuk dua.

Atau tembak pelaku terburuk dan biarkan sisanya mengeluarkan keringat.


Eeep! Anda memiliki tipe checkout tunggal VCS? Dapatkan dengan abad ini, man!
David Thornley

0

Buat mereka menderita akibat yang ingin Anda hindari dengan menggunakan aturan-aturan itu, itu satu-satunya cara mereka benar-benar akan mengerti mengapa Anda bertanya, misalnya: membuat kekacauan kecil yang terkontrol yang harus mereka perbaiki.


0

Jika kru ini benar-benar mengalami kesulitan memeriksa perubahan, mengikuti pemisahan kekhawatiran dan bukan konstanta sulap pengkodean keras maka saya akan memecat seluruh kru dan menggantinya dengan programmer nyata 1 yang benar-benar peduli dengan kerajinan mereka sesegera mungkin. Jadilah yang satu per satu atau secara massal yang tidak bisa saya katakan tetapi pelawak ini harus pergi.

Jenis pengkodean yang Anda gambarkan cocok untuk skrip dibuang, sekali pakai saja. Bukan bagaimana seseorang membangun aplikasi nyata. Jika mereka dibayar sebagai programmer profesional, maka tugas mereka untuk mengetahui hal semacam ini.


1 Ini sering digunakan sebagai istilah lelucon untuk orang imajiner yang menulis kode mereka secara langsung dalam biner atau sesuatu yang sama konyolnya. Di sini, saya tidak bercanda. Saya seorang programmer yang cukup pemula dan saya tidak perlu diberitahu hal-hal ini karena saya peduli dengan kerajinan saya. Ini bukan programmer nyata yang Anda hadapi.


Saya setuju dengan semuanya kecuali bagian yang menembak. Semoga berhasil menghapus setiap tugas penting yang sedang Anda kerjakan sebagai manajer, termasuk memenuhi tenggat waktu dan tonggak pelanggan, untuk mengganti seluruh staf berpengalaman Anda dengan orang-orang yang dapat berkomentar kode tetapi yang tidak memiliki pengetahuan domain.
jmort253

0

Pekerjaan manajer bukanlah menjadi teman karyawan, terkadang Anda harus menjadi penjahat. Menegakkan standar pengkodean dan melakukan, penolakan untuk mengikuti arsitektur yang diproksi, kegagalan untuk menggunakan alat yang ditentukan dll adalah saat-saat ketika Anda harus tidak populer.

Nyatakan kebijakan dengan jelas. Lakukan tinjauan kode formal dan periksa untuk melihat apakah kebijakan diikuti. Jangan izinkan mereka pindah ke tugas lain sampai semua masalah dari tinjauan kode diputuskan.

Jika kebijakan mengenai tidak melakukan kode, ini menyerukan peringatan tertulis jika mereka tidak dapat melakukannya ketika mereka diminta untuk melakukannya. Jika mereka tidak melakukan kode, sejauh yang Anda ketahui mereka belum menulis apa pun.

Jika mereka tidak membaik setelah diberi kesempatan yang masuk akal untuk meningkatkan, memecat mereka. Pengembang tidak profesional adalah hambatan dalam tim Anda, apa pun jenis kode yang mereka tulis. Mereka memengaruhi orang lain dengan kurangnya profesionalisme dan tidak bisa ditoleransi. Mereka bukan orang baik untuk dipertahankan dalam peristiwa apa pun. Pengembang yang baik melakukan kode mereka, pengembang yang baik mengikuti keputusan arsitektur bahkan jika mereka tidak setuju dengan mereka dan pengembang yang baik tidak melakukan hard code. Anda tidak akan kehilangan apa pun kecuali sakit kepala dengan menyingkirkan coder koboi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.