Di mana tim saya harus mulai dengan menjadi "modern"? [Tutup]


106

Saya adalah pengembang yang relatif baru, baru dari perguruan tinggi. Sementara di perguruan tinggi dan selama pencarian kerja berikutnya, saya menyadari bahwa ada banyak metodologi pengembangan perangkat lunak "modern" yang kurang pendidikan saya: pengujian unit, logging, normalisasi basis data, pengembangan tangkas (vs. konsep tangkas generik), gaya pengkodean panduan, refactoring, ulasan kode, tidak ada metode dokumentasi standar (atau bahkan persyaratan), dll.

Secara keseluruhan, saya tidak melihat ini masalah. Saya mengharapkan pekerjaan pertama saya untuk merangkul semua ide ini dan mengajarkannya kepada saya di tempat kerja. Kemudian saya mendapatkan pekerjaan pertama saya (pengembangan web penuh tumpukan) di sebuah perusahaan besar dan saya menyadari bahwa kami tidak melakukan hal-hal ini. Sebenarnya saya, yang paling tidak berpengalaman dalam tim, adalah orang yang mempelopori upaya untuk mempercepat tim saya dengan teknik pemrograman "modern" - karena saya khawatir tidak melakukannya adalah bunuh diri profesional di ujung jalan.

Pertama saya mulai dengan perangkat lunak logging (log4J), tetapi kemudian saya dengan cepat pindah ke menulis styleguide saya sendiri, kemudian meninggalkannya untuk Google styleguide - dan kemudian saya menyadari bahwa pengembangan web Java kami menggunakan pengontrol depan yang ditulis tangan, jadi saya mendorong untuk adopsi kami pada Spring - tetapi kemudian saya menyadari bahwa kami juga tidak memiliki unit test, tetapi saya sudah mempelajari Spring ... dan seperti yang Anda lihat, itu menjadi luar biasa terlalu cepat, terutama ketika dipasangkan dengan pekerjaan pengembangan normal. Selain itu, sulit bagi saya untuk menjadi "ahli" cukup dalam metodologi ini untuk mengajar orang lain di dalamnya tanpa mencurahkan terlalu banyak waktu untuk satu pun dari mereka, apalagi mereka semua.

Dari semua teknik ini, yang saya lihat sebagai "diharapkan" di dunia pengembangan perangkat lunak saat ini, bagaimana saya mengintegrasikan mereka ke dalam tim sebagai pemain baru tanpa membebani diri saya dan tim?

Bagaimana saya bisa memengaruhi tim saya untuk menjadi lebih gesit? terkait, tapi saya bukan pengembang Agile seperti penanya di sini, dan saya melihat serangkaian metodologi yang lebih luas daripada Agile.


92
"modern"? Keluarkan kata kunci "gesit" dari daftar Anda dan saya hanya dapat melihat hal-hal dengan usia> 20 tahun.
Doc Brown

10
Mungkin "modern" dalam arti bahwa adopsi yang meluas dari mereka adalah modern, bukan asal usul ide, kalau begitu? Saya juga bukan ahli dalam hal ini , ini hanya kesan saya.
WannabeCoder

41
Saya yakinkan, Anda, pengujian unit, pencatatan, normalisasi basis data, panduan gaya pengkodean, inspeksi kode (= ulasan) semuanya lebih dari 30 tahun. Istilah "refactoring" setidaknya berusia 15 tahun (Fowler menulis bukunya pada tahun 2000). Dan tidak memiliki dokumentasi formal atau persyaratan tertulis bukanlah "teknik modern", itu adalah IMHO bahkan bukan "teknik".
Doc Brown

69
@DocBrown mengakuinya, Anda baru saja mengirim Marty kembali pada waktunya untuk membuat semua hal ini sebelum membuat komentar Anda.
null

17
Saya lebih khawatir bahwa kuliahnya tidak mengajarkan hal-hal itu di muka - Saya sudah 15 tahun lebih dari sekolah dan sebagian besar hal-hal itu dibahas cukup awal. (Kurang kata kunci, tentu saja).
Allen Gould

Jawaban:


165

Kedengarannya bagi saya seperti Anda meletakkan kereta di depan kuda.

Apa masalah utama yang dihadapi tim Anda dan teknologi mana yang akan membantu memperbaikinya?

Misalnya, jika ada banyak bug, terutama bug tipe regresi, maka pengujian unit mungkin merupakan titik awal. Jika tim Anda kekurangan waktu, mungkin kerangka kerja dapat membantu (jangka menengah hingga panjang). Jika orang kesulitan membaca kode masing-masing, penataan mungkin berguna.

Ingatlah bahwa tujuan bisnis tempat Anda bekerja adalah untuk menghasilkan uang, bukan untuk membuat kode.


35
Kurang lebih. Sebagian dari titik pragmatis harus mulai dari suatu tempat dan sebagian lagi dari titik reputasi bahwa jika Anda dapat memperbaiki masalah bagi tim, mereka mungkin lebih bersedia mendengarkan saran lain. Juga ingat bahwa perusahaan ini menghasilkan uang sebelum Anda datang dengan metode yang ada, jadi apa yang Anda tempatkan harus meningkatkan kemampuan menghasilkan uang perusahaan.
Jaydee

