Kelas penamaan menjadi melemahkan [ditutup]

Saya tidak yakin apakah ini adalah sifat OCD atau tidak, tetapi saya menemukan bahwa kadang-kadang saya benar-benar diblokir tidak dapat melanjutkan apa yang saya lakukan ketika memberi nama kelas (atau fungsi, atau namespace dll) yang saya percaya akan digunakan di luar dari proyek yang diberikan. API misalnya. Atau perpustakaan kelas utilitas.

Jika penamaannya tidak tepat (dalam pikiran saya) saya tidak bisa melanjutkan ... Saya macet ketika mencoba mencari nama yang tepat. Saya sudah mencoba menulis aplikasi kecil yang akan menggunakannya untuk melihat seperti apa nama-nama itu tetapi itu sepertinya tidak membantu ...

Saya tahu itu seharusnya tidak masalah, dan itu bertentangan dengan pola pikir pemrograman untuk menganggap Anda akan sempurna pertama pergi ... Saya hanya merasa tidak berdaya untuk itu ...

Setiap tips / ide akan sangat dihargai ...

Menurut saya masalah yang Anda miliki bukan hanya menemukan cara yang lebih baik untuk menghasilkan nama-nama baik, tetapi juga berurusan dengan keharusan untuk melakukannya. Jika saya jujur, saya mengenali sifat yang sama dalam diri saya. Lagipula nama-nama itu penting, dan aku suka nama yang bagus untuk konsep yang sedang kukerjakan. Namun, mereka tidak selalu merupakan hal yang paling penting.

Berikut adalah beberapa metode yang saya gunakan untuk mengatasi hal semacam ini:

1. Ketahuilah bahwa tidak ada solusi yang sempurna, hanya solusi yang lebih baik dari yang lain.
2. Dahulukan hal pertama. Lebih penting untuk menyelesaikan tugas pemrograman daripada melakukannya dengan sempurna.
3. Tanyai orang lain. Kita semua memiliki wilayah di mana kita menjadi macet, tetapi untungnya orang yang berbeda macet di tempat yang berbeda. Mungkin orang lain akan datang dengan nama baik, atau memberi tahu Anda bahwa itu sebenarnya tidak masalah.
4. Tetapkan batas waktu. Beri diri Anda x menit untuk melakukan hal yang membuat Anda terpaku, lalu lanjutkan.
5. Berjanjilah pada diri sendiri bahwa Anda akan kembali lagi nanti. Simpan catatan tentang hal-hal yang ingin Anda kembalikan. Banyak dari masalah-masalah ini menjadi lebih jelas ketika Anda membiarkannya sendirian sebentar. Entah Anda akan menemukan nama yang lebih baik nanti, atau Anda akan menyadari bahwa itu sebenarnya tidak masalah.
6. Ketahuilah bahwa dalam waktu 100 tahun, tidak ada yang peduli.
7. Lakukan yang sebaliknya. Beri kelas nama yang benar-benar buruk, dan lihat apa yang terjadi. Ini akan mengkonfirmasi kebutuhan untuk menghabiskan waktu untuk nama-nama yang lebih baik, atau menunjukkan kepada Anda betapa sedikitnya itu benar-benar penting. Juga, ini akan membantu Anda keluar dari pola pikir obsesif.
8. Berdoa. Ini sering berhasil bagi saya.
9. Hargai diri Anda terpisah dari apa yang Anda lakukan. Tinggalkan ide bahwa nilai Anda berasal dari memberikan kesempurnaan. Ketika kita menyadari bahwa kita memiliki nilai intrinsik, terlepas dari pekerjaan kita, kita merasa kurang malu ketika kita tidak memenuhi standar kita sendiri.
10. Buat kata-kata baru dan gunakan untuk memberi nama kelas Anda, atau hanya mengarahkan yang lama. Pemrograman adalah proses kreatif, dan terkadang ide yang kami tangkap adalah ide baru. Gagasan baru membutuhkan nama baru. "EmployeeTransmogrifier" adalah nama yang benar-benar valid untuk sebuah kelas.
11. Pertimbangkan bahwa Anda sedang mencoba menyelesaikan masalah yang salah. Sebagai contoh, itu bukan ide yang baik untuk menulis API tanpa ide yang sangat jelas tentang apa kebutuhan pemanggil. Jika Anda memecahkan masalah ini, masalah penamaan Anda mungkin jauh lebih mudah.
12. Makan siang. Makan siang selalu enak.

