Praktik spesifik apa yang bisa disebut "pengerjaan perangkat lunak" daripada "rekayasa perangkat lunak"? [Tutup]

11

Meskipun bukan ide baru, tampaknya ada peningkatan besar dalam minat pengerjaan perangkat lunak selama beberapa tahun terakhir (terutama buku yang sering direkomendasikan judul lengkap Clean Code adalah Clean Code: A Handbook of Agile Software Craftsmanship ).

Secara pribadi saya melihat pengerjaan perangkat lunak sebagai rekayasa perangkat lunak yang baik dengan minat tambahan untuk memastikan bahwa hasil akhirnya adalah kesenangan untuk bekerja dengan (baik sebagai pengguna akhir dan sebagai seseorang yang memelihara perangkat lunak itu) - dan juga bahwa fokusnya lebih pada tingkat pengkodean hal daripada hal-hal tingkat proses yang lebih tinggi.

Sebagai analogi - ada banyak bangunan yang dibangun pada tahun 50-an dan 60-an dalam gaya yang sangat modern yang hanya memperhitungkan sedikit orang yang akan tinggal di dalamnya atau bagaimana bangunan itu akan menua seiring waktu. Banyak dari bangunan itu dengan cepat berkembang menjadi daerah kumuh atau telah dihancurkan jauh sebelum jangka hidup yang diharapkan. Saya yakin sebagian besar pengembang dengan beberapa tahun di bawah ikat pinggang mereka akan mengalami basis kode yang sama.

Apa hal spesifik yang mungkin dilakukan oleh pengrajin perangkat lunak yang mungkin tidak dilakukan oleh insinyur perangkat lunak (mungkin yang buruk)?

programming-practices

— FinnNk
sumber

1

Analogi itu tampaknya tidak cocok. Baik pengerjaan perangkat lunak dan rekayasa perangkat lunak memiliki tujuan (dan kepentingan pribadi) yang sama untuk meningkatkan kegunaan jangka panjang dari perangkat lunak tersebut.

— rwong

3

Saya pikir masalah ini sebagian besar masalah apakah Anda menganggap "insinyur" atau "pengrajin" judul yang lebih dingin, dan jawaban saat ini tampaknya membuktikan hal itu. Judul mana pun yang Anda sukai jelas menyiratkan bahwa orang tersebut tahu apa yang mereka lakukan.

— Ben Brocka

Saya akan mengatakan perbedaan antara keduanya adalah bahwa pengrajin bekerja sendiri, seorang insinyur bekerja sebagai bagian dari tim. Dalam sapuan luas ini tampaknya memuaskan deskripsi utama dari dua peran, bukan karena keduanya memiliki keterampilan yang berbeda tetapi pendekatan mereka berasal dari posisi yang berbeda.

— gbjbaanb

Itu terdengar seperti judul yang benar-benar megah untuk diberikan kepada diri sendiri.

— michaelsnowden

13

Saya akan mengatakan satu-satunya perbedaan antara seorang profesional dan pengrajin adalah peduli dengan sedikit gairah bercampur . Tidak ada praktik khusus yang dapat diamati yang akan mengklasifikasikan seseorang sebagai pengrajin, melainkan kumpulan kualitas:

Seorang pengrajin peduli tentang kualitas sebenarnya dari karyanya, dan bukan hanya kualitas yang dirasakan.
Seorang pengrajin memiliki ketertarikan pada keahliannya yang lebih dari sekedar menyelesaikan pekerjaan, dan secara alami condong ke keahliannya.
Seorang pengrajin peduli dengan profesinya, bercita-cita untuk meningkatkan keterampilannya dan tidak hanya memajukan karirnya .
Seorang pengrajin menghabiskan sejumlah waktu di luar jam kerjanya yang dibayar (bahkan jika itu adalah sejumlah kecil waktu) melakukan sesuatu dengan keahliannya, baik itu berdiskusi, belajar, atau bahkan memikirkannya.
Seorang pengrajin tahu betapa sedikitnya yang dia tahu, dan merasa rendah hati karenanya.
Seorang pengrajin bersedia untuk mengajar mereka yang mau belajar, membimbing mereka yang mencari bimbingan, dan mencari hal-hal itu sendiri ketika dia membutuhkannya.

