Bagaimana cara saya menangani kelumpuhan analisis?


61

Sangat sering, saya terjebak ketika memilih keputusan desain terbaik. Bahkan untuk perincian kecil, seperti definisi fungsi, aliran kontrol, dan nama variabel, saya menghabiskan waktu yang sangat lama meneliti manfaat dan pertukaran pilihan saya.

Saya merasa seperti kehilangan banyak efisiensi dengan menghabiskan waktu untuk detail-detail tidak penting seperti ini. Meskipun, saya tahu di belakang pikiran saya bahwa saya dapat mengubah hal-hal ini jika desain saya saat ini tidak berhasil, saya mengalami kesulitan memutuskan dengan tegas pada satu pilihan.

Apa yang harus saya lakukan untuk mengatasi masalah ini?



Diskusikan dengan seorang rekan di papan tulis. Ini sering membantu mengklarifikasi masalah ini dan jika Anda setuju maka itu memiliki peluang bagus untuk menjadi pilihan yang baik

Jawaban:


35

Dua aturan sederhana:

  1. Lakukan hal paling sederhana yang mungkin bisa berhasil.
  2. Refactor terus menerus.

Ketika Anda mulai melakukan masing-masing hal ini, Anda akan mendapatkan kepercayaan diri bahwa Anda dapat membuat keputusan sederhana sekarang tanpa mengurangi kemampuan Anda untuk merespons perubahan di kemudian hari.

Ingatlah bahwa pemeriksaan di masa depan berarti membuat kode mudah diubah, tidak mencoba mengantisipasi setiap cara yang mungkin perlu diubah oleh kode Anda.


4
Refactoring berkelanjutan hanya masuk akal jika Anda memiliki cakupan tes yang baik. Jadi saya akan mengatakan "Tulis unit test. Kemudian lakukan hal yang paling sederhana untuk membuat lulus tes. Refactor. Ulangi."
kevin cline

Setuju setuju. "Merah, hijau, refactor" adalah jalan yang harus ditempuh.
Rein Henrichs

5
Berita gembira kecil yang indah dari buku pegangan XP, tetapi saran yang benar-benar tidak bagus ketika diambil di luar konteks.
Aaronaught

2
Di luar konteks, secara harfiah setara dengan pengkodean koboi. Lihat Fowler's Is Design Dead? yang memperingatkan terhadap prinsip memetik ceri dari XP dan metodologi serupa. Mungkin Anda adalah perancang dan pembuat kode yang luar biasa dan secara intrinsik dan implisit mampu serta termotivasi untuk mempertahankan integritas konseptual saat melakukan refactoring, tetapi sebagian besar programmer tidak, dan memberi mereka saran ini di luar konteks tidak bertanggung jawab (walaupun mereka semua senang mendengarnya, karena itu berarti lebih sedikit pekerjaan untuk mereka).
Aaronaught

1
"Lakukan hal paling sederhana yang mungkin bisa berhasil" tidak memerlukan konteks tambahan. Refactoring memang, tetapi bagaimana seseorang yang tidak tahu konteksnya belajar bagaimana memperbaiki tetapi dengan mempelajari konteksnya?
Rein Henrichs

9

Biasanya ketika saya merasa seperti itu artinya saya perlu mencoba:

  1. Berdiri, berjalan, dan pastikan semua biologinya bekerja dengan baik.
  2. Pergi ke papan tulis dan menggambar sampai aku merasa percaya diri.
  3. Temukan "teman keluhan desain" yang bisa Anda ajak bicara.

Jika masalahnya melibatkan sintaks dan potongan kecil, maka:

  1. Puaskan diri Anda bahwa, meskipun jelek, ia dikemas dengan baik di suatu tempat, dan mewakili jenis cruft yang murni lokal.
  2. Tambahkan penanda TODO atau hanya komentar yang menjelaskan mengapa kode mengganggu Anda.
  3. Pindah ke tugas berikutnya.

+1 untuk yang pertama dan kedua # 2. Menggambar kotak, garis, dan pelabelan dan mendapatkan gambar besar biasanya membantu saya memutuskan di antara opsi. Jika Anda memiliki penganalisa kode yang bagus yang melacak tugas (Hudson dapat melacak TODO dan menampilkannya dengan baik di build Anda), Anda dapat dengan mudah melacak hal-hal yang tidak Anda sukai.
Randy

