Memberikan presentasi tentang "gaya kode dan pola desain" [ditutup]


9

Perusahaan saya (kecil, sekitar 40 orang di 3 kantor) kadang-kadang melakukan "lokakarya pengembang" online di mana salah satu pengembang mengadakan presentasi tentang beberapa topik teknologi. Ini tidak selalu tentang pekerjaan kita, tetapi hanya untuk membantu semua orang meningkatkan keterampilan dan pemahaman mereka.

Saya telah diminta untuk menjadi tuan rumah yang berikutnya, dan topik (dipilih dari daftar yang saya berikan) adalah gaya kode dan pola desain. Saya tahu hal-hal itu tidak terkait erat tetapi bersabarlah. Saya telah melihat banyak tempat dalam basis kode kami yang dapat ditingkatkan, beberapa yang bahkan mungkin memenuhi syarat untuk DailyWTF, jadi saya ingin presentasi ini seefektif mungkin. Masalahnya adalah saya tidak tahu persis apa yang harus saya bahas dalam satu jam.

Gagasan pertama saya adalah menggunakan kode kita sendiri sebagai contoh, untuk membawa pulang poin "tolong terapkan ini pada pekerjaan Anda." Tapi topiknya sangat luas.

Beberapa hal yang salah dengan kode kami (PHP) meliputi:

  • Minimal OO. Sudah membaik akhir-akhir ini, tetapi masih ada banyak fungsi global. Butuh beberapa saat untuk menemukan hal-hal.
  • Konfigurasi global (pendapat saya kira). Anda dapat menemukan $ GLOBALS ['bla'] yang tersebar di hampir setiap file.
  • Gaya penjepit tidak konsisten. Kedengarannya minimal, tetapi ini sebenarnya menyebabkan kesalahan sintaks didorong ke asal lima hari yang lalu, yang masih belum diperbaiki sampai kemarin.
  • Konstruksi tidak efisien. Saya dapat melakukan beberapa perbaikan dasar yang mengurangi waktu berjalan di beberapa daerah hingga 70%.

Saya ingin hal ini bermanfaat, tanpa terdengar merendahkan rekan kerja saya. Jadi aspek "gaya" apa yang harus saya fokuskan, dan pola desain mana yang paling berguna untuk dijelaskan?


1
Ini adalah topik yang terbuka sehingga sulit untuk sampai pada kesimpulan yang solid. Saya akan mencoba menjelaskan bahwa maksud dari presentasi ini adalah untuk membuat rekan kerja Anda menyadari masalah saat ini, daripada meyakinkan mereka untuk mengikuti standar tertentu. Mengapa Anda tidak mencantumkan poin yang Anda buat dalam pertanyaan Anda, dan memberikan contoh mengapa ini adalah praktik yang buruk dan konsekuensi yang mungkin terjadi yaitu utang teknis. Juga menyebutkan alat-alat seperti ReSharper dan FxCop mungkin.
Tidak ada yang

Jawaban:


8

Berhati-hatilah menggunakan kode asli dalam presentasi di depan orang-orang yang menulis kode ini.

Paling-paling Anda akan mengecewakan tim Anda dengan mengarahkan jari ke arah mereka di depan semua orang. Dan yang akan Anda dapatkan alih-alih "Anda benar-benar membuka mata saya" adalah "WTF di depan semua orang? Apakah Anda bahkan melihat kode Anda sendiri dumbA .."

Ambil contoh nyata tetapi modifikasi atau pastikan itu tidak dapat dilacak kepada siapa pun yang menulisnya. Atau ambil kode asli dari orang yang Anda kenal tetapi juga ambil beberapa kode lama ANDA dan mainkan humor dan lelucon dalam dengan orang-orang ini, gaya standup :)

Untuk menjawab pertanyaan awal Anda: Segala sesuatu yang berkaitan dengan kewajaran: fungsi dengan sesedikit mungkin argumen, OOP, nama variabel panjang dan terinci serta komentar.


2
+1: peninjauan kode adalah operasi rumit yang membutuhkan diplomasi, dan kebijaksanaan, dan tidak boleh digunakan untuk tujuan demonstrasi dengan sendirinya.
Matthieu

4

Saya menduga Anda memiliki sistem pelacakan bug di organisasi Anda. Tarik keluar beberapa bug paling menjijikkan dari repositori, lihat laporan perbaikan tentang mengapa hal itu terjadi (variabel global menjadi serba salah, fungsi melakukan hal-hal yang tidak dimaksudkan dll) dan kemudian membahas gaya pengkodean dan pola desain yang dapat membantu menghindari masalah ini .

Ini adalah kerja keras untuk melakukan sedikit riset ini, tetapi ini adalah cara terkuat untuk membawa pulang apa yang Anda sajikan benar-benar bekerja .


2

"Masih banyak fungsi global".

Pertama, dapatkan daftar. Lengkap itu ideal.

Kedua, partisi daftar ini menjadi kelas-kelas potensial. Pikirkan tentang definisi kelas.

Selama presentasi aktual, pilih kelas potensial terbesar, paling jelas, paling mencolok, paling tidak bisa diperdebatkan yang akan menyerap banyak fungsi global tersebut.

