Desain yang saya usulkan biasanya lebih buruk daripada rekan saya - bagaimana saya menjadi lebih baik? [Tutup]

Saya telah pemrograman selama beberapa tahun dan saya umumnya baik ketika datang untuk memperbaiki masalah dan membuat skrip kecil-menengah, namun, saya umumnya tidak pandai merancang program skala besar dengan cara berorientasi objek. Beberapa pertanyaan

1. Baru-baru ini, seorang kolega yang memiliki pengalaman bertahun-tahun sama dengan saya dan saya sedang mengerjakan suatu masalah. Saya sedang mengerjakan masalah yang lebih lama darinya, namun, ia menemukan solusi yang lebih baik dan pada akhirnya kami akan menggunakan desainnya. Ini sangat mempengaruhi saya. Saya akui desainnya lebih baik, tetapi saya ingin membuat desain sebaik desainnya. Saya bahkan berpikir untuk berhenti dari pekerjaan itu. Tidak yakin mengapa tetapi tiba-tiba saya merasa di bawah tekanan misalnya apa yang akan dipikirkan para junior tentang saya dan lain-lain? Apakah ini normal? Atau saya terlalu banyak berpikir tentang ini?

2. Pekerjaan saya melibatkan pemrograman dengan Python. Saya mencoba membaca kode sumber tetapi bagaimana menurut Anda saya dapat meningkatkan keterampilan desain saya? Apakah ada buku atau perangkat lunak bagus yang harus saya pelajari?

Tolong beri tahu saya. Saya akan sangat menghargai bantuan Anda.

Saya pikir ini adalah tanda yang sangat positif dari keahlian Anda. Adalah jauh lebih umum bagi orang-orang yang mengalami kesulitan dalam mendesain desain 'lebih baik' dalam tim untuk sepenuhnya tidak mampu mengenali mengapa desain lain lebih baik.

Anda memiliki dua kekuatan yang luar biasa hebat (dan anehnya tidak biasa) untuk Anda:

• Anda mampu menilai desain Anda terhadap orang lain secara objektif
• Anda memiliki keinginan dan berusaha untuk membuat desain Anda optimal

Anda hanya beberapa tahun dan masih memiliki jalan panjang, tetapi dengan sikap ini Anda pasti akan sampai di sana, tapi jangan menyerah; kita semua berurusan dengan mental mundur seperti ini. Seringkali ketika saya mendapat kesempatan, saya suka memasang Prinsip Desain (TIDAK sama dengan pola desain) dan saya pikir ini adalah contoh sempurna dari mana mereka berguna. Pelajari dan praktikkan menerapkannya dalam desain Anda, Anda akan sebelum Anda tahu itu telah mengambil langkah maju dalam hal ini.

Pada akhirnya ingatlah, mendesain itu sulit. Kami berurusan dengan abstraksi tingkat tinggi yang kompleks setiap hari, untuk membuatnya dari udara tipis, membuatnya bekerja dengan baik, dan mudah digunakan oleh rekan kerja adalah tugas yang sangat sulit. Butuh latihan, selama bertahun - tahun .

Jadi, ingat dan ingat: ada banyak orang di luar sana yang tidak bisa menilai dua desain dan benar-benar mengenali satu lebih disukai daripada yang lain, seberapa baik menurut Anda mereka bergaul dalam menciptakan desain yang bagus?

Sunting:
'nother tip, setelah memahami prinsip-prinsip dan sedikit mempraktikkan aplikasi mereka, saya pikir ada permata lain dari pertanyaan lain di sini yang berbicara tentang nilai mempelajari berbagai bahasa yang memiliki tujuan dan aturan yang berbeda:

Idealnya, setiap programmer harus tahu bahasa dari masing-masing kelas. Apa yang bisa kamu pelajari:

1. Bahasa mainstream yang diketik OOP statis: Java, C # (kebanyakan digunakan dalam perangkat lunak perusahaan) dan C ++ (pemrograman sistem dan aplikasi desktop yang kompleks)
2. Bahasa OOP berbasis prototipe: Javascript (pemrograman sisi klien)
3. Bahasa prosedural: C (perangkat lunak tertanam dan pemrograman sistem)
4. Bahasa fungsional: Haskell, ML atau Lisp (bahasa fungsional baik untuk perangkat lunak yang sangat paralel).

Bahasa pemrograman logika (Prolog) mungkin tidak begitu berguna dalam industri, kebanyakan digunakan dalam penelitian di AI.

Ini akan membantu untuk memperluas berbagai ide yang muncul dalam pikiran ketika mencoba merancang solusi.

1. Ini benar-benar normal bagi banyak orang untuk menghasilkan desain dengan kualitas yang berbeda. Saya telah diundang di masa lalu untuk menilai kompetisi dalam desain perangkat lunak, jadi saya menyaksikan ini secara langsung: bahkan desain yang paling sederhana pun menghasilkan solusi dengan kualitas yang berbeda secara drastis, semua datang dari orang yang pintar dan berpengalaman.
2. Membaca kode sumber tingkat terlalu rendah untuk membantu Anda meningkatkan keterampilan desain Anda: kode alamat kompleksitas pada tingkat yang lebih rendah daripada desain keseluruhan.

Cara terbaik untuk meningkatkan dalam mendesain perangkat lunak adalah dengan mendesain perangkat lunak ^* . Salah satu cara untuk melakukannya adalah dengan melihat kompetisi desain: TopCoder memiliki arsip 100+ desain komponen, lengkap dengan dokumentasi desain UML dan implementasi di Jawa dan / atau C #. Ambil komponen jadi yang Anda suka, baca spesifikasi persyaratan, dan coba untuk membuat desain asli untuk memenuhi persyaratan. Luangkan satu atau dua jam untuk memikirkan masalah dan membuat sketsa diagram kelas, lalu buka desain yang menang, dan baca apa yang penulis lakukan. Bandingkan desainnya dengan milik Anda, cari perbedaannya, dan lihat apakah desain Anda lebih baik. Periksa kartu skor kompetisi untuk melihat bagaimana juri menilai desain. Ini akan memberi Anda umpan balik yang Anda butuhkan untuk memutuskan bagaimana meningkatkan keterampilan desain Anda.

Yah, jangan berhenti dari pekerjaan Anda. Lebih baik bekerja dengan seseorang yang memiliki keterampilan lebih baik daripada Anda, sehingga Anda bisa belajar darinya.

Lihatlah desain yang lebih baik dan tentukan mengapa itu lebih baik. Belajar dari desain yang diterima dan pikirkan cara-cara di mana Anda bisa menerapkan desain yang serupa dalam situasi lain. Setelah Anda tahu mengapa itu lebih baik daripada desain Anda, maka Anda tahu mistatke apa yang tidak membuat saat Anda melakukan desain. Bicaralah dengan pengembang lain dan tanyakan bagaimana dia membuat desain.

Untuk meningkatkan keterampilan desain, hal terbaik yang harus dilakukan adalah membuat desain, kemudian bersikap brutal dengan diri Anda sendiri dalam mengevaluasinya dan menentukan bagaimana mereka dapat ditingkatkan. Ajukan pertanyaan pada diri sendiri seperti: Apakah akan berfungsi dan apakah memenuhi persyaratan di semua aspek, apakah bisa dipertahankan, bagaimana saya bisa menguji ini, apakah itu akan menyebabkan masalah kinerja, seberapa besar kemungkinan persyaratan untuk berubah dan seberapa baik desain akan bisa menangani perubahan. Baca tentang pola desain dan cobalah menerapkannya pada desain Anda. Refactor tanpa ampun setelah datang dengan desain awal. Jika Anda mendesain database bersama dengan aplikasi, membaca secara luas tentang normalisasi dan kinerja tuning db, Anda akan belajar banyak tentang desain database jika Anda belajar bagaimana membuat database bekerja paling efektif dan efisien. Untuk aplikasi, pikirkan prinsip KERING dan SOLID dalam melakukan desain Anda. Baca tentang antipatterns untuk mengetahui hal-hal apa yang harus dihindari.