Sedikit gairah menutupi semua ini tanpa berkeringat.

— Allon Guralnek
sumber

Saya pikir yang terakhir sangat penting

— Lovis

7

Secara pribadi saya melihat pengerjaan perangkat lunak sebagai rekayasa perangkat lunak yang baik dengan minat tambahan untuk memastikan bahwa hasil akhirnya adalah kesenangan untuk bekerja dengan (baik sebagai pengguna akhir dan sebagai seseorang yang memelihara perangkat lunak itu) - dan juga bahwa fokusnya lebih pada tingkat pengkodean hal daripada hal-hal tingkat proses yang lebih tinggi.

Seperti yang pernah dikatakan oleh seorang profesor saya (diparafrasekan): "Sebagai seorang insinyur perangkat lunak, bukan hanya pekerjaan Anda untuk mengirimkan perangkat lunak. Tugas Anda adalah memberikan perangkat lunak yang membuat pelanggan Anda bahagia."

Apa hal spesifik yang mungkin dilakukan oleh pengrajin perangkat lunak yang mungkin tidak dilakukan oleh insinyur perangkat lunak (mungkin yang buruk)?

Tidak ada - seorang insinyur adalah pengrajin ... tetapi lebih. Teknik dibangun berdasarkan keahlian.

Sebagai pengrajin dan insinyur, Anda adalah individu yang terampil, melalui kombinasi antara pendidikan dan pengalaman. Anda mengikuti prosedur yang ditetapkan. Anda juga pragmatis dan menyadari apa yang rusak dan perlu menjadi lebih baik.

Namun, seorang insinyur menambahkan kekhawatiran ekonomi, teori, dan sains di atas itu. Anda prihatin dengan mendapatkan manfaat paling banyak dengan biaya paling murah. Anda ingin menerapkan teori-teori dari psikologi, sosiologi, manajemen, interaksi manusia-komputer, dan ilmu komputer untuk menyelesaikan masalah Anda (baik interpersonal dan teknis). Dan Anda pasti memiliki pendidikan untuk mendukung pengalaman Anda.

— Thomas Owens
sumber

2

Dan Anda pasti memiliki pendidikan untuk mendukung pengalaman Anda - senang Anda tidak mengatakan "formal".

— treecoder

@greengit Di banyak tempat, untuk menggunakan gelar "insinyur", Anda harus memiliki pendidikan formal. Di Eropa, ini berarti lulus dengan gelar teknik. Italia juga menambahkan persyaratan untuk lulus ujian sertifikasi. Di Amerika Utara, Texas, Florida, dan Kanada mengharuskan mereka yang menggunakan gelar "insinyur" (termasuk insinyur perangkat lunak) untuk lulus ujian lisensi.

— Thomas Owens

Meskipun itu tidak berarti bahwa seseorang tanpa pendidikan formal ini tidak dapat mempraktikkan teknik. Mereka tidak bisa menyebut diri mereka seorang insinyur sebagai gelar profesional.

— Thomas Owens

1

Saya tidak setuju, seorang insinyur belum tentu pengrajin.

— Nicole

2

@ Renesis Menurut definisi, teknik adalah kerajinan. Definisi kerajinan: "suatu seni, perdagangan, atau pekerjaan yang membutuhkan keterampilan khusus, terutama keterampilan manual". Teknik adalah pekerjaan yang membutuhkan keterampilan khusus, oleh karena itu merupakan keahlian. Namun, itu juga penerapan teori ilmiah (antara lain), yang membuatnya lebih.

— Thomas Owens

2

Gerakan pengerjaan perangkat lunak dimulai sebagai reaksi terhadap kegagalan dan hasil yang tidak memuaskan dari rekayasa perangkat lunak "tradisional" yang (bersama dengan kecerobohan beberapa pengembang) saat ini menyebabkan ketidakpercayaan dari para pemangku kepentingan dan pengguna terhadap profesi kami.

Tujuannya ada dua: mengembalikan kepercayaan pada programmer, dan untuk melakukannya, meningkatkan standar kualitas perangkat lunak dan keterampilan pengembang.

Keahlian Sw mempromosikan praktik-praktik teknis seperti:

Prinsip-prinsip desain SOLID
Pola desain
Metafora TDD ("akuntansi entri ganda")
...

Dan praktik tim / organisasi:

Pemrograman Pasangan
Pendampingan
Kode katas
Dojo / kode mundur
...

Jadi saya akan mengatakan perbedaan antara 2 jelas: pengerjaan perangkat lunak mencoba untuk mengatasi sebagian besar masalah rekayasa perangkat lunak telah ada di 40 + tahun keberadaannya yang hari ini membuat disiplin kita terlihat tidak dapat diandalkan dan dilumpuhkan dengan sejarah kegagalan.

— guillaume31
sumber

1

Saya tidak setuju - alasan rekayasa perangkat lunak gagal adalah karena tidak memiliki insinyur, hanya pengrajin yang berpura-pura menjadi insinyur. NASA tidak mengirim pesawat ruang angkasa ke bulan menggunakan pengrajin!

— gbjbaanb

@ gbjbaanb Saya pikir itu sangat bertentangan - kami memang memiliki insinyur, dan itulah sebabnya mereka mencoba untuk menempelkan model teknik tradisional dan pola pikir dari industri lain ke perangkat lunak, tetapi tidak berhasil.

— guillaume31

Wahana antariksa tidak terbuat dari benda-benda tak berwujud yang dapat dirancang ulang, direkayasa ulang, dan digunakan kembali berulang kali. Hukum yang mereka patuhi sangat berbeda dengan undang-undang program perangkat lunak.

— guillaume31

Pesawat ulang-alik memiliki pendorong yang dapat dipekerjakan kembali, setidaknya, dan tidak diragukan lagi menggunakan kembali bit (atau setidaknya pengetahuan) dari roket sebelumnya. Dan pesawat ruang angkasa memiliki banyak perangkat lunak di dalamnya. Saya tidak berpikir mereka memulai dari awal dengan setiap satelit atau probe baru, dan hampir tidak pernah menerapkan pembaruan sekali dikerahkan. Rekayasa perangkat lunak dapat dan jelas berhasil - tetapi hanya jika Anda mendekatinya dengan pola pikir seorang insinyur, bukan pengrajin.

— gbjbaanb

Silakan tentukan "pola pikir insinyur", dalam konteks perangkat lunak.

— guillaume31

1

Pergi oleh http://manifesto.softwarecraftsmanship.org/ Saya akan mendapatkan yang berikut ini.

Seorang pengrajin berbeda dari persepsi tradisional tentang seorang "insinyur" karena

Mereka fokus pada nilai, bukan hanya memenuhi persyaratan.
Mereka fokus pada kualitas bahkan dalam gaya kode mereka, tidak hanya memenuhi persyaratan.
Mereka berpartisipasi dalam komunitas pengembangan perangkat lunak yang lebih luas, bukan hanya di tempat kerja mereka.
Mereka tidak hanya mengerti bahwa keadaan seni saat ini adalah sampah masa depan, mereka aktif dalam membawanya pada satu tingkat atau yang lain.
Ini bukan hanya pekerjaan, itu yang mereka adalah .

— MIA
sumber

4

Jujur, semua poin-poin itu menggambarkan seorang insinyur yang baik. Terutama 1, 2, dan 4.

— Thomas Owens

@ThomasOwens Dan bagaimana dengan insinyur yang buruk? Apakah dia juga pengrajin? Atau pengrajin yang baik vs buruk?

— Euforia

@ Euforia Saya tidak berpikir Anda bisa menjadi insinyur yang baik tanpa menjadi pengrajin yang baik. Ini seperti dipentaskan. Anda harus mencapai "pengrajin yang baik" sebelum mencapai "insinyur yang baik". Namun, Anda bisa menjadi pengrajin yang baik dan bukan menjadi insinyur yang baik.

— Thomas Owens

1

Paman Bob entah bagaimana mengisyaratkan bahwa pemrograman adalah disiplin yang sangat muda yang belum memiliki badan hukum atau peraturan yang stabil yang diakui oleh pemerintah (atau apakah itu Frederick Brooks?). Saya tidak membuat kutipan verbatin di sini.

Anda tidak dapat mencabut izin siapa pun untuk memprogram karena malpraktek. Pemrograman tidak memiliki badan hukum dan peraturan yang secara hukum ditegakkan oleh undang-undang yang sesuai dengan "profesi". Seorang dokter membunuh seorang pasien karena ketidakmampuan dan ia mengambil risiko gelar dokter atau izin diambil darinya.