6
Menerima ini, tetapi saya akan sangat menghargai tindak lanjut untuk mengatasi risiko ini secara profesional (misalnya, "resume saya akan memiliki lebih banyak barang, tetapi pekerjaan lama saya tidak menerima perubahan dengan baik.")
WannabeCoder

4
@WannabeCoder - Anda harus mulai menggunakannya sebelum Anda menjadi mahir. Anda masih dapat memasukkan kode ke dalam produksi. Terkadang pengkodean seperti menjadi seorang dokter medis. Kita semua masih berlatih.
JeffO

5
Jawaban yang bagus Anda seharusnya hanya menerapkan hal-hal ini untuk menyelesaikan masalah, bukan untuk membuat masalah.
Kik

5
@WannabeCoder Sangat penting untuk menyadari bahwa tidak ada metodologi yang dibuat dalam ruang hampa. Mereka menjadi tersebar luas karena mereka membantu menyelesaikan masalah . Jika Anda mencoba menerapkannya dan itu tidak membantu menyelesaikan masalah yang dihadapi tim Anda, maka Anda tidak mencapai apa pun dan mungkin sepenuhnya salah paham dan menyalahgunakan praktik tersebut. Fokus Anda sebagai pengembang harus menyelesaikan masalah dalam setiap tindakan yang Anda lakukan. Carilah kemenangan kecil di mana menerapkan praktik-praktik ini sedikit lebih banyak akan memperbaiki situasi. Ini membantu membangun kasus untuk mengembangkannya.
jpmc26

77

Jawa? Modern?! Anda gagal pada rintangan pertama. Jika Anda ingin benar-benar modern dan menghindari "bunuh diri profesional" maka Anda harus menulis kode Rust. Tentu saja, minggu depan, semuanya akan berubah dan Anda harus belajar sesuatu yang lebih baru untuk mengikuti!

Atau, Anda dapat menerima bahwa tidak ada sejumlah teknologi atau metodologi atau kerangka kerja kata kunci atau du jour lainnya yang akan mengubah fakta bahwa Anda ingin membangun produk berkualitas yang berfungsi. Tidak masalah jika Anda tidak menggunakan gesit jika Anda berhasil menghasilkan output yang tepat. Tentu saja, jika tidak, maka Anda mungkin ingin mengubah beberapa hal tetapi kemungkinan tidak ada latihan khusus yang akan memperbaiki masalah. Mereka akan tetap menjadi masalah manusia yang dapat diperbaiki dengan berbagai cara.

Adapun bunuh diri profesional, jika Anda tahu apa yang Anda lakukan dan fleksibel maka Anda tidak perlu hal-hal yang Anda sebutkan. Orang-orang akan terus menemukan cara-cara baru untuk melakukan pekerjaan lama dan Anda akan selalu mengejar ketinggalan. Atau Anda bisa menggunakan teknik apa pun yang digunakan perusahaan Anda saat ini. Ketika Anda mengubah perusahaan Anda, Anda cukup belajar dan menggunakan teknik yang mereka gunakan.

Terlalu banyak anak yang terpaku pada semua alat baru yang bisa mereka gunakan, lupa bahwa alat ini tidak berharga di tangan seorang pemula. Pelajari praktiknya terlebih dahulu, begitu Anda adalah pengembang yang berpengalaman, Anda dapat mulai "memperbaiki" praktik pengembangan dengan "hal-hal baru yang keren", tetapi pada saat itu Anda diharapkan telah menyadari bahwa itu tidak sepenting yang Anda pikirkan, dan hanya digunakan ketika mereka benar-benar dibutuhkan.


4
Jawaban yang sangat bagus (+1), terutama paragraf terakhir. Sebuah buku yang sangat modern (modern dalam arti yang saya rasa sangat relevan hari ini) yang saya baca baru-baru ini adalah SICP.
Giorgio

1
+1 untuk menyebutkan seberapa cepat buzzword dan bahasa populer ini berubah. Seorang pengembang yang baik mengeluarkan kode yang baik mengalahkan metodologi apa pun. Lakukan apa yang berhasil dan bekerja dengan baik!
WeRelic

2
Meskipun Anda benar bahwa ini perlu digunakan dengan benar, saya tidak setuju dengan gagasan bahwa "mereka tidak sepenting yang Anda pikirkan saat ini." Oke, tentu, itu mungkin benar untuk beberapa praktik (saya agak skeptis terhadap pengujian unit.), Tetapi yang lain sangat berharga. Saya mendapat kesempatan untuk mulai melakukan banyak CI dan otomatisasi dan penggunaan kontrol sumber yang baik sejak awal, dan sekarang mengerjakan proyek di mana itu tidak ada, saya melihat semua masalah yang ingin kami pecahkan dalam tindakan: kesalahan, inkonsistensi , tidak ada yang tahu kode apa di mana, kerjanya. Praktik-praktik itu membuat perbedaan besar .
jpmc26