Mengenali desain yang lebih baik adalah kemampuan yang penting. Anda harus mengembangkan ini saat Anda mengikuti beberapa saran sebelumnya mengenai melihat desain.

Pada kriteria apa Anda menilai desain lain dengan lebih baik? Apakah lebih sederhana dan lebih mudah dipahami? Apakah itu memberikan keuntungan kinerja? Apakah lebih bisa diperluas? Ada banyak prinsip desain seperti penguraian, abstraksi, penyembunyian informasi, dan modularitas komponen yang dapat Anda gunakan untuk menilai desain dan yang mungkin sudah Anda kenali.

• Cobalah menyebutkan kriteria Anda, memahaminya, mengembangkannya dan menggunakannya kembali saat Anda melihat desain lain. Saat Anda mendesain sendiri, jadikan bagian dari proses Anda untuk menggunakan kriteria itu dan secara sadar mengukur desain Anda terhadapnya. Kemudian, bersiaplah untuk sepenuhnya mengubah atau membuang desain Anda jika tidak memenuhi kriteria Anda.

Anda akan mendapatkan ide-ide tentang prinsip-prinsip berbeda untuk desain dari beberapa sumber berikut: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Desain Perangkat Lunak di wikipedia Google "Prinsip-prinsip desain perangkat lunak"

• Memahami berbagai model untuk desain perangkat lunak, seperti Desain Berorientasi Objek atau Desain Fungsional atau Desain Analisis Terstruktur. Ini bisa menjadi pola pikir yang sama sekali berbeda dari yang mendekati tugas desain dan masing-masing memiliki area di mana mereka unggul. Pelajari ini sebagai alat untuk kotak alat Anda. http://userpages.umbc.edu/~khoo/survey2.html

• Pastikan Anda memisahkan desain dari implementasi, coba diagram hal-hal yang Anda lihat sebagai desain yang baik, untuk memisahkan bahasa dan spesifikasi implementasi dari prinsip-prinsip desain tingkat tinggi. Dan untuk mengembangkan "mata desain" dan kemampuan komunikasi Anda.

• Terakhir, tetapi mungkin yang paling penting, membaca secara luas adalah alat yang sangat bagus - ada banyak hal menarik mulai dari analisis Fraktal hingga Bayesian hingga Logika Fuzzy ke Pemrosesan Bahasa Alami, yang dapat menyediakan makanan bagi ide-ide yang akan muncul kemudian dan tidak terduga. Dengan web, Anda dapat membaca topik secara luas dan luas, hanya untuk hiburan dan perbaikan Anda dan itu akan bermanfaat. Anda tidak perlu menjadi ahli, cukup akrab dengan istilah dan ide.

Bersenang-senanglah - jangan lakukan itu jika Anda tidak menikmatinya setidaknya sedikit!

Nah, Anda sudah mengambil langkah pertama. Anda mengakui bahwa Anda memiliki sesuatu untuk dipelajari, bahwa pekerjaan kolega Anda lebih baik daripada pekerjaan Anda, dan Anda ingin belajar dan meningkat.

Langkah kedua adalah menganalisis. Lihatlah karyanya dan jangan hanya mengatakan bahwa itu lebih baik; mencari tahu mengapa itu lebih baik. Cari detail dan poin spesifik yang ia lakukan dengan lebih baik.

Setelah Anda memahami itu, ekstrak prinsip di baliknya. Ajukan pertanyaan seperti ini:

• Bagaimana dengan desain ini yang lebih baik dari desain saya?
• Apakah poin ini spesifik untuk desain ini, atau apakah itu prinsip umum yang dapat diterapkan pada desain lain di masa depan?
• Jika itu prinsip umum, apa batasannya? Kapan ide yang bagus untuk tidak melakukan hal-hal seperti ini? (Yang ini sangat penting. Ini mencegah Anda memperlakukan ide yang berguna sebagai palu emas , bahkan dalam kasus yang tidak pantas.)

Cobalah untuk mencari tahu sendiri, karena Anda akan menginternalisasi ide-ide lebih baik jika Anda datang dengan rantai penalaran yang membawa Anda pada kesimpulan sendiri, tetapi juga berbicara dengan rekan kerja Anda untuk memastikan Anda mendapatkan sesuatu Baik. (Anda tidak ingin membuat kesalahan dalam penalaran Anda dan menginternalisasi prinsip yang buruk, setelah semua.) Dan jangan ragu untuk meminta bantuan rekan kerja Anda jika Anda tidak dapat memecahkan masalah. Pemrograman adalah disiplin di mana kerendahan hati cenderung dihormati, dan banyak coders akan melompat pada kesempatan untuk mengajarkan seseorang sesuatu yang baru, yang mungkin merupakan bagian besar mengapa StackOverflow menjadi begitu besar begitu cepat.

Saya juga ingin menambahkan (selain jawaban yang bagus) bahwa ada lebih dari itu daripada "Dia dapat membuat desain yang lebih baik daripada saya". Jawaban lain fokus pada bagaimana Anda bisa menjadi lebih baik di Desain, yang semuanya dan bagus ... tapi ...

Saya bertaruh uang bahwa ANDA dapat melakukan sesuatu yang lebih baik daripada rekan kerja Anda. Bukan untuk membuat pertandingan kencing atau apa pun (Anda bisa melakukan Y lebih baik? Persetan, saya bisa melakukan X lebih baik!), Tetapi untuk menunjukkan kebenaran bahwa setiap orang memiliki kekuatan dan kelemahan.

Di pekerjaan saya ada 4 pengembang. Ada saat-saat di mana dua "programmer" utama dapat membuat hal-hal yang hanya membuat saya dalam debu. Membuat kepalaku berputar mencoba membungkus kepalaku di sekitar ciptaan mereka.

Tapi saya jauh lebih baik di SQL dan script-line scripting daripada mereka, dan dapat mengotomatisasi hal-hal yang membuat MEREKA dalam debu.

Apakah mereka lebih baik dari saya? Di beberapa daerah pasti. Ya ampun, di banyak daerah mereka - saya adalah pengembang junior di toko saya sejauh ini dan secara individual mereka memiliki pengalaman bertahun-tahun pada saya. Meskipun pengalaman bertahun-tahun, saya lebih baik di beberapa daerah daripada mereka.

Berhentilah berfokus pada fakta bahwa seseorang lebih baik di X daripada Anda. Orang itu, tanpa mencoba atau bahkan memikirkannya, mungkin dapat mendesain-out Anda bahkan setelah Anda mempraktikkannya selama 10 tahun ke depan. Bukan berarti Anda tidak harus memperbaiki kelemahan Anda sama sekali, tetapi ingatlah untuk setiap kekuatan ada kelemahan.

Fokus pada keduanya - Kekuatan dan kelemahan - Anda dan rekan kerja Anda.

Dalam setiap aspek kehidupan, Anda akan menemukan orang-orang yang tidak sebaik Anda, serta orang-orang yang lebih baik daripada Anda, terutama setelah hanya "beberapa tahun" pengalaman.

Anda harus belajar dari semua orang.

Jangan merasa buruk. Mungkin kolega Anda adalah hal yang wajar. Anda harus memberi selamat kepadanya dengan tulus dan belajar sebanyak mungkin dari dia.

Jangan biarkan profesional iri antara Anda dan peluang untuk belajar.

