Di NORBIT kami menangani solusi SRM . Hari ini kami akan memberi tahu Anda tentang proyek khusus untuk tim kami - pengembangan platform NBT BPMS. Kami tidak hanya menciptakan solusi bisnis untuk pelanggan, tetapi mengembangkan produk kami sendiri dari awal - semua ini menyiratkan pendekatan yang sama sekali berbeda untuk desain, pengembangan, manajemen tim, pengorganisasian proses pengiriman perubahan, dan perencanaan rilis.
Secara umum, artikel tersebut tidak hanya tentang KDPV yang indah. Anda juga akan belajar:
- tentang pengalaman kami dalam merancang arsitektur layanan mikro (pilihan alat, pendekatan untuk menggunakan alat ini, yaitu abstraksi penggunaannya);
- tentang pengembangan perancang objek bisnis dan implementasi perancang proses bisnis dalam solusi untuk memastikan pendekatan pengembangan kode rendah;
- tentang bagaimana kami mengatur pekerjaan pada proyek dan menyelamatkan pengembang dari beberapa aspek rutin atau mengganggu saat bekerja pada sistem (interaksi antar-layanan abstrak, pembuatan kode otomatis, suasana tim);
- dan tentang meme mana yang membantu kami di masa-masa sulit.
Divisi kami di perusahaan NORBIT terutama bergerak dalam otomasi proses pengadaan, di mana ia menciptakan berbagai macam solusi pada platform .Net.
Pengembangan solusi tersebut dimulai dengan ASP.NET WebForms, kemudian versi baru dari solusi ini dibuat berdasarkan ASP.NET MVC. Selain perkembangan di .NET, kami telah dan masih memiliki proyek dan solusi lain, namun demikian, pengembangan di .NET menyumbang sekitar 80% dari semua proyek departemen.
Keterbatasan ASP.NET WebForms dan ASP.NET MVC menyarankan bahwa agar solusi berfungsi pada platform ini, penerapan pada OS dari keluarga Windows Server diperlukan, dan di sisi DB (database), volume logika diimplementasikan yang tidak memungkinkan untuk transisi yang cepat dan tidak menyakitkan di DBMS selain MS SQL Server. Ini tidak memberikan hambatan dan kesulitan sebelum dimulainya transisi besar-besaran ke perangkat lunak dalam negeri.
Mulai dari 2014-2015, pasar TI mulai bergerak sangat serius menuju substitusi impor, dan masalah penerapan sistem kami pada sistem operasi dan DBMS yang sesuai dengan persyaratan baru cukup akut. Ternyata itu menjadi pertanyaan nomor 1yang perlu kami selesaikan agar solusi kami dapat memenuhi kebutuhan pelanggan potensial dalam jangka panjang.
Pada saat yang sama, memiliki kompetensi yang kuat dan tim pengembang .NET yang cukup besar, tampaknya tidak rasional untuk mulai mengembangkan inti lintas platform baru bukan di .NET. Peluncuran platform open source .NET Core sangat disambut baik oleh kami, termasuk karena kompatibilitasnya dengan sistem operasi seperti Windows, Linux dan macOS.
Pertanyaan nomor 2 , yang perlu kami selesaikan, adalah bahwa sebagian besar solusi yang dibuat sebelumnya mengasumsikan pemrograman wajib untuk menambahkan atribut objek bisnis atau mengubah proses bisnis dalam sistem.
Ini terkait dengan dua aspek.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
Dan pertanyaan nomor 3 , yang telah kami hadapi selama bertahun-tahun, adalah ketidaksempurnaan arsitektur sistem yang sedang dibuat, yang tidak memungkinkan untuk menulis ulang beberapa bagian dengan cepat tanpa perlu menulis ulang modul individual, atau membuat ambang masuk yang cukup tinggi untuk pemrogram, analis, dan penguji saat terhubung ke proyek.
Masih banyak lagi pertanyaan dan masalah di pintu masuk proyek, yang akan dibahas nanti. Tetapi ketiga hal ini (substitusi impor dan sumber terbuka, kode rendah, ambang masuk rendah, dan tingkat pencelupan cepat anggota tim baru) kami menganggap sebagai kunci yang harus kami selesaikan.
Rancangan
Berpikir tentang pertanyaan-pertanyaan ini membawa kami pada kesadaran bahwa kami membutuhkan semacam konstruktor yang dapat "dimainkan" oleh analis dan merancang sistem (objek bisnis dan proses bisnis) sesuai dengan kebutuhan pelanggan. Kedengarannya berani, tetapi jauh lebih menarik daripada menulis sistem lain untuk pelanggan. Bahkan, kami memutuskan untuk membuat produk kami dalam bentuk konstruktor dan mengembangkannya.
Kami jelas tidak menemukan sesuatu yang revolusioner, dan ada cukup banyak produk serupa di pasaran, tetapi pada dasarnya penting bagi kami untuk menyelesaikan pertanyaan yang terkumpul, terutama karena, untuk alasan yang disebutkan sebelumnya, sulit bagi kami, secara halus, untuk mengikuti jalur refactoring sistem yang ada.
Pada tahap desain, kita harus memikirkan kembali fakta bahwa kita tidak selalu tahu sebelumnya siapa calon pelanggan kita, besar atau kecil, penuntut atau loyal, proses bisnis apa yang dia miliki, infrastruktur seperti apa. Beberapa persyaratan untuk sistem masa depan mulai muncul dengan sendirinya: Anda memerlukan penskalaan, Anda memerlukan lintas platform, Anda memerlukan penyesuaian objek bisnis / proses bisnis yang fleksibel dan cepat, antarmuka, mungkin integrasi "gerobak dan gerobak kecil". Itu menjadi menakutkan, sangat menakutkan.
Tapi, seperti yang dikatakan salah satu ketua tim kami, "Gajah perlu dimakan sedikit demi sedikit, mulai dari kaki." Pada tahap ini, kami menetapkan sendiri dua tugas: pilihan arsitektur layanan mikro dan pilihan alat. Ya, langsung saja layanan mikro (Martin Fowler merekomendasikan MonolithFirst , tetapi kami memutuskan untuk tidak mematuhinya), karena dengan monolit kami telah lama menjadi "Anda" dan inilah saatnya menerima tantangan untuk melanjutkan. Tapi serius, persyaratan penskalaan horizontal sistem saja sudah cukup, menurut kami.
Pilihan arsitektur dan alat
Saat mendesain arsitektur, kami mengejar beberapa tujuan:
- abstraksi alat yang digunakan agar dapat setiap saat mengganti alat yang tidak sesuai dengan yang lain;
- ( , );
- , .
Karena tim kami berspesialisasi dalam teknologi Microsoft, .NET Core versi 2.1 dipilih sebagai platform implementasi. Pada saat pengembangan produk kami dimulai, versi ini adalah LTS (dukungan jangka panjang), dan bagi kami ini adalah kriteria penting, karena beberapa sistem operasi domestik (tempat kami berpotensi dapat menyebarkan sistem) hanya mendukung versi .NET Core LTS ...
Mereka memutuskan untuk membuat Frontend di React + TypeScript, karena mudah dipelajari. Kami memutuskan untuk mempromosikan pendekatan tumpukan penuh pengembang.
Kami memutuskan untuk membuat komunikasi antar-layanan sinkron, karena rantai panggilan kami seharusnya pendek, dan komunikasi antar layanan masih abstrak. Sebuah layanan memanggil layanan lain melalui proxy abstrak. Dan itu bisa berisi logika apa pun. Dalam kasus kami, ini adalah panggilan ke layanan lain melalui http melalui Service Discovery. Desain ini memungkinkan kami, di satu sisi, untuk menyederhanakan kehidupan pengembang (mereka cukup menggunakan antarmuka layanan untuk memanggilnya, tetapi pada kenyataannya, dalam wadah layanan ASP.NET Core, implementasi terdaftar dari antarmuka ini adalah Proxy yang sama), dan di sisi lain - untuk menyediakan penskalaan horizontal sistem secara otomatis, karena kami selalu bertanya kepada Penemuan Layanan bagaimana memanggil layanan, dan yang, pada gilirannya, dapat memberikan salah satu contoh yang berjalan dari layanan ini.
Pada titik tertentu, struktur layanan menjadi standar, dan kami membuat ekstensi untuk Visual Studio, yang, ketika proyek baru ditambahkan ke solusi, menghasilkan struktur proyek dengan implementasi layanan minimal, sekali lagi, sehingga pengembang tidak perlu melakukan rutinitas ini. Selain itu, kami membuat beberapa skrip untuk meluncurkan seluruh sistem dengan sedikit gerakan tangan (kemudian kami memikirkan penerapan cepat yang sama dari orkestrator ringan dari pengembang).
Proses seleksi juga cukup menarik. Kami harus memutuskan fungsionalitas mana yang kami tulis sendiri dan mana yang kami ambil "di luar kotak" (berbicara tentang alat yang ada), tetapi, tentu saja, mengabstraksi semua interaksi dengannya, sehingga, jika perlu, akan memungkinkan untuk mengganti alat atau pustaka ini dengan implementasi lain. Kami membutuhkan alat berikut: mesin telusur, mesin proses bisnis (Mesin BPMN), protokol penemuan layanan (Penemuan Layanan), penjadwal. Kriterianya berbeda: lisensi, kecepatan kerja, kecepatan keterlibatan tim proyek, dll. Hasilnya adalah daftar berikut: Elasticsearch, Camunda, Consul, Hangfire.
Kami segera memberikan dukungan untuk setidaknya PostgreSQL dan SQL Server, tetapi berfokus terutama pada PostgreSQL dan penerapan di Linux. Software gratis, lho. Dalam hal ini, sebuah cerita yang aneh terjadi. Kami meletakkan dukungan untuk SQL Server pada tahap awal, tetapi tidak benar-benar berharap bahwa beberapa pelanggan potensial kami akan tertarik untuk menerapkan di Windows + SQL Server, jadi kami menunda pengujian konfigurasi ini sampai nanti (bagaimanapun, selalu diketahui sebelumnya lingkungan apa yang dimiliki pelanggan?!) ... Dan kemudian suatu hari, membuat uji coba lain untuk pelanggan potensial, kami sudah siap untuk menerapkan AltLinux + PostgreSQL seperti biasa, tetapi tiba-tiba kami mengetahui bahwa pelanggan tetap berubah pikiran dan memutuskan untuk menerapkan di Windows + SQL Server, dan kami memiliki dua hari untuk melakukan semuanya mempersiapkan. Untungnya, kode yang ditulis lama dan dilupakan berguna,yang memberikan dukungan ini kepada kami dengan perbaikan kecil, dan kami berhasil menyiapkan semuanya tepat waktu, dan sistem bekerja seolah-olah tidak ada yang terjadi (kemuliaan bagi .NET Core).
Implementasi ide bisnis
Kami mendekati implementasi dengan daftar tahapan kerja yang telah disiapkan, dan yang terpenting adalah mendapatkan MVP (produk yang layak minimum) dalam waktu dekat. Hampir dari iterasi pertama, kami mulai bekerja dengan penekanan pada mendapatkan prototipe secepat mungkin dengan bagian visual yang dapat didemonstrasikan kepada pelanggan (yang merupakan pemimpin kami pada awalnya) secara berkala. Pendekatan ini, seperti yang diharapkan, berkontribusi pada pemikiran ulang dari beberapa konsep yang sebelumnya dipahami. Saya berhasil menangkap beberapa kontradiksi dan melawannya terlebih dahulu. Ini tentang merancang API Web untuk komunikasi frontend dan backend.
Konstruktor objek bisnis
Telah disebutkan di atas bahwa salah satu ide kunci dari produk ini adalah kemampuan untuk membuat struktur objek bisnis oleh pengguna konfigurator. Kami sebenarnya mulai dengan implementasi konstruktor objek bisnis. Versi pertama, tentu saja, lebih konseptual, tetapi kemudian memberi kita banyak bahan untuk dipikirkan. Objek bisnis yang dulunya sederhana dengan beberapa bidang sederhana kemudian berkembang menjadi unit multifungsi multi-level dengan berbagai macam pengaturan. Kami mempelajari cara mengonfigurasi tidak hanya bidang sederhana, tetapi juga bidang dengan pilihan dari direktori hierarki, kumpulan objek terkait dengan pemfilteran, dan sebagainya.
Objek bisnis yang dihasilkan oleh mouse konfigurator memiliki cukup metadata untuk menyusun registri yang dapat dicari dan berbagai bentuk presentasi.
Masalah memvalidasi objek bisnis juga tidak luput dari kami. Kami dengan cepat menemukan bahwa validasi tidak bisa tidak disertai dengan logika bisnis yang diperlukan pada tahap pengisian objek bisnis dengan data. "Jika" bidang 1 "memiliki" nilai 1 ", maka" bidang 2 "perlu disembunyikan" atau "Bidang 1 adalah jumlah dari bidang 2 dan bidang 3" hanyalah beberapa contoh paling sederhana yang dapat diberikan. Berapa lama waktu yang singkat, dan kami sekarang memiliki mesin acara di mana perilaku seperti itu dapat dikonfigurasi. Acara juga dapat dikonfigurasi dengan mouse. Banyak opsi telah diterapkan, termasuk penghitungan yang rumit. Tapi ini topik untuk percakapan lain. Silakan tulis di komentar jika Anda menyelesaikan masalah serupa, akan menarik untuk bertukar perasaan.
Desainer Proses Bisnis
Seperti yang ingin kami ulangi: "Siapa yang membutuhkan objek bisnis tanpa proses bisnis?"
hasil
Satu setengah tahun telah berlalu sejak dimulainya proyek. Tim telah meningkat sepuluh kali lipat,
Hal pertama yang tampak sangat keren adalah kenyataan bahwa semakin banyak fungsionalitas yang kita buat, semakin banyak ide yang kita dapatkan. Rasanya kami tidak bergerak dari awal proyek hingga penyelesaiannya, tetapi hanya dari awal dan selanjutnya - ini adalah aspek penting. Setelah bertahun-tahun mendukung solusi siap pakai (dan ini sangat sering terjadi dalam kehidupan spesialis TI), keadaan ini sangat memotivasi.
Keduaperasaan mega adalah menyaksikan tim yang termotivasi dan berada di dalamnya. Proses pembuatan produk baru tidak hanya berupa urutan tugas dan tahapan. Ini, pertama-tama, atmosfer. Suasana kenyataan bahwa Anda sangat sering melakukan sesuatu yang belum pernah Anda lakukan sebelumnya, meskipun Anda telah berpartisipasi dalam puluhan proyek. Setiap anggota tim menghirupnya dan pada suatu saat menyadari bahwa dia meninggalkan zona nyaman setelah menghembuskan napas pertama. Dan tugas tersulit dan utama adalah membuat suasana ini menjadi segar, nyaman dan menarik. Kita tidak bisa bersembunyi dari bug, tenggat waktu, dll., Tetapi kurangnya lingkungan yang mendukung di mana kita semua menemukan diri kita sendiri bisa jauh lebih merusak.
Kami berusaha memberikan perhatian khusus pada proses pengembangan produk kami. Proses ini tidak statis. Dia mengalami perubahan, jika perlu, tetapi dia memungkinkan untuk menyelesaikan masalah dengan nyaman dan membantu rekan-rekannya melakukannya.
PS Sulit untuk mendeskripsikan semuanya secara rinci dalam satu artikel, jadi ternyata lebih banyak gambaran. Kami sangat berharap Anda menemukan sesuatu yang menarik di dalamnya, dan kami akan dengan senang hati menjawab pertanyaan Anda di komentar, atau menjelaskan beberapa aspek dari sistem kami secara lebih rinci di artikel terpisah.