6
Tidak ada yang mengatakan "jangan selesaikan masalah", masalahnya adalah ketika solusi diperkenalkan mencari masalah untuk dipecahkan. Mereka tidak sepenting yang dipikirkan banyak orang, para pemuja kargo menganggap alat adalah bagian penting, di mana mereka sebenarnya hanya alat. Adalah praktisi yang penting, dan alat apa pun yang bekerja di tempat yang tepat adalah yang harus dipilih. maksud saya adalah untuk tidak pernah memilih alat hanya karena ada di kotak alat.
gbjbaanb

2
Orang bodoh dengan alat masih bodoh.
Pete Becker

40

Banyak perusahaan terjebak seperti ini; Anda bahkan mungkin terkejut mendapati bahwa beberapa kolega pengembang Anda belajar sendiri dan menjadi pengembang tanpa latar belakang formal apa pun. Pengembang ini sering kali lebih baik dalam pekerjaannya, karena merekalah yang akan terdorong untuk mempelajari keterampilan baru dan sukses alih-alih hanya melakukan pekerjaan itu. Sayangnya ini juga bisa berarti bahwa, meskipun mereka sangat baik dalam pemrograman, mereka mungkin tidak menyadari manfaat dari praktik-praktik ini. Faktanya adalah ini adalah praktik terbaik , bukan praktik umum . Yang terbaik menggunakannya, tetapi mereka sama sekali tidak persyaratan untuk berhasil, mereka hanya alat untuk membantu membuat kesuksesan lebih mudah.

Anda benar sekali, akan sangat sulit untuk mencoba mengimplementasikan semuanya sekaligus. Anda mungkin akan membakar diri Anda (dan mungkin tim Anda) karena berusaha melakukannya, yang akan menurunkan motivasi masa depan untuk mengadopsi metodologi / teknologi baru. Hal terbaik untuk dilakukan dalam situasi seperti ini adalah memilih satuhal (logging mungkin merupakan awal yang baik, karena Anda mungkin punya jalan sulit di depan menemukan bug tanpa login, dan pasti ada bug) dan bicarakan dengan tim tentang hal itu. Anda tidak harus menerapkan ini sendirian; Anda akan lebih baik mendiskusikan pro dan kontra dengan tim (dan bos Anda, yang benar-benar HARUS berada di papan dengan sesuatu seperti ini) dan membuat rencana untuk mengimplementasikannya. Ini akan harus semudah mungkin (ingat, Anda memberitahu orang-orang bahwa sekarang mereka harus menulis ekstra kode selain apa yang sudah mereka lakukan).

Dan biarkan saya katakan lagi, pastikan bos Anda membeli . Ini sangat penting; Anda mungkin akan menemukan bahwa kecepatan perbaikan / rilis melambat saat Anda menerapkan hal-hal baru. Intinya adalah bahwa Anda membayar dimuka untuk menghemat garis; mereka HARUS memahami ini dan berada di pihak Anda. Jika Anda tidak mendapatkan mereka di papan, Anda berjuang di pertempuran yang kalah terbaik, dan paling buruk mereka mungkin menganggap Anda secara aktif menyabotase tim (tanyakan kepada saya bagaimana saya tahu).

Setelah Anda membawa barang-barang ini ke meja, diskusikan dengan tim, rencanakan cara mengimplementasikannya, dan tindak lanjut, yang kedua, ketiga, kedelapan, dll. Akan lebih mudah. Tidak hanya itu, ada potensi bagi tim dan atasan Anda untuk mendapatkan rasa hormat kepada Anda karena saran Anda diterapkan dan diakui sebagai nilai tambah. Bagus! Pastikan Anda tetap fleksibel: Anda berusaha melawan kelembaman di sini, dan perubahan itu tidak mudah. bersiaplah untuk perlahan menjadi kecilperubahan, dan pastikan Anda dapat melacak kemajuan dan nilai yang diperoleh. Jika Anda menerapkan proses masuk dalam proses baru dan ini membantu Anda menghemat waktu menemukan bug dalam tiga minggu, buat masalah besar tentang itu! Pastikan semua orang tahu bahwa perusahaan baru saja menghemat $ XXX dengan melakukan hal yang benar sebelumnya. Di sisi lain, jika Anda mendapatkan pushback, atau memiliki tenggat waktu yang ketat, jangan mencoba memaksakan masalah tersebut. Biarkan perubahan baru meluncur untuk saat ini, dan putar kembali. Anda tidak akan pernah menang dengan mencoba memaksa tim untuk melakukan sesuatu yang tidak ingin mereka lakukan, dan Anda dapat yakin bahwa hal pertama yang mereka sarankan untuk dijatuhkan adalah pekerjaan 'ekstra' baru (seperti menulis logging, atau mengikuti sebuah styleguide alih-alih hanya 'membuatnya bekerja').


