Melihat melalui artikel tentang desain perangkat lunak, saya terus-menerus bertemu dengan awan singkatan yang belum pernah terjadi sebelumnya dan praktik pengembangan yang disebutkan dengan santai.

• TDD - well, semua orang tahu itu, pertama kita menulis tes, dan kemudian sisa kode.
• BDD adalah sesuatu yang akrab, semacam tes juga, tetapi tes khusus.
• TDD - Lagi? Jadi, hentikan, ini bukan soal tes sama sekali. Tetapi mengapa itu disebut sama?
• DDD - konteks terikat, bahasa di mana-mana, domain ...
• Fdd
• MDD - Serius, Berbasis Grafik?
• PDD - ...

Pendekatan pengembangan dibagi oleh kompleksitas, bidang aplikasi dan tujuan.
Saya pikir waktunya telah tiba untuk mencari tahu mengapa mereka dibutuhkan, mengapa ada begitu banyak dari mereka, dan bagaimana mereka dapat berguna bagi kita.

Kita akan mulai berkenalan dengan mereka dari yang paling sederhana sampai yang paling kompleks, pertimbangkan contoh penggunaan dan pro dan kontra dari masing-masing.

TDD - Pengembangan Berbasis Tes

TDD adalah metodologi pengembangan perangkat lunak yang didasarkan pada siklus pengembangan singkat yang berulang: awalnya tes ditulis yang mencakup perubahan yang diinginkan, kemudian kode program ditulis yang mengimplementasikan perilaku sistem yang diinginkan dan memungkinkan Anda lulus tes tertulis. Kemudian kode tertulis di refactored dengan pengujian pengujian yang konstan.

Kedengarannya sederhana dan jelas. Banyak yang akrab dengan pendekatan pengembangan ini, dan bahkan Paman Bob sendiri secara aktif mempromosikannya.

TDD dianggap sebagai bentuk konstruksi aplikasi yang tepat. Filosofi pengembangan yang digerakkan oleh tes adalah bahwa tes Anda adalah spesifikasi tentang bagaimana program Anda harus bersikap. Jika Anda menganggap suite tes Anda sebagai bagian wajib dari proses build, jika tes Anda gagal, program tidak membangun karena itu salah. Tentu saja, batasannya adalah bahwa kebenaran program Anda hanya didefinisikan sebagai kelengkapan tes Anda. Namun, penelitian telah menunjukkan bahwa pengembangan berdasarkan pengujian dapat mengurangi kesalahan hingga 40-80% dalam produksi.

Ketika Anda mulai menggunakan TDD, Anda mungkin merasa berjalan lebih lambat dari biasanya. Ini karena Anda akan bekerja di luar "zona nyaman", dan ini cukup normal.

Setelah Anda merasa bahwa tes menulis telah menjadi bagian yang sederhana dan alami dari alur kerja, bahwa Anda tidak perlu lagi berpikir tentang menggunakan TDD saat mengerjakan proyek, Anda menyadari bahwa TDD telah mengalir ke dalam pekerjaan Anda.

Metodologi ini memungkinkan kita untuk mencapai pembuatan aplikasi yang cocok untuk pengujian otomatis dan cakupan kode yang sangat baik dengan tes, karena TK diterjemahkan ke dalam bahasa tes otomatis, yaitu, segala sesuatu yang harus dilakukan program diperiksa. TDD juga sering menyederhanakan implementasi perangkat lunak: redundansi implementasi dihilangkan - jika suatu komponen lulus tes, maka itu dianggap siap.

Arsitektur produk perangkat lunak yang dikembangkan dengan cara ini biasanya lebih baik (dalam aplikasi yang cocok untuk pengujian otomatis, tanggung jawab antara komponen biasanya didistribusikan dengan sangat baik, dan prosedur kompleks yang dilakukan didekomposisi menjadi banyak yang sederhana). Stabilitas aplikasi yang dikembangkan melalui pengujian lebih tinggi karena fakta bahwa semua fungsi dasar program dicakup oleh tes dan kinerjanya terus diperiksa. Menyertai proyek-proyek di mana semuanya atau hampir semuanya diuji sangat tinggi - pengembang mungkin tidak takut untuk membuat perubahan pada kode, jika terjadi kesalahan, hasil pengujian otomatis akan menginformasikan tentang hal ini.