5

Sangat mudah untuk menganggap diri Anda tidak aktif. Bahkan jika Anda berhasil, entah bagaimana, untuk menghasilkan solusi terbaik saat ini yang dapat dengan mudah berubah sebelum Anda menyelesaikan proyek, dan kemudian apa?

Lebih baik memilih solusi yang layak dan menjalankannya, daripada duduk dan memikirkan apa solusi terbaik . Solusi terbaik adalah sulit dipahami dan lebih buruk, subjektif. Jika persyaratan berubah sedikit, solusi Anda mungkin berubah menjadi lebih buruk daripada solusi yang Anda buang karena itu bukan yang terbaik saat itu.


Saya sadar akan hal ini, tetapi saya masih kesulitan memilih satu pilihan.
Anne Nonimus

@anne: Lebih baik segera melakukan sesuatu yang konstruktif, daripada hal yang benar terlambat. Satu-satunya hal yang pasti salah adalah tidak melakukan apa-apa.
Satanicpuppy

4

Saya belajar untuk menghindari kelumpuhan analisis juga, jadi pujian kepada kami =) Ini sering terjadi karena kami ingin melakukan "desain terbaik". Pada kenyataannya, "terbaik" ada di mata yang melihatnya . Formula saya untuk menghindari kelumpuhan analisis, adalah menerapkan prinsip desain yang cukup baik . Bagaimana saya melakukannya? Saya membawa variabel seperti batasan waktu, jadwal dan bertanya pada diri sendiri apa desain paling sederhana yang dapat menyelesaikan pekerjaan (ini tidak berarti yang termudah) tanpa mengurangi kualitas, tetapi pada saat yang sama, saya memastikan bahwa itu dapat diuji dan sebuah terbuka untuk ekstensi ditutup untuk modifikasi (OCP)desain juga. Apa yang saya maksud dengan testable dan OCP? Yah, alih-alih mencari apa yang saya anggap terbaik, saya menganggap desain yang dapat memberi tahu saya ketika segala sesuatunya memburuk dan mencoba melakukan cukup kode yang memungkinkan saya untuk memperbaiki dan meningkatkan nanti. Juga, cobalah untuk memisahkan kode yang akan berubah dengan kode yang tetap sama. Refactoring menjadi lebih mudah, karena kode yang tidak seharusnya diubah lebih aman dari masa depan Anda, Anda atau orang lain.


2

Bagaimana dengan membiarkan nyali Anda memutuskan untuk salah satu opsi? Itu harus berjalan cukup cepat dan bergabung dengan baik dengan timeboxing , yang juga diusulkan ammoQ . Anda dapat mencoba batas 1 menit jika opsi sudah ditetapkan, atau 2 menit jika Anda harus menentukannya terlebih dahulu. Atau apa pun yang tampaknya sesuai (didefinisikan sebelumnya). Saat belajar mendengarkan naluri Anda, pilihan intuitif Anda akan menjadi lebih cepat dan lebih baik dengan latihan .

Jika Anda terganggu oleh kekhawatiran tentang kemungkinan memilih yang tidak sempurna, berikut adalah beberapa pemikiran untuk mengatasinya:

  • Jika ada opsi dengan keunggulan yang jelas di atas yang lain, Anda tidak akan bertanya pada diri sendiri mana yang harus dipilih. Jadi dengan alasan itu, setiap kali Anda ragu-ragu tentang beberapa pilihan pada masalah yang tidak terlalu rumit, itu menunjukkan bahwa semua opsi pada dasarnya sama; jadi tidak ada banyak ruginya dengan hanya memilih salah satu dari mereka.
  • Yang sedang berkata, intuisi tidak acak sama sekali, tetapi tebakan yang cukup baik dan berpendidikan untuk solusi optimal. Seringkali lebih baik daripada apa yang akan dihasilkan seseorang melalui pencarian tanpa akhir.
  • Melayani perfeksionisme, seseorang dapat menilai kecepatan keputusan lebih tinggi daripada optimalitas pilihan ketika secara semi-sadar mengevaluasi kinerja seseorang. Itu masuk akal sepenuhnya dengan pilihan-pilihan yang tidak penting, tetapi tidak sepele untuk diingat.

Semoga berhasil! :)


2