6
Aku ragu kamu sangat berarti dengan itu, tapi aku agak membenci omong kosong di devs seperti aku tanpa pendidikan universitas compsci. Pengalaman saya (agak sayangnya) adalah bahwa pendidikan universitas memiliki sedikit korelasi dengan kualitas pengembang. Dan sejauh ini dalam karir saya, saya telah menjadi salah satu dari mereka yang mengadvokasi dan menerapkan praktik terbaik. Saran Anda sangat bagus.
djeikyb

5
Sebenarnya saya maksudkan sebaliknya: OP akan terkejut dengan berapa banyak dev yang baik di luar sana tanpa pendidikan formal. Banyak posisi teknologi dibuka dalam 20/30 tahun terakhir yang diisi oleh orang-orang yang mau belajar daripada anak-anak dengan gelar. Dan temuan saya mencerminkan milik Anda: pengalaman selalu lebih baik daripada pendidikan. Itu sebabnya OP perlu berjalan lambat ... mendorong tim untuk mengadopsi praktik baru terlalu cepat akan membuat mereka membencinya, dan dia tidak akan memiliki pengalaman untuk meredam sikap itu. Juga penting untuk disadari adalah beberapa tim tidak akan pernah menggunakan alat ini; saat itulah Anda mendapatkan pekerjaan baru.
DrewJordan

1
"Banyak perusahaan terjebak seperti ini; Anda bahkan mungkin terkejut menemukan bahwa beberapa rekan 'pengembang' Anda otodidak dan menjadi pengembang tanpa latar belakang formal apa pun." Ini sering berubah menjadi pengembang paling berharga karena keahlian domain mereka.
PMF

Benar, saya setuju sepenuhnya. Ulang paragraf pertama sehingga terdengar kurang merendahkan. Saya hanya ingin memastikan bahwa OP tahu bahwa sebagian besar tenaga kerja di luar sana sebenarnya tidak memiliki latar belakang formal. Pilihan kata yang buruk di pihak saya.
DrewJordan

18

Saya harap Anda belum menyampaikan masalah ini kepada rekan kerja Anda seperti yang Anda lakukan pada kami di pos Anda. ITULAH bunuh diri profesional.

Masalah pertama adalah bahwa Anda mencoba untuk mengajarkan teknologi dan metode yang bahkan Anda tidak memiliki pengalaman dengan sekelompok programmer itu, mungkin agak ketinggalan jaman, tetapi mendapatkan pekerjaan "selesai". Kemungkinan bumerang itu tidak terbatas, dan mungkin akan membawa banyak kegembiraan bagi rekan kerja Anda. Sangat menarik dan mengagumkan bahwa Anda ingin meningkatkan diri dan departemen Anda, tetapi hindari menggunakan istilah seperti "ujung tombak". Hormat kami, jangan gunakan kata itu.

Sebagai masalah sampingan di atas, periksa apakah Anda melakukan beberapa pekerjaan . Saya telah bekerja sebagai programmer mandiri yang belajar sendiri untuk banyak waktu, dan saya tahu betapa mudahnya mengesampingkan pekerjaan yang sebenarnya untuk mengeksplorasi kerangka kerja yang menjanjikan, teknologi dan sejenisnya. Pastikan diri Anda bahwa kinerja Anda berada dalam parameter yang diharapkan (tidak, tidak ada yang peduli bahwa Anda menghabiskan 20 jam meneliti Musim Semi jika laporan yang mereka tanyakan tidak selesai).

Dari semua hal di atas, hindari menjadi guru (kecuali jika itu terkait dengan bidang / teknologi di mana sebenarnya Anda memiliki cukup pengalaman). Presentasi yang lebih netral akan menunjukkan keuntungan, katakanlah, pengujian otomatis, dan membiarkan manajemen memilih siapa yang mereka inginkan untuk meneliti pro dan kontra dari praktik-praktik tersebut.

Sekarang, untuk menyajikan "praktik terbaik" itu, ada dua cara untuk menjelaskannya kepada tim Anda:

  • Karena saya katakan bahwa itu adalah praktik terbaik, dan itu sudah cukup.
  • Karena mereka berguna dan membantu menyelesaikan masalah.

Menggunakan argumen pertama, kecuali Anda adalah bos atau anggota tim yang sangat senior, kecil kemungkinan mereka akan memberi Anda perhatian. Dan "Saya membaca buku dari Knuth yang mengatakan demikian" atau "orang-orang dari SE mengatakan bahwa" tidak akan menimbulkan kesan, juga ("orang-orang itu tidak bekerja di sini sehingga mereka tidak benar-benar tahu apa yang baik untuk toko IT ini. "). Mereka memiliki metode, rutinitas, prosedur, dan hal-hal yang "kurang lebih" berfungsi, jadi mengapa mengambil upaya dan risiko perubahan?

Agar pendekatan kedua berhasil, harus ada kesadaran bahwa ada masalah . Begitu:

  • jangan memaksakan siang dan malam untuk pengujian otomatis. Tunggu hingga pembaruan merusak beberapa fitur, dan tim harus bekerja lembur untuk memperbaikinya, lalu mengusulkan untuk membangun sistem pengujian otomatis.
  • jangan meminta ulasan kode. Tunggu sampai Joe dalam cuti panjang dan ada kebutuhan untuk mengubah dalam modul yang hanya diketahui oleh Joe, dan tunjukkan kepada bos Anda berapa banyak waktu yang hilang hanya untuk mencoba memahami kode Joe.