Anda dapat mempelajari lebih lanjut tentang prinsip-prinsip TDD dengan membaca buku Kent Beck, Extreme Programming, Development through Testing.

TDD - Pengembangan Berbasis Tipe

Tipe Driven Development disingkat juga pengembangan melalui pengujian, jadi biasanya nama lengkap ditulis.

Ketika mengembangkan berdasarkan tipe, tipe data dan tipe tanda tangan Anda adalah spesifikasi program. Jenis juga berfungsi sebagai bentuk dokumentasi yang dijamin akan diperbarui.

Jenisnya adalah titik kontrol kecil, karena itu, kami mendapatkan banyak tes mini di seluruh aplikasi kami. Selain itu, biaya pembuatan jenis minimal dan memperbarui mereka tidak diperlukan, karena mereka adalah bagian dari basis kode.

Pengembangan menurut jenis adalah metode lain yang baik untuk membangun aplikasi. Seperti pengembangan berbasis tes, pengembangan berbasis tipe dapat meningkatkan kepercayaan Anda pada kode Anda dan menghemat waktu Anda saat membuat perubahan pada basis kode besar.

Dari minusnya, hanya meningkatnya kompleksitas bahasa dengan pengetikan dinamis. Misalnya, untuk JavaScript pendekatan ini lebih sulit diterapkan daripada untuk TypeScript.

Pada habr ada artikel bagus tentang mengetik.

BDD - Pengembangan Berbasis Perilaku

Karena beberapa kesamaan metodologis, TDD (Test Driven Development) dan BDD (Behavior Driven Development) sering bingung bahkan oleh para profesional. Apa bedanya? Konsep kedua pendekatan itu serupa, tes pertama dilakukan dan baru kemudian pengembangan dimulai, tetapi tujuannya sama sekali berbeda. TDD lebih lanjut tentang pemrograman dan pengujian pada tingkat implementasi teknis produk, ketika pengujian dibuat oleh pengembang sendiri. BDD melibatkan penguji atau analis yang menggambarkan skrip yang ditentukan pengguna dalam bahasa alami - jika boleh saya katakan demikian, dalam bahasa bisnis.

BDD - pengembangan berbasis perilaku adalah pengembangan berbasis perilaku. Orang tertentu (atau orang) menulis deskripsi formulir "sebagai pengguna yang saya inginkan ketika tombol mulai ditekan maka menu ditampilkan seperti pada gambar" (ada kata kunci yang disorot khusus). Programmer telah lama menulis alat khusus yang menerjemahkan deskripsi seperti itu ke dalam tes (kadang-kadang benar-benar transparan bagi programmer). Dan kemudian pengembangan klasik dengan tes.

Jika Anda mencatat nama-nama tes dalam bentuk kalimat dan menggunakan kosakata domain bisnis untuk menulis nama metode, dokumentasi yang dibuat menjadi jelas bagi pelanggan, analis, dan penguji.

Teks skrip ditulis dalam bentuk tertentu.

Memiliki (kurang lebih Diberikan - diberikan) beberapa konteks,

Ketika (catat kapan) suatu peristiwa terjadi,

Kemudian (kurang-lebih Lalu) periksa hasilnya.

Sesuatu seperti ini mungkin terjadi:

Atau contoh lain dalam bahasa Rusia:

Skenario 1: Ada uang di akun +

Memiliki akun dengan uang

Dan kartu yang valid

Dan ATM dengan uang tunai

Ketika seorang pelanggan meminta uang tunai

Kemudian pastikan akun itu didebit

Dan pastikan uang tunai dikeluarkan

Dan pastikan kartunya dikembalikan

Pendekatan BDD, bersama dengan praktik-praktik rekayasa, memungkinkan kami untuk meninggalkan dokumentasi lama yang berisi informasi yang tidak relevan, dan menerima dokumentasi baru dengan cepat, menyimpannya dengan proyek, yang membawa analis dan penguji lebih dekat ke kode.