Saya pikir itu hilang dengan sedikit pengalaman. Sebagian besar kelumpuhan saya terjadi karena saya mencoba membayangkan basis kode apa yang akan terlihat lebih jauh ke depan daripada yang saya perlukan sehingga untuk mengatasinya saya hanya melakukan hal yang paling sederhana yang akan berhasil dan kemudian melanjutkan. Setelah proyek memiliki bentuk tertentu, unit kode berulang mulai menonjol dan cukup mudah untuk abstrak pola berulang dan menyederhanakan kode.


1

Untuk mengatasi keengganan Anda untuk memutuskan, gunakan timeboxing : atur jam alarm untuk berbunyi dalam beberapa menit; siksa pikiran Anda sampai saat itu, tetapi ketika alarm berbunyi, pilih opsi terbaik yang Anda temukan sampai saat itu.


3
Dan kemudian dia bisa menghabiskan berjam-jam menyiksa dirinya sendiri tentang berapa lama jam alarm seharusnya ditetapkan! :)
Jordan

1
Jordan: Ada beberapa solusi yang mungkin untuk masalah itu juga. Sayangnya, saya tidak bisa memutuskan mana yang akan diusulkan.
user281377

0

Buat prototipe. Ingat, prototipe dibuat untuk dibuang, jadi tidak masalah apa fungsi, nama variabel atau bahkan arsitektur besar yang Anda gunakan. Anda hanya membangunnya untuk membuktikan bahwa itu berhasil.

Setelah Anda membuatnya, dan membuangnya, saya berani bertaruh Anda akan lebih mudah membuat keputusan itu.


Anda tidak boleh membuang prototipe karena mungkin Anda bisa mengembangkannya nanti ketika Anda menambahkan fitur. Atau mungkin Anda perlu menguji bug dengan SSCCE. Saya selalu mengontrol sumber semua prototipe saya di tempat yang terpisah.
maple_shaft

2
Saya pikir ide di balik "membuang" bukanlah bahwa Anda kehilangan data, tetapi Anda tidak boleh menggunakan prototipe sebagai dasar untuk sebuah program karena seluruh inti prototipe adalah untuk bereksperimen dengan kebebasan untuk membuat kesalahan.
Darien

prototipe dalam cabang, lakukan pengujian yang diperlukan, dan buat versi bersih pada intinya.
zzzzBov

0

Saya menderita masalah ini juga. Apa yang akan saya katakan adalah bahwa Anda tidak memiliki insentif penyelesaian yang cukup.

Sebagai contoh, ketika saya sedang menulis kode rendering, maka saya memiliki insentif penyelesaian yang besar karena saya tahu bahwa jika saya melanjutkan, saya akan melihat sistem dalam aksi dan memikirkan betapa hebatnya saya untuk texturing quad, atau mengubah vert. Tetapi sekarang setelah saya memfaktorkan ulang (upaya 4, jika Anda ingin tahu) maka saya menderita karena ini banyak pekerjaan dan bahkan jika saya selesai, saya hanya akan melihat quad lama yang sama. Dan saya benar-benar tidak ingin harus refactor lagi dan saya muak melihat quad lama yang sama berulang-ulang, dan itu bukan hadiah untuk saya lagi.

Anda perlu memecahnya menjadi komponen dan hadiahi diri Anda sendiri untuk menyelesaikannya, bahkan jika hanya dengan beberapa konsol i / o yang menunjukkan bahwa itu berfungsi.


0

Saya sedang membaca pertanyaan Anda dan memikirkan hal-hal di sepanjang poster yang lain: Anda tidak cocok dengan pekerjaan ini; beri diri Anda batas waktu; lakukan sesuatu yang lain sejenak. Setelah beberapa refleksi, saya tidak yakin ada jawaban yang benar-benar bermanfaat

Masalah dengan masalah mental seperti ini adalah bahwa mereka tidak mudah dipecahkan, mereka adalah bagian dari Anda, dan jelas Anda peduli (terlalu banyak mungkin) tentang pekerjaan Anda, tidak memiliki kepercayaan diri untuk setuju dengan diri sendiri, terlalu tidak berpengalaman untuk mempertimbangkan bahwa Anda adalah pilihan pertama yang benar selama ini, atau terlalu banyak stres karena melakukannya dengan benar. Kenapa lagi Anda khawatir tentang hal sepele seperti itu ?!