Tentu saja, perubahan akan lambat dan progresif (lebih-lebih dalam perusahaan besar). Jika Anda bisa memperkenalkan tinjauan kode dan pengujian otomatis dalam lima tahun, Anda harus memberi selamat kepada diri sendiri atas pekerjaan yang dilakukan dengan baik. Tetapi, kecuali ada penulisan ulang yang lengkap karena sebab-sebab eksternal, lupakan fantasi apa pun yang akan mereka ubah menjadi IS inti, katakanlah, Spring ( Joel menjelaskan cara itu lebih baik daripada yang pernah saya bisa, bahkan sebelum Anda dilahirkan 1 ); pada saat itu Anda bisa, paling banyak, memasukkan Spring ke daftar platform yang didukung untuk menulis sistem yang tidak kritis.

Selamat datang di dunia perusahaan IT, nak! :-p

1 : Ok, mungkin aku sedikit bersemangat, tapi tidak terlalu banyak.


1
Sebagian besar tidak setuju. Satu-satunya cara untuk mendapatkan perubahan dalam tim adalah jika seseorang bersedia melakukan penelitian dan menyeret sisanya. Tentu saja Anda harus tetap produktif, tetapi jika semua orang menundukkan kepala, Anda akan "sedikit ketinggalan zaman, tetapi Anda menyelesaikan pekerjaan". Dan benar-benar terbakar karena bosan.
winkbrace

@winkbrace Saya tidak mengklaim bahwa Anda seharusnya tidak mencoba untuk meningkatkan (pada kenyataannya saya menyatakan sebaliknya). Tetapi mendorong perubahan-perubahan itu tanpa dukungan manajemen dan tanpa otoritas dari beberapa senioritas mungkin cukup sulit dan menyebabkan perlawanan; menambah bahwa OP tidak cukup ahli sendiri dan mungkin memiliki masalah dengan implementasi yang sebenarnya. Alangkah baiknya jika OP dapat menjadi sukarelawan ke tim penelitian / prototyping untuk secara tepat memperkenalkan perubahan; tetapi melarang bahwa dia harus berhati-hati dalam memilih pendekatan yang tepat untuk mempromosikan mereka dan bersabar.
SJuan76

@winkbrace untuk sedikit kebosanan, itu tergantung pada kepribadian Anda dan apa yang Anda cari dalam pekerjaan. Masuk akal untuk mencoba mendarat di posisi pekerjaan yang memuaskan Anda, daripada pergi ke mana saja dan mencoba mengubah organisasi sesuai selera Anda. Dan biasanya perusahaan besar (kecuali untuk departemen R&D) bukan tempat bagi orang yang suka menguji teknologi baru setiap beberapa bulan.
SJuan76

Agak kacau mengatakan "pastikan Anda benar-benar melakukan pekerjaan". Tentu Anda harus melakukan pekerjaan tetapi Anda juga harus berpikir jangka panjang dan setiap hari Anda harus meningkat. Butuh 5 bulan bagi saya untuk membuat manajer kami memahami fakta bahwa unit test membantu bahkan ketika kami mencoba untuk kode "cepat". Tapi saya perlu mengambil 10 menit di sana-sini setiap beberapa hari untuk itu terjadi.
Rudolf Olah

@omouse Saya hanya menunjukkan risiko yang kadang-kadang mengenai diri saya, ketika melakukan penelitian. Tentu saja saya tidak melihat risiko dalam situasi yang Anda gambarkan, tetapi bentuk OP menggambarkan penelitiannya ("pertama saya mulai dengan ... lalu saya cepat pindah ...") membuat saya menambahkan kehati-hatian itu. Perhatikan bahwa saya tidak mengklaim bahwa OP tidak melakukan pekerjaan yang ditugaskan dengan benar (itu adalah sesuatu yang saya tidak tahu, dan itu adalah tugas bosnya), saya hanya memperingatkan dia untuk memastikan bahwa dia tidak terlalu terbawa suasana .
SJuan76

12

Anda harus mulai dengan buku Bekerja Efektif dengan Kode Legacy oleh Michael Feathers. Dari pengantar buku, "Ini tentang mengambil sistem yang kusut, buram, berbelit-belit dan perlahan-lahan, sepotong demi sepotong, langkah demi langkah, mengubahnya menjadi sistem yang sederhana, terstruktur dengan baik, dirancang dengan baik." Dia kebanyakan memulai dengan pengujian otomatis, sehingga Anda dapat melakukan refactor dengan aman (Anda akan tahu jika Anda memecahkan apa pun), dan dia memasukkan banyak strategi untuk membawa kode yang sulit di bawah pengujian otomatis. Ini berguna untuk setiap proyek yang masih dalam pengembangan. Setelah Anda mendapatkan beberapa pesanan dasar, Anda dapat melihat teknologi modern apa yang benar-benar diuntungkan oleh proyek Anda - tetapi jangan menganggap Anda membutuhkan semuanya.