BDD lebih merupakan proses yang tujuannya adalah untuk mengurangi biaya penerapan fitur baru. Bahkan pada awal pengembangan, kami mendapatkan artefak penting. Misalnya, dokumentasi yang dapat dimengerti untuk didukung. Dokumentasi ini memberikan peluang bagi semua pihak yang berkepentingan untuk membentuk pemahaman mereka tentang skenario perilaku produk dan pengguna yang harus diimplementasikan selama iterasi pengembangan. Dengan pendekatan BDD, kami juga menurunkan ambang batas bagi anggota baru untuk memasuki proyek.

Apa keuntungan BDD?

• Tes yang dapat dibaca untuk non-programmer.
• Mereka mudah diubah. Mereka sering ditulis dalam bahasa Inggris yang hampir murni.
• Mereka dapat ditulis oleh pemilik produk atau pihak lain yang berkepentingan.
• Hasil tes lebih manusiawi.
• Tes tidak tergantung pada bahasa pemrograman target. Migrasi ke bahasa lain sangat disederhanakan.

Cons:

Tetapi pendekatan ini memiliki kelemahan - pendekatan ini panjang dan mahal. BDD tidak nyaman bahkan jika memerlukan keterlibatan spesialis pengujian yang sudah pada tahap pengembangan persyaratan, dan ini memperpanjang siklus pengembangan.

Jalan keluar dari situasi ini mungkin adalah pilihan kerangka BDD yang cocok dan proses pembangunan yang dibangun dengan benar.

Baca lebih lanjut tentang BDD di sini .

Banyak yang sudah lama memahami bahwa pengujian adalah semacam obat mujarab untuk semua penyakit, tetapi apakah benar demikian? Tentu saja, kode yang diuji secara menyeluruh berfungsi lebih stabil dan dapat diprediksi, tetapi pengujian tidak menyelamatkan kita dari masalah dan kesalahan pada tahap desain dan pengaturan tugas. Pendekatan pengembangan berikut dapat membantu Anda dalam hal ini.

DDD - Desain Berbasis Domain

Desain yang berorientasi pada subjek bukanlah teknologi atau metodologi tertentu. DDD adalah seperangkat aturan yang memungkinkan Anda untuk membuat keputusan desain yang tepat. Pendekatan ini secara signifikan dapat mempercepat proses mendesain perangkat lunak dalam domain yang tidak dikenal.

Desain berorientasi subjek (lebih jarang berorientasi pada masalah, Bahasa Inggris. Desain berbasis domain, DDD) adalah seperangkat prinsip dan skema yang bertujuan untuk menciptakan sistem objek yang optimal. Proses pengembangan bermuara pada pembuatan abstraksi perangkat lunak, yang disebut model domain. Model-model ini termasuk logika bisnis yang membangun hubungan antara kondisi aktual area aplikasi produk dan kode.

Pendekatan DDD sangat berguna dalam situasi di mana pengembang bukan spesialis di bidang produk yang dikembangkan. Sebagai contoh: seorang programmer tidak dapat mengetahui semua bidang di mana diperlukan untuk membuat perangkat lunak, tetapi dengan bantuan representasi struktur yang benar, melalui pendekatan berorientasi subjek, ia dapat dengan mudah merancang aplikasi berdasarkan poin-poin utama dan pengetahuan ruang kerja.

Dalam artikel ini saya mencoba menyampaikan esensi dari setiap pendekatan untuk pengembangan perangkat lunak, tetapi tentang DDD Anda dapat menulis lebih dari satu artikel dan membahas semua nuansa dalam beberapa paragraf, itu tidak akan berhasil bagi saya. Karena itu, ketika menjelaskan, saya akan memberikan tautan jelas ke sumber yang paling layak.

Tujuan utama Desain Berbasis Domain adalah untuk memerangi kompleksitas proses bisnis, otomasi dan penerapannya dalam kode. "Domain" diterjemahkan sebagai "domain", dan pengembangan dan desain dalam kerangka pendekatan ini didorong menjauh dari domain.