pertama

Tanyakan kepada diri Anda pertanyaan "apa tujuan tunggal kelas ini?". Tanpa mematuhi Prinsip Tanggung Jawab Tunggal, penamaan kelas dan metode menjadi sangat sulit. Jika Anda tidak dapat menjawab pertanyaan itu, Anda mungkin perlu memikirkan kembali apa yang Anda inginkan dari kelas, dan pertimbangkan untuk memisahkan masalah. Ini akan memudahkan untuk memberi nama

Kedua

Apakah Anda memiliki pola bagaimana Anda memberi nama kelas Anda? Mungkin coba lihat beberapa pola penamaan yang umum, misalnya polanya, yang menjadi lebih mudah diikuti setelah Anda membahas SRP di atas. Apakah kelas Anda menguraikan XML? Coba XMLParser. Apakah ini mem-parsing XML, membuat model domain untuk mewakili input, bertahan mereka ke DB dan kemudian memposting pesan sukses ke Twitter? Coba refactoring.

Ketiga

Saya mengerti dari mana Anda berasal, dan pernah berada dalam situasi yang sama sebelumnya. Mungkin coba menyempurnakan kelas Anda dengan beberapa fungsi, dengan nama sementara untuk memulai. Dengan IDE yang bagus atau asisten refactoring, mengganti nama kelas harus menjadi tindakan satu-klik, jadi apa yang Anda beri nama kelas Anda awalnya tidak perlu permanen! Ini akan membantu Anda melewati blok OCD Anda, dan memberikan waktu bawah sadar Anda untuk memprosesnya sedikit lebih jauh.

Akhirnya dan sedikit keluar dari topik

Saya mengalami momen bola lampu dalam beberapa pekerjaan yang saya lakukan kemarin, menerapkan sistem yang tidak kritis, dan saya menghabiskan waktu yang adil untuk bermain-main dengan penamaan kelas yang berbeda dll ... Beri nama antarmuka Anda sesuai dengan fungsinya, beri nama Anda kelas sesuai dengan penerapan spesifik mereka ... Misalnya, Anda mungkin tergoda untuk memiliki IXMLParser dan XMLParser, tetapi apa yang terjadi ketika input Anda berubah ke JSON? Coba IInputParser sebagai gantinya, dengan cara itu Anda dapat membuat kelas konkret XMLParser dan JSONParser yang keduanya mengimplementasikan IInputParser dengan cara yang berbeda.

Bagi saya itu biasanya tanda desain tidak jelas dalam pikiran saya, jadi saya membuat nama, dan memberi diri saya waktu (katakanlah 2 menit) untuk datang dengan yang lebih baik, pada akhir waktu itu, saya harus gunakan yang saya buat dulu. Barney, Wilma dan Fred adalah favorit untuk memulai. Saya melakukan hal-hal seperti "BarniesInputParser" Nama-nama itu sangat buruk sehingga saya harus membuat yang lebih baik atau mengubahnya nanti. Mereka juga sangat buruk mereka unik, membuat refactoring sepele dan aman, dan siapa pun yang melihat kode yang tidak lengkap dapat melihat secara instan itu tidak lengkap.

Yang penting adalah bahwa sementara Anda tidak menambahkan fungsionalitas, Anda tidak memberi otak Anda informasi baru untuk digunakan untuk mendefinisikan nama (dan memperjelas desain). Yang Anda lakukan hanyalah memuntahkan input yang sama dengan cara yang berbeda.

Atau pergi membuat kopi. Sebelum Anda sampai ke mesin Anda akan memilikinya ...

Saya mendapatkan ini dari seorang teman beberapa waktu lalu. Tuliskan apa yang seharusnya dilakukan oleh proses Anda. Hanya sebuah narasi singkat. Kemudian mengambil kata benda dan mengubahnya menjadi kelas, kata kerja menjadi metode, dan kata keterangan menjadi properti.