Jika Anda ingin mempelajari kerangka kerja baru (atau sesuatu) untuk alasan profesional daripada karena proyek Anda saat ini benar-benar membutuhkannya, maka Anda harus menggunakannya dalam beberapa proyek pribadi (pada waktu Anda sendiri).


Saya setuju dengan topik dalam Bekerja Secara Efektif dengan Kode Legacy tetapi tidak terlalu kompak. Ambillah sebagai referensi dan lihat bab-bab daripada berharap untuk membacanya seperti novel.
Lukas

10

Kontrol sumber.

Anda tidak menyebutkannya, semoga karena sudah ada di tempat, tetapi, kalau-kalau tidak, mulai dari sana.

Kontrol sumber memiliki dampak terbesar, kecuali dalam keadaan langka yang secara patologis membutuhkan sesuatu yang lain.

Dan Anda bisa mulai sendiri jika awalnya tidak ada yang membeli.


1
Bang-for-buck terbesar lebih seperti beberapa ASSERT di tempat yang tepat.
Peter Mortensen

@PeterMortensen Benar, tetapi hanya jika Anda tahu tempat yang tepat.
Emilio M Bumachar

Anda mengalahkan saya untuk itu. Tidak peduli ke arah mana OP membawa timnya, pergi ke sana bersama Git akan jauh lebih mudah dan lebih produktif daripada tanpa.
dotancohen

6

Jawaban Langsung

Jawaban lain memberikan 'meta-poin' yang baik tentang penerapan praktik yang lebih baik, tetapi, hanya untuk memberi Anda beberapa panduan yang relevan secara langsung, berikut ini adalah urutan kasar praktik terbaik yang saya sarankan untuk diterapkan tim Anda (atau tim mana pun) (pertama):

  1. Kontrol sumber
  2. Pelacakan masalah (manajemen proyek dan tugas)
  3. Pembuatan otomatis 1
  4. Penyebaran otomatis

1 Praktik yang sangat terkait adalah mengotomatisasi, atau setidaknya mendokumentasikan , menyiapkan lingkungan pengembangan dan pengembangan dari setiap aplikasi atau proyek perangkat lunak yang Anda kembangkan atau pelihara. Ini jauh kurang berguna karena Anda (mudah-mudahan) jarang melakukan hal ini atau jarang.

Yang lainnya

Anda menyebutkan beberapa praktik baik lainnya - "pengujian unit, pencatatan, normalisasi basis data, ... refactoring, ... dokumentasi" - tetapi ini semua adalah praktik yang dapat dan harus diadopsi secara bertahap dan bertahap. Tak satu pun dari mereka perlu diadopsi sekaligus dan Anda mungkin akan lebih baik mengadopsi mereka sama sekali dengan mengadopsi mereka dengan hati-hati dan penuh perhatian.

Keempat praktik yang saya sebutkan di atas juga akan membuat mengadopsi, dan bereksperimen dengan, praktik baru semudah mungkin. Misalnya, pengujian unit dapat dimasukkan ke dalam bangunan otomatis Anda dan dokumentasi dapat dipublikasikan sebagai bagian dari penyebaran otomatis Anda.

Beberapa praktik lain yang Anda sebutkan - "pengembangan lincah, ... panduan gaya pengkodean, ... ulasan kode, ... metode dokumentasi standar" dan kerangka kerja (misalnya Musim Semi) - benar-benar opsional atau memiliki nilai yang meragukan. Dan itu benar dari banyak (kemungkinan?) Kemungkinan praktik yang akan Anda temukan atau temui.

Pengembangan lincah jelas tidak unggul dari metodologi lain yang digunakan. Dan banyak orang (termasuk saya) memiliki pengalaman mengerikan dengannya. Tetapi banyak orang benar-benar menyukainya (atau menyukainya) juga. Cobalah!

Panduan gaya pengkodean dapat membantu, terutama untuk proyek-proyek besar, atau dalam tim besar, tetapi juga banyak pekerjaan untuk menegakkan pedoman tersebut dan yang mungkin bukan penggunaan waktu terbaik bagi siapa pun yang melakukannya.

Ulasan kode juga dapat sangat membantu - sudahkah Anda meminta rekan kerja Anda untuk meninjau kode Anda? Ingatlah bahwa Anda tidak memerlukan proses formal untuk mengadopsi praktik yang baik!

Dokumentasi hebat - apakah Anda punya? Jika demikian, bagus untuk Anda! Apakah Anda menghadapi banyak pekerjaan tambahan yang dapat dicegah dengan memiliki (lebih banyak) dokumentasi "standar"? Jika ya, maka itu mungkin sesuatu yang layak dilakukan. Namun, katakanlah jika perangkat lunak Anda digunakan oleh sekelompok kecil orang, Anda mungkin tidak memerlukan dokumentasi apa pun . (Atau Anda dapat langsung memasukkan dokumentasi ke dalam perangkat lunak Anda. Itu selalu pilihan saya.)