Konsep kunci dalam DDD adalah bahasa di mana-mana. Bahasa di mana-mana mempromosikan komunikasi yang transparan antara peserta proyek. Dia bukan satu dalam arti bahwa dia adalah satu untuk semua kesempatan. Justru sebaliknya. Semua peserta berkomunikasi di dalamnya, semua diskusi berlangsung dalam satu bahasa, dan semua artefak harus disajikan dalam satu bahasa, yaitu mulai dari TK, dan diakhiri dengan kode.

Konsep selanjutnya adalah "model domain". Model ini adalah daftar istilah dari bahasa di mana-mana. Baik model domain dan bahasa di mana-mana dibatasi oleh konteks yang oleh Desain Domain-Driven disebut konteks terbatas. Dia membatasi model domain sedemikian rupa sehingga semua konsep di dalamnya tidak ambigu, dan semua orang mengerti apa yang dipertaruhkan.

Contoh: ambil entitas "orang" dan letakkan dalam konteks "berbicara di depan umum". Dalam konteks ini, menurut DDD, ia menjadi pembicara atau pembicara. Dan dalam konteks "keluarga" - suami atau saudara.

Sekarang tentang kodenya. Penting bahwa kode Anda dibaca seperti buku, bahwa kode itu sederhana dan dapat dimengerti oleh semua orang yang berbicara dalam bahasa umum proyek. Apa yang saya maksud

Jika dalam bahasa proyek Anda menggunakan ungkapan "produk telah ditambahkan", maka opsi berikut ini bukan DDD:

var product = Produk baru ('apel')

product.save ()

Mengapa Kode mengatakan bahwa kami menciptakan produk dengan cara yang aneh dan menyimpannya. Bagaimana cara menambahkan produk? Perlu menambahkannya . Ini adalah kode DDD:

Product :: add ('apple');

Arsitektur:

Dari sudut pandang Desain Berbasis Domain, tidak terlalu masalah arsitektur apa yang Anda pilih. Desain Berbasis Domain bukan tentang itu; Desain Berbasis Domain adalah tentang bahasa dan komunikasi.

Tetapi DDD hampir tidak mungkin tanpa arsitektur proyek yang bersih, karena ketika menambahkan fungsionalitas baru atau mengubah yang lama, Anda perlu mencoba mempertahankan fleksibilitas dan transparansi basis kode. Anda dapat membaca tentang port, adaptor, dan arsitektur bawang di artikel yang bagus. Gambar di atas hanya dari itu.

Ada juga artikel tentang DDD yang saya sangat sarankan baca dengan seksama - di sini dan di sini .

Apa yang ini memberi kita pada akhirnya:

• hampir semua anggota tim dapat membaca kode proyek;
• pernyataan tugas menjadi lebih eksplisit;
• bug dalam logika bisnis menjadi lebih mudah dicari;
• Jauh lebih mudah bagi spesialis QA untuk memindai kode dan menemukan kesalahan logis dan bug.

Cons:

• Diperlukan pengembang yang berkualitas tinggi, terutama pada awal proyek;
• tidak semua pelanggan bersedia membuat biaya seperti itu, DDD perlu dipelajari oleh semua peserta dalam proses pengembangan.

FDD - Pengembangan Fitur Didorong

FDD - Metodologi ini (secara singkat disebut sebagai FDD) dikembangkan oleh Jeff De Luca dan guru yang diakui di bidang teknologi berorientasi objek, Peter Coad. FDD adalah upaya untuk menggabungkan teknik yang paling dikenal dalam industri pengembangan perangkat lunak yang mengambil sebagai dasar fungsi penting (properti) dari perangkat lunak yang dikembangkan untuk pelanggan. Tujuan utama metodologi ini adalah untuk mengembangkan perangkat lunak yang nyata dan berfungsi secara sistematis tepat waktu.

Seperti metodologi adaptif lainnya, ini berfokus pada iterasi pendek, yang masing-masing berfungsi untuk mengerjakan bagian tertentu dari fungsionalitas sistem. Menurut FDD, satu iterasi berlangsung dua minggu. FDD memiliki lima proses. Tiga yang pertama dari mereka berhubungan dengan dimulainya proyek:

• pengembangan model umum;
• menyusun daftar properti sistem yang diperlukan;
• merencanakan pekerjaan di setiap properti;
• desain setiap properti;
• pembangunan setiap properti.