Sebagai topik diskusi. Anda punya ide. Anda perlu mendapatkan konsensus. Dan jawab pertanyaan di sepanjang jalan. Dan bantu mereka memahami mengapa ini adalah satu kelas objek, bukan sekelompok fungsi acak yang berbagi global.

Kemudian, setelah membahas ini sampai pada titik di mana mereka mengerti hanya kelas ini dan bagaimana Anda sampai pada isinya ....

Nyalakan proyektor.

Mulai mengetik.

Perbaiki kodenya. Jalankan kembali tes unit Anda.

Desain pola dan gaya penulisan dan pekerjaan yang dikerjakan. Semua dalam satu paket.


2

dalam 1 jam Anda akan berhasil dengan baik untuk mendapatkan pemahaman dasar yang minimal.

saya sarankan pilih 3 hal dari setiap topik dan fokuslah pada itu; batasi slide menjadi 5-7 kata sehingga orang mendengarkan Anda alih-alih membaca slide; gunakan contoh-contoh buatan (jadi Anda tidak menginjak-injak orang, sesuai saran orang lain); berikan referensi di bagian akhir (URL lebih baik daripada buku) sebagai latihan untuk mereka yang ingin belajar lebih banyak; memposting slide Anda di intranet Anda setelah presentasi Anda. (Adapun masalah kawat gigi, gunakan pemformat kode; itu mungkin bukan pertempuran yang layak diperjuangkan)

Topik yang disarankan:

  • Gaya Pengodean

    • Zen OOP dalam PHP: Pengodean Dengan Gaya!
    • 5 Alasan Mengapa Fungsi Global Menyebabkan Kode Kanker
    • Apa yang ada di Nama? Kebiasaan dan Akal Sehat (atau Jangan Membuatku Berpikir!)
  • Pola desain

    • Beberapa Pola GoF dalam Kode Kita; sebuah Pendahuluan
    • Pola hanyalah alat, bukan Injil
    • Yang Terbaik dan yang Terburuk: Pola dan Anti-Pola

catatan: konfigurasi global terkadang sulit untuk dihindari; satu solusi mudah adalah dengan meletakkan semua referensi kepada mereka dalam fungsi init

peringatan: Saya hanya tahu cukup PHP untuk memecahkan wordpress dan melakukan perbaikan situs web kecil


1

Tentang menggunakan kode nyata dalam presentasi - jika digunakan, gunakan saja untuk contoh yang baik, TIDAK PERNAH contoh yang buruk. Untuk yang buruk, buat sendiri, atau temukan di web. Ini memungkinkan rekan kerja Anda bangga dengan pekerjaan mereka dan mendapatkan pengakuan untuk itu. Itu juga menghindari skenario di mana mereka mungkin marah / malu karena dipilih sebagai pengembang yang buruk.


0

Gaya pengkodean adalah kebiasaan buruk. Sulit untuk dihilangkan. Cara terbaik untuk membiarkan seseorang meninggalkan kebiasaan buruk? Biarkan dia melihat sendiri betapa jelek, menjijikkan atau berbahaya itu.

Tunjukkan pada mereka kode yang buruk, tanyakan kepada mereka apa yang buruk tentang itu. Biarkan mereka berpikir sejenak, lalu beri mereka "Aaahaaa!" saat dengan menunjukkan mereka kasus tepi (masalah Fencepost, mungkin?) atau kasus di mana desain buruk mereka runtuh segalanya.

Orang-orangmu menderita masalah desain yang buruk, sepertinya. Tunjukkan pada mereka satu contoh bagaimana suatu fungsi global berubah dengan cara yang tidak bersalah merusak fungsi-fungsi lain bergantung padanya, tetapi tidak mengetahui bahwa itu diubah. Tunjukkan pada mereka masalah sinkronisasi klasik dengan variabel global.

Apakah itu dengan cara yang lucu untuk melibatkan mereka, alih-alih membuat mereka bosan atau membuat mereka mengambil posisi bertahan (siapa orang ini yang mengkritik kita?); misalnya menunjukkan kepada mereka fungsi yang melakukan tugasnya dalam dua langkah (1 - masukkan nama istri) (2 simpan di global) (3-masukkan nama suami dan ambil nama istri dari global untuk disimpan dalam database) (4- tertawa seperti hasil sinkronisasi yang buruk pada pria yang memiliki istri 'baru'), ketika lelucon mengusulkan penulisan fungsi statistik perceraian.

Percaya bisa mendapatkan pemikiran tentang gaya pemrograman, karena kami memprogram apa yang kami pikirkan, dan ketika desain pemrograman dikritik beberapa orang menganggapnya sebagai penghinaan terhadap cara berpikir mereka dan karenanya kecerdasan mereka, jadi Anda harus mengambil pendekatan yang menyenangkan untuk itu.

Ambil fungsi buruk Anda, sembunyikan dengan beberapa perubahan agar tidak mempermalukan pemilik kode, dan bekerja & berinteraksi dengan audiens untuk memperbaikinya. Hasil: Sistem kontrol kode sumber Anda keesokan paginya akan sangat sibuk, jadi ambil kopi dan tersenyumlah di log perubahan.

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.