Kerangka adalah ... pedang bermata dua (sangat tajam). Solusi enkapsulasi dan terawat dengan baik untuk fitur non-inti perangkat lunak Anda sangat bagus ... sampai tidak. Saya tidak yakin apa sebenarnya "pengontrol depan tulisan tangan" tetapi tidak ada penjelasan yang jelas mengapa mereka lebih rendah dari kode yang memanfaatkan Spring. Sudahkah Anda mempertimbangkan merangkum logika umum dalam semua pengontrol ini ke dalam kerangka kerja in-house Anda sendiri? Mengadopsi Pegas, dan menulis ulang semua kode Anda yang ada, bisa menjadi proyek refactoring yang sangat besar (atau, lebih mungkin, menulis ulang) dan itu mungkin bukan perubahan terbaik yang dapat Anda lakukan pada kode Anda . Tentu saja Anda tidak boleh menulis semua perangkat lunak yang Anda gunakan - kerangka kerja (dan perpustakaan) sangat bagus!Tapi mungkin Anda tidak harus menggunakan Spring (atau alternatif) untuk menulis aplikasi web yang hebat (atau bagus).


Saya akan menempatkan pengujian regresi otomatis di atas sana dengan membangun dan penyebaran otomatis. Ini juga memiliki keuntungan bahwa itu adalah sesuatu yang dapat Anda kerjakan secara bertahap.
sdenham

Pengujian unit harus menjadi yang pertama, mulailah dengan secara manual selalu menjalankannya secara lokal (atau pada setiap checkout / checkin) dan kemudian dapatkan seluruh tim untuk membeli ke dalam pengujian regresi otomatis. Benar-benar ada dev yang takut menjalankan tes terus-menerus karena alasan tertentu.
Rudolf Olah

5

Lihatlah ke sekeliling tim yang menjadi bagian Anda. Dapatkah Anda melihat bukti bahwa pengembangan yang didorong oleh pengujian atau normalisasi basis data akan meningkatkan kualitas perangkat lunak yang Anda tulis atau membuat orang lebih produktif?

Sudahkah Anda mencoba berbicara dengan salah satu pengawas pembangunan tentang hal itu, atau kepala pengembangan? Obrolan yang benar-benar informal akan menjadi awal yang baik. Apa yang membuat Anda berpikir bahwa orang-orang di atas Anda belum memiliki ide yang sama tetapi tidak dapat / tidak akan mengimplementasikannya karena bisnis tidak akan mengizinkannya?

Saya menemukan bahwa memimpin dengan memberi contoh adalah cara yang baik untuk dilakukan. Orang-orang jauh kurang tahan jika orang lain telah melakukan pekerjaan dan dapat menunjukkan kepada mereka bagaimana mereplikasi itu. Perkenalkan TDD ke dalam proyek yang sedang Anda kerjakan. Mintalah untuk memberikan presentasi kepada seluruh anggota tim, atau bahkan beberapa orang lain dan tunjukkan kepada mereka apa yang telah Anda lakukan. Apa yang dikatakan @DrewJordan tentang menerima pembelian dari bos lebih penting daripada yang mungkin Anda sadari.


5

Temukan cacatnya. Perbaiki cacat. Tunjukkan perbaikannya.

Mari lakukan normalisasi * terlebih dahulu. Dan memang, saya sarankan Anda mengambilnya dulu, karena kurangnya normalisasi kemungkinan akan menghasilkan data kereta yang sebenarnya yang tidak bisa ada sebaliknya, sedangkan sisanya adalah kasus di mana praktik terbaik mungkin bisa membantu tetapi lebih sulit untuk mengatakan "Bug A disebabkan oleh tidak mengikuti kebijakan X ". Jika Anda memiliki database yang tidak dinormalisasi, maka Anda memiliki tempat di mana data bisa tidak konsisten.

Ini adalah taruhan yang bagus bahwa Anda akan dapat menemukan kasus aktual dari data yang tidak konsisten. Anda sekarang telah menemukan dua hal:

  1. Bug dalam data Anda.

  2. Bug dalam skema database Anda.

Anda sebenarnya tahu tentang bug kedua pertama, tetapi yang pertama lebih mudah dibuktikan dan juga sesuatu yang menyebabkan masalah nyata, bukan sesuatu yang secara teoritis bisa.

Sayangnya salah satu alasan nyata untuk menolak database dinormalisasi dinormalisasi adalah bahwa pertanyaan apa yang harus dilakukan dengan data kereta tidak selalu mudah, tetapi Anda akan menemukan bug yang sebenarnya.

(Berhati-hatilah karena ada alasan mengapa seseorang terkadang men-denormalisasikan beberapa data dengan sengaja. Jangan salah mengartikan melanggar aturan karena ketidaktahuan akan aturan tersebut; jika Anda menormalkan sebuah tabel yang sengaja dinormalisasi untuk kecepatan pencarian, Anda menang tidak akan memenangkan pujian. Meskipun di sini, denormalisasi menjadi penuh adalah sesuatu yang harus dilakukan secara prosedural, jadi jika tabel yang dinormalisasi tidak dibuat secara otomatis berdasarkan isi tabel yang dinormalisasi masih ada kemajuan untuk dibuat).