Dua langkah terakhir harus dilakukan selama setiap iterasi. Selain itu, setiap proses dibagi menjadi tugas dan memiliki kriteria verifikasi.

Mari kita bahas setiap item dengan lebih detail.

Pengembangan model umum.

Pengembangan dimulai dengan analisis luasnya jangkauan tugas yang ada dan konteks sistem. Selanjutnya, untuk setiap area yang disimulasikan, analisis yang lebih rinci dibuat. Deskripsi awal dikompilasi dalam kelompok-kelompok kecil dan diserahkan untuk diskusi lebih lanjut dan evaluasi ahli. Setelah salah satu model yang diusulkan atau kombinasinya menjadi model untuk area tertentu. Model masing-masing area tugas digabungkan menjadi model akhir yang umum, yang dapat berubah selama pekerjaan.

Daftar Fitur

Informasi yang dikumpulkan selama pembangunan model umum digunakan untuk menyusun daftar fungsi. Fungsi digabungkan menjadi apa yang disebut "domain" (domain bahasa Inggris), dan mereka, pada gilirannya, dibagi menjadi sub-wilayah (area subjek bahasa Inggris) sesuai dengan atribut fungsional.

Setiap subdomain berhubungan dengan proses bisnis tertentu, dan langkah-langkahnya menjadi daftar fungsi (properti). Fungsi disajikan dalam bentuk "action - result - object", misalnya, "periksa kata sandi pengguna". Pengembangan setiap fungsi harus tidak lebih dari 2 minggu, jika tidak tugas tersebut harus diuraikan menjadi iterasi yang lebih kecil. Daftar properti di FDD sama dengan simpanan produk di SCRUM.

Properti (Fungsi) Rencana

Tahap berikutnya adalah distribusi fungsi di antara programmer atau tim terkemuka.

Desain Fitur

Paket desain dibuat untuk setiap properti. Programmer pemimpin menguraikan sekelompok kecil properti untuk pengembangan dalam waktu dua minggu. Setelah itu, diagram urutan terperinci untuk setiap properti dibiarkan, menentukan model umum. Selanjutnya tertulis "rintisan" kelas dan metode. Pada titik ini, kita harus fokus pada desain produk perangkat lunak.

Implementasi fungsi

Kami menulis kode, menghapus bertopik, menguji.

Setelah properti telah diuji dan dimasukkan ke dalam produk, kami mengambil properti prioritas berikutnya, mengulangi siklus desain / implementasi.

Total, sebagai hasilnya, kita mendapatkan:

• dokumentasi properti sistem;
• desain yang cermat;
• lebih mudah untuk mengevaluasi tugas-tugas kecil;
• tes difokuskan pada tugas bisnis;
• proses pembuatan produk yang canggih;
• Siklus pengembangan berulang pendek memungkinkan Anda untuk dengan cepat meningkatkan fungsionalitas dan mengurangi kesalahan.

Cons:

• FDD lebih cocok untuk proyek besar. Tim pengembangan kecil tidak akan dapat merasakan semua manfaat dari pendekatan ini;
• biaya implementasi dan pelatihan yang signifikan.

MDD - Pengembangan Berbasis Model

Baru-baru ini, banyak perhatian telah diberikan dalam publikasi untuk topik arsitektur dan pengembangan berdasarkan model MDA (Model Driven Architecture) dan MDD (Model Driven Development). Tanpa merinci, kami hanya menyoroti poin-poin penting.

Pengembangan model-driven adalah gaya pengembangan perangkat lunak di mana model menjadi artefak pengembangan utama dari mana kode dan artefak lainnya dihasilkan.

, , .

MDD — , . - .

. . , , . MDD — , , .

«», . ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

:

• .

PDD , , , .

Kesimpulan

agile . , , .

Saya harap banyak dari Anda telah mempelajari sesuatu yang baru tentang praktik Pembangunan Berbasiskan, dan sekarang, bertemu langsung dengan singkatan DDD, BDD, MDD, Anda tidak akan mengalami kebingungan, atau Anda mungkin ingin mencobanya dalam praktik.