Sekarang saya memiliki masalah yang sama, tetapi tidak dengan kode begitu banyak .. biasanya itu apa yang harus untuk makan malam .. pizza atau kari .. hmm ... pizza tapi kemudian kari bagus, tetapi apakah saya merasa seperti kari, pizza lebih murah , tapi kemudian kamu mendapatkan lebih banyak kari, tapi ... dan seterusnya. :)

Jadi saya pikir - mengapa saya tidak memiliki masalah yang sama dengan pengkodean, dan saya pikir itu hanya karena saya memiliki serangkaian pola yang saya gunakan secara teratur. Jika saya membutuhkan definisi fungsi, itu mudah .. itu akan berada dalam nada yang sama dengan setiap definisi fungsi lainnya yang pernah saya kodekan. Jika saya membutuhkan aliran kontrol, pertama-tama saya memutuskan apakah saya memerlukan loop for atau loop sementara dan kemudian membuat kode lama yang sama yang saya gunakan terakhir kali saya membutuhkan salah satu dari hal-hal ini. Hal yang sama berlaku untuk semuanya, apakah saya ingin antrian? Tentu - mari kita potong dan tempel kode antrian 'standar' saya (diarsipkan dari proyek terakhir yang saya kerjakan, atau yang saya ingat menggunakan salah satu dari hal-hal ini). Hasil akhirnya ... Saya hanya khawatir tentang hal-hal baru, dan jujur ​​saja, itu menyenangkan.

Jadi, saran saya adalah mulai membangun perpustakaan potongan kode - Saya dulu mengirim email kepada saya sendiri dan meletakkannya di folder tetapi apa pun yang Anda kerjakan adalah yang terbaik - dan Anda akan mulai tahu apa yang harus dilakukan setiap saat. Anda akan selalu pergi ke kode lama yang Anda tulis dan menyingkirkan masalahnya, siap untuk masalah berikutnya. Anda akan menemukan Anda menjadi pengembang yang jauh lebih cepat (serius, ini adalah satu-satunya cara untuk mendapatkan produktivitas programmer) dan mudah-mudahan akan menemukan waktu untuk bersenang-senang, bukan hal-hal suram sehari-hari yang telah Anda pecahkan berkali-kali lebih.

Tentu saja, bagian terakhir dari semua itu juga penting - semakin banyak pekerjaan yang Anda miliki, semakin sedikit kemewahan yang Anda habiskan untuk berpikir.


pemrograman potongan adalah jenis praktik terburuk yang terburuk
Neil Butterworth

@Neil: Menggunakan snippet orang lain sebagai pemrograman snippet, dan tidak tahu apa yang mereka lakukan, adalah praktik yang buruk. Menggunakan cuplikan kode Anda sendiri umumnya baik, karena sangat mungkin Anda memahami apa yang Anda tulis. Jika tidak, maka mungkin tidak ada harapan untuk Anda.
Jordan

@ Neil, Anda sedang dalam suasana hati yang sangat buruk hari ini! Sebagian besar pembuat kode senior memiliki perpustakaan snippet yang luas di kepala mereka, Anda hanya tidak memperhatikan diri Anda menggunakannya. Untuk seorang junior, menuliskannya membantu mereka membangun ini.
gbjbaanb

0

Berikut adalah strategi yang menggabungkan saran oleh Rein Henrichs ( mulai sederhana, refactor ) dan amunisi ( timeboxing ):

  1. Berikan batas waktu yang cukup ketat untuk solusi pertama yang hanya berfungsi. Misalnya 30 detik untuk nama variabel. Pertama-tama Anda bisa membuat sesuatu seperti x, kemudian memperbaikinya string, lalu namesampai waktunya habis.
  2. Kemudian lanjutkan ke tugas lain untuk beberapa waktu tertentu, misalnya 10 menit.
  3. Hanya dengan demikian biarkan diri Anda kotak waktu lain untuk lebih meningkatkan keputusan Anda, misalnya untukuserHandle

Kemungkinan manfaat dari pendekatan ini:

  • pengetahuan untuk kembali ke masalah ini nanti dapat memudahkan pelepasan masalah untuk saat ini
  • sambil melanjutkan tugas-tugas lain, Anda bisa saja memberikan solusi yang memuaskan tanpa perlu mencari-cari waktu
  • setelah melepaskan langkah 1 dan berada di aliran langkah 2 , mungkin akan mudah untuk menjaga langkah 3 benar-benar cepat, karena Anda ingin melanjutkan dengan langkah 2, dan dengan senang hati hanya memilih satu solusi yang layak dan menerimanya