Seorang programmer membuat program buggy atau membuat proyek gagal karena ketidakmampuan dan dia bebas untuk melanjutkan pemrograman.

Saya pikir itulah yang membuat pemrograman menjadi kerajinan. Pembuat pot tanah liat tidak membuat dua pot yang sama. Anda juga belum pernah mendengar tentang pembuat pot tanah liat yang dipaksa untuk mengingat pot yang rusak. Pemrograman masih merupakan jenis pekerjaan yang sangat manual dan pribadi. Kadang-kadang Anda bahkan dapat mengetahui siapa yang menulis sepotong kode menilai dari gaya itu.

— Tulains Córdova
sumber

0

Refactoring Ke Pola.

Yaitu, membangun sesuatu yang memenuhi 90% dari persyaratan perangkat lunak, kemudian mengubah seluruh proyek menjadi beberapa desain yang bersih dan elegan.

Biasanya, rekayasa perangkat lunak akan mencegah Anda melakukan ini, karena memenuhi 90% dari persyaratan berarti bahwa perangkat lunak memiliki nilai bisnis yang cukup bagi pelanggan sehingga tidak boleh dimodifikasi dengan cara yang signifikan (kecuali perbaikan bug prioritas tinggi).

Rekayasa perangkat lunak sebaliknya akan menyarankan Anda untuk menstabilkan perangkat lunak pada saat ini.

Selain itu, jika sebuah proyek tidak dimulai dengan desain yang elegan sejak awal, itu akan dianggap sebagai proyek yang dilaksanakan dengan buruk (terlepas dari hasil proyek), menurut rekayasa perangkat lunak.

Solusi Spike.

Desain yang terinspirasi dari solusi spike biasanya tidak dapat diterima sesuai dengan metodologi rekayasa perangkat lunak yang berlaku.

Penghentian , karena alasan apa pun.

Dalam rekayasa perangkat lunak, segala jenis penghinaan diizinkan terjadi hanya pada akhir siklus hidup sistem perangkat lunak. Ini harus direncanakan sebagai bagian dari SDLC.

Dalam praktiknya, agak umum bahwa kekurangan bagian tertentu dari antarmuka perangkat lunak ditemukan beberapa tahun dalam produksi, dan bagian tertentu itu dapat ditinggalkan di tengah siklus kehidupan, tanpa membatalkan sisa perangkat lunak. Ini akan membutuhkan sertifikasi ulang seluruh sistem perangkat lunak setelah penghentian, menurut rekayasa perangkat lunak.

Pada akhirnya, pengerjaan perangkat lunak adalah upaya pribadi untuk penilaian yang baik dari individu, sedangkan rekayasa perangkat lunak adalah kumpulan pengetahuan yang konservatif. Mengizinkan penilaian yang baik dalam pengambilan keputusan proyek adalah apa yang membedakan pengerjaan perangkat lunak dari rekayasa perangkat lunak.

— rwong
sumber

-1

Saya akan mengatakan memiliki unit test yang mencakup 100% dari kode akan menjadi bagus. Karena itu memungkinkan kelebihan barang yang akan dilucuti.

Terkadang saya membandingkan pengembangan perangkat lunak dengan patung. Bukan apa yang Anda tambahkan, itu yang Anda ambil.

Jelas Anda bisa melangkah terlalu jauh. Tidak seorang pun akan mengatakan bahwa kerikil kecil yang mengkilap adalah patung yang bagus: S

— Antony Scott
sumber

3

Seberapa berkilau yang kita bicarakan di sini? :-)

— Chris

1

Sebagian besar waktu saya setuju dengan ini - tapi saya tidak yakin ketat 100% selalu bermanfaat - misalnya getter / setter di mana mereka tidak memiliki logika. Kode yang dihasilkan juga umumnya lebih baik dibiarkan tanpa unit test (meskipun tes integrasi mungkin tepat)

— FinnNk

@FinnNk - saya setuju. Saya telah menggunakan dotCover baru-baru ini dan yang mengatakan pengambil / penyetel tertutup jika digunakan dalam tes lain. Jadi, saya tidak benar-benar bermaksud metode pengujian untuk setiap pengambil & penyetel

— Antony Scott