1. Beberapa tahun benar-benar tidak banyak. Dan daripada ada orang dengan tampilan desain tingkat tinggi yang lebih baik atau terburuk. Sebagai contoh, saya kenal orang yang mampu menulis algoritma yang kompleks untuk program tingkat rendah dalam sekejap mata tetapi tidak mampu memahami desain dan konsep tingkat tinggi seperti kohesi dan dependensi. Namun ini bukan keadaan de-facto. Baik Anda bisa mendapatkan yang lebih baik pada desain tingkat yang lebih tinggi (membaca beberapa buku, mencoba beberapa trik di rumah, dll) dan juga Anda mungkin menemukan bahwa di bidang pemrograman lain sesama programmer Anda kurang baik. Juga, jika Anda berpikir Anda memiliki tingkat yang sama baik dalam pengalaman dan pengetahuan teknis, ini mungkin memiliki situasi acak. Lain kali mungkin Anda memiliki ide desain yang lebih baik. Selain itu, alih-alih berhenti dari pekerjaan Anda, ambillah kesempatan ini dan belajarlah dari kolega Anda. Lain kali, lakukan desain bersama, mencoba menangkap rahasianya, pikirannya. Pemrograman seperti kerajinan, itu dipelajari dengan melakukan dan menonton orang lain melakukannya.

2. Keterampilan desain sebagian besar datang dengan pengalaman dan setelah Anda membaca beberapa buku penting. Saya akan merekomendasikan Anda yang berikut:

   • Robert C. Marting - Prinsip, Pola, dan Praktek Agile (ada 2 versi, satu di Jawa dan satu di C #. Tidak masalah mana yang Anda pilih, ide dan prinsip dapat diterapkan pada objek yang berorientasi - dan tidak hanya - Kode sumber)
   • Selain itu, Robert C. Marting memiliki 2 buku menarik lainnya: Clean Code dan The Clean Coder
   • Sekalipun Martin membahas semua pola desain modern di buku pertamanya, Anda ingin mencari buku pola desain asli karya Gang of Four.
   • Akhirnya, ada buku-buku lain yang sangat dihargai hari ini: Perangkat Lunak Berorientasi Objek Tumbuh Dipandu oleh Tes, atau Refactoring oleh M. Feathers (saya pikir), atau Menulis Kasus Penggunaan Efektif oleh A. Cockburn dan beberapa lagi Anda akan menemukan di jalan.

Tidak satu pun dari buku-buku ini adalah peluru ajaib, tetapi membaca 2 rekomendasi pertama mungkin akan mengubah pandangan dan persepsi Anda tentang pemrograman selamanya.

Jangan biarkan itu menghampiri Anda. Jika Anda memiliki pengalaman bertahun-tahun memperbaiki bug dan membuat program kecil, itulah yang akan Anda kuasai. Rekan kerja Anda mungkin memiliki pengalaman bertahun-tahun merancang proyek yang lebih besar.

Menjadi akrab dengan bit yang mendasarinya sangat berguna, tetapi jika Anda ingin menjadi lebih baik di desain, Anda harus merancang beberapa proyek. Ulangi sampai skill tenggelam.

Singkatnya, "pengalaman bertahun-tahun" tidak selalu setara. Pergi, buat tahun-tahun Anda berharga.

"Menjadi lebih baik" seringkali menyiratkan mengukur desain atau kode Anda terhadap sesuatu / seseorang yang lebih baik, dengan hati-hati membandingkan apa yang berbeda, belajar dari perbedaan itu, dan terus berusaha meningkatkan desain masa depan Anda berdasarkan itu. Merasa terlalu buruk mengetahui bahwa Anda perlu belajar lebih banyak akan memperlambat proses yang bermanfaat ini. Jika Anda pindah ke suatu tempat di mana tidak ada orang (atau sumber daya lainnya) yang kadang-kadang atau selalu dapat memberi Anda perbandingan yang lebih baik, Anda mungkin kehilangan kesempatan ini untuk belajar dan memperlambat proses taruhan Anda dengan lebih baik.