Untuk yang lainnya, perkenalkan mereka ketika mereka membantu dalam jangka pendek, untuk kemudian membangun mereka dalam jangka panjang. Misalnya, jika Anda diberikan sepotong kecil kode untuk dibuat, tulislah tes unit untuk itu. Lebih baik lagi, jika Anda diberi bug untuk memperbaikinya, tulis unit test yang gagal karena bug tersebut dan kemudian ketika Anda telah memperbaiki bug sebutkan fakta bahwa bug tersebut berlalu ketika Anda menutup bug (atau mengirim email yang mengatakan bahwa itu sudah diperbaiki) , atau terserah).

* Kebetulan, tidak terlalu modern. Alasan itu disebut normalisasi dan tidak normalisasi atau sesuatu yang lain, adalah bahwa pada saat itu adalah lelucon topikal untuk tetap -ization di ujung hal yang membuat menyenangkan dari nama Richard Nixon Vietnamisasi kebijakan.


4

Saya akan menentang keinginan dan berkata: cari pekerjaan baru setelah menghabiskan waktu di sini untuk membuat resume Anda sedikit. Bertujuan untuk sekitar satu tahun. Meskipun banyak hal adalah "kata kunci," masalah seperti tidak lengkapnya pengujian unit tidak dapat dilakukan untuk satu pengembang, dan kemungkinannya adalah jika programmer yang bekerja di sana tidak memiliki keinginan untuk pengujian, Anda tidak akan pernah mendapatkan pembelian dan bahkan dapat membahayakan posisi Anda. di perusahaan dengan membuat orang menganggap Anda sebagai penipu. Anda harus berada di tempat di mana Anda bisa mendapatkan bimbingan, bukan mencoba mendorong budaya menuju kompetensi dasar.


3
Itulah tepatnya yang telah saya lakukan. Hanya ada satu kali (dari ~ 5 upaya di berbagai tempat) ketika saya berhasil memperkenalkan beberapa "praktik baik" baru atau membuat perubahan signifikan dalam praktik yang ada, dan saat itulah tim masih segar dan kami memulai sebagian besar proyek dari awal . Semua kali praktik yang baik diperkenalkan dari atas (pimpinan tim), atau gagal karena tidak ada orang lain yang berpartisipasi. Saya percaya itu semua datang pada kemampuan untuk memaksa keputusan Anda dengan menjadi pemimpin / bos.
scriptin


1

Ada banyak proposal untuk meningkatkan paradigma pemrograman . Kata kunci terpanas sekarang tampaknya pemrograman tangkas dan berorientasi objek. Atau apakah mereka? Keduanya memudar secara substansial dibandingkan dengan apa yang baru saja mereka lima tahun lalu.

Anda dapat cukup percaya diri bahwa metodologi apa pun yang diterapkan berusaha mencapai hasil akhir yang sama: membantu insinyur secara ekonomis menghasilkan produk akhir yang cukup baik.

Ada satu paradigma yang kontroversial diperkenalkan pada 1960-an: terstruktur pemrograman : hanya menggunakan "tingkat tinggi" konstruksi seperti while, for, repeat, if/ then/ else, switch/ casepernyataan bukan banyak digunakan gotopernyataan yang telah diterima secara default. Ada masih perdebatan tentang apakah gotomemiliki penggunaan sah sama sekali.

Saya menerima bahwa meminimalkan penggunaan gotoadalah hal yang baik, tetapi seperti semua hal yang baik, adalah mungkin untuk melangkah terlalu jauh.

Anda menyebut agilemetodologi sebagai sesuatu yang positif. Saya berada di satu tim pengembangan selama sekitar enam bulan yang dengan sengaja mengikuti rejimen lincah yang ditentukan. Saya menemukan itu sama seperti metodologi manajemen proyek yang tercerahkan dari beberapa dekade yang lalu, kecuali semuanya diganti namanya. Mungkin dengan menggabungkan kembali dan menjual kembali ide-ide untuk mengkomunikasikan seseorang mencari nafkah dan perusahaan dapat merasa baik tentang "melihat" pakaian baru kaisar .

Pelajaran Agile yang paling berharga, yang telah dikenal sejak lama, adalah bahwa fleksibilitas untuk menemukan jalan yang lebih baik ke produk jadi adalah hal yang baik dan kemampuan untuk menemukan jalan itu bisa datang dari siapa saja — bukan hanya manajemen tingkat atas.


Dari sebuah tulisan oleh pemimpin anti-goto Edsger Dijkstra:

Seni pemrograman adalah seni mengatur kerumitan, menguasai banyak orang dan menghindari kekacauan bajingannya seefektif mungkin.

—Dijkstra, dalam: Dahl, Dijkstra & Hoare 1972, hal. 6. (lihat halaman 6 di sini .)

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.