Jawaban ini tampaknya lebih spesifik dan lengkap daripada jawaban Anda sebelumnya , tetapi keduanya tampaknya mencakup dasar yang sama. Silakan gabungkan menjadi satu atau pilih yang ingin Anda simpan.
Adam Lear

@Anna saya membuat dua posting terpisah, karena saya menemukan mereka mengandung ide konsep yang berbeda yang harus dipilih secara independen: Yang ini: melepaskan dengan menunda keputusan akhir. Yang sebelumnya: firasat. Memang kedua teknik berjalan dengan baik bersama, tetapi masing-masing juga bekerja tanpa yang lain.
Aaron Thoma

0

Ketika saya sudah melakukan penelitian dan dibiarkan tanpa pilihan terbaik yang jelas, saya memberi diri saya batas waktu (biasanya 5 menit) untuk memilih satu, kemudian hanya bergerak maju dengannya. Bahkan ketika Anda mengalami hambatan, pada titik ini, tidak ada jaminan, Anda tidak akan mendapatkan hambatan yang sama dengan membuat keputusan yang berbeda. Saya tidak bisa memikirkan saat saya menyesali keputusan saya.


0

Biasanya alasan Anda tidak dapat memutuskan adalah perbedaannya tidak signifikan, atau Anda tidak memiliki informasi yang cukup.

Dalam hal a) Tetapkan batas waktu untuk membuat opsi yang masuk akal untuk dipertimbangkan. Jangan memutuskan yang mana. Pada akhir waktu, pilih satu (secara acak jika tidak ada preferensi yang jelas) dari opsi yang diidentifikasi, dan batas waktu lainnya. Jika tidak ada keputusan yang jelas dibuat pada akhir waktu, yang sudah dipilih itu. Mulai kode, dan refactor jika Anda salah. Jika bos bertanya mengapa, katakan "Saya membalik koin, Anda punya cara yang lebih baik?"

Dalam hal b) - Anda memerlukan informasi lebih lanjut, dan duduk di atas A besar Anda yang gemuk .... sepanjang hari tidak akan menyediakannya. Keluar dari mode desain dan masuk ke mode pengumpulan informasi. Prototipe, ajukan pertanyaan, baca majalah teknis. Apa pun yang Anda lakukan, jangan tidur terlalu lama.


0

Seringkali, solusi terbaik adalah mencoba menjelaskan keputusan Anda kepada seorang kolega. Namun, karena Anda tidak ingin melakukan ini terlalu sering, hal terbaik berikutnya adalah berpikir di atas kertas - baik dengan kertas / pena, atau jendela notepad kosong.

Mulailah dengan menulis apa pun - hanya untuk mengikuti ritme penulisan. Di jendela notepad Anda cukup mengetik "Saya sedang berpikir di atas kertas" dan kemudian melanjutkan dengan aliran kesadaran. Setelah beberapa detik, Anda akan berada dalam ritme penulisan, jadi tekan enter beberapa kali, dan mulailah menjelaskan dilema Anda.

Nyatakan masalahnya, lalu nyatakan solusi yang mungkin, apa yang baik dari masing-masing, dll.

Meskipun tidak selalu berhasil, proses mengeluarkan pikiran dari kepala Anda (RAM) dan ke media eksternal (dokumen notepad) memberi Anda lebih banyak kebebasan untuk membuat koneksi baru, dan melihat keputusan dari berbagai perspektif.


0

Saya menderita masalah yang sama. Untuk masalah kecil, cara saya mencoba mengatasinya adalah dengan pergi dengan desain pertama yang saya pikir itu tidak bodoh. Tidak ada gunanya mencari desain yang optimal; sulit jika bukan tidak mungkin untuk beralasan tentang semua nuansa desain yang mungkin Anda pikirkan tanpa menuliskannya. Ketika Anda kode, Anda akan menemukan bahwa Anda dapat membuat perbaikan kecil. Dilakukan dengan benar, saya merasa cukup mudah untuk menyatu pada solusi yang cukup bagus dengan cara ini.

Untuk masalah yang lebih besar, saya pikir ada manfaat dalam memikirkan opsi Anda terlebih dahulu, tetapi timebox itu. Masalah besar memiliki ruang solusi besar, Anda tidak dapat mengevaluasi setiap kemungkinan, Anda juga tidak harus mencoba.

TLDR; Pilih solusi yang masuk akal, perbaiki saat Anda pergi.

Ini juga relevan:

Guru keramik mengumumkan pada hari pembukaan bahwa dia membagi kelas menjadi dua kelompok. Semua yang berada di sisi kiri studio, katanya, akan dinilai hanya berdasarkan jumlah pekerjaan yang mereka hasilkan, semua yang di sebelah kanan semata-mata pada kualitasnya. Prosedurnya sederhana: pada hari terakhir kelas ia akan membawa timbangan ke kamar mandi dan menimbang pekerjaan kelompok "kuantitas": pot lima puluh pon diberi nilai "A", empat puluh pon "B", dan seterusnya. Namun, yang dinilai berdasarkan "kualitas" hanya perlu menghasilkan satu pot - meskipun pot yang sempurna - untuk mendapatkan "A".

Nah, tibalah saat penilaian dan fakta aneh muncul: karya-karya dengan kualitas terbaik semuanya diproduksi oleh kelompok yang dinilai berdasarkan kuantitas. Tampaknya sementara kelompok "kuantitas" sibuk mengaduk-aduk tumpukan pekerjaan - dan belajar dari kesalahan mereka - kelompok "kualitas" telah duduk berteori tentang kesempurnaan, dan pada akhirnya memiliki sedikit lebih banyak untuk ditampilkan untuk usaha mereka daripada teori muluk dan setumpuk tanah liat mati.

dari http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .


-8

Saya tidak pernah mengerti ini. Ketika saya seorang instruktur, saya akan mengatakan sesuatu seperti:

"OK, create an integer variable and assign the return value of strlen() to it."

Tidak terlalu rumit, Anda mungkin berpikir, dan 95% orang menulis sesuatu seperti:

int x;   // or y, or len, or whatever
x = strlen( s );

Tetapi terkadang ada orang yang duduk seperti kelinci yang lumpuh di lampu depan. Saya dengan penuh simpati akan bertanya apa masalahnya, dan mereka akan berkata, "Saya tidak tahu harus menyebutnya apa!".

Inilah orang-orang yang harus mencari karier lain. Seperti yang seharusnya Anda lakukan.


2
@Anne, saya tidak membuat asumsi - Anda sendiri mengatakan Anda merasa sulit untuk memikirkan nama untuk hal-hal - "Sangat sering, saya terjebak ketika memilih keputusan desain terbaik. Bahkan untuk detail kecil, seperti ... nama variabel"
Neil Butterworth

3
Dan mengapa saya harus mencari karier lain karena saya kesulitan menyebutkan beberapa hal? Tidak setiap konsep memiliki pemetaan singkat yang bersih ke bahasa alami.
Anne Nonimus

2
@ Anne Dorongan pertanyaan awal Anda tampaknya bagi saya adalah bahwa Anda mengalami masalah melakukan apa yang secara alami bagi programmer yang baik. Tidak ada rasa malu dalam hal ini - kebanyakan orang (bahkan kebanyakan programmer!) Jelek dalam melakukan hal-hal ini. Namun, dengan asumsi bahwa seperti saya Anda hanya bisa bahagia melakukan sesuatu yang benar-benar Anda kuasai, saya menyarankan agar pemrograman tidak sesuai dengan yang Anda inginkan. Saya menghabiskan 10 tahun pertama kehidupan dewasa saya sebagai ahli mikrobiologi. Saya tidak begitu mahir dalam hal itu, dan jauh lebih bahagia ketika saya berubah menjadi seorang programmer.
Neil Butterworth

3
Pengingat yang ramah untuk semua: jika Anda tidak setuju dengan jawabannya, jangan ragu untuk menggunakan downvotes untuk mengekspresikannya. Serangan pribadi dari kedua sisi akan dihapus.
Adam Lear

3
Pada akhirnya, saya merasa bahwa jawabannya keluar dengan agak kasar, tetapi komentar itu membuat saya merasa itu tidak terlalu keras. Mungkin Anda harus mengeditnya.
DeadMG
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.