Beberapa waktu lalu, saya mengamati distorsi teknik yang diterapkan dalam produksi perangkat lunak. Setelah masuk jauh ke dalam rincian (penerapan DDD), saya ingin mengisyaratkan kepada pembaca bahwa, setelah memimpin manajemen burung hantu, seseorang tidak dapat memenuhi tugasnya sebagai seorang insinyur.

Sebuah artikel profil tinggi baru-baru ini tentang raja-raja telanjang industri membuat saya menyadari bahwa saya masih ingin mengekspresikan pemahaman saya tentang apa jenis programmer yang saya inginkan dan apa yang ingin saya lihat - insinyur yang memahami konteks pekerjaan mereka, peran mereka, dan metode apa yang harus diikuti . Di bawah potongan, saya mengundang pembaca untuk berpikir dengan saya tentang apa yang kita lakukan pada umumnya dan apa yang memaksakan pembatasan pengembang dalam kegiatan mereka.

Tentang penyebab kontradiksi

Saya akan mulai dari jauh - dari abad XVIII. Pengembangan dan sosialisasi produksi, ditambah dengan persaingan, memacu produsen berulang-ulang untuk memodernisasi dan mengotomatisasi produksi. Mesin uap, alat tenun Jacquard, konveyor, jalur produksi dan robot - semua peningkatan ini memainkan peran ekonomi mereka - memberikan keunggulan kompetitif, sebagai prasyarat untuk sosialisasi tenaga kerja yang lebih banyak lagi, yaitu penyatuan rantai produksi. Akibatnya, produksi berkembang, mereka dapat merencanakan pengembangan dan otomasi mereka untuk menerima keuntungan yang lebih besar.

Tentu saja, bisnis apa pun selalu memiliki alternatif untuk metode laba. Misalnya, sewa tenaga kerja yang lebih murah, manajer yang efektif yang akan dapat menurunkan tiga kulit dari pekerja ini. Namun, jika Anda, seperti saya percaya bahwa umat manusia tidak boleh diam, tetapi bergerak maju menuju kemajuan, maka Anda akan setuju dengan saya bahwa ini bukan pilihan yang cocok untuk kita. Ya, semua toko tanpa penjual ini sangat ketakutan, karena drone semakin banyak mengirimkan barang, bahwa AI siap untuk menggantikan pengemudi, dan sebagainya. Para ekonom takut dengan kemunculan industri dengan biaya nol. Namun, insinyur, perancang, penemu, arsitek, dan hanya ilmuwan masih harus melakukan pekerjaan mereka - untuk mengurangi biaya produksi dengan meningkatkan kualitasnya - ini adalah tugas sosial-ekonomi kita.

Agar tidak membicarakan hal-hal yang terlalu tinggi, saya mengusulkan untuk turun ke kegiatan langsung kami. Untuk bisnis, selalu ada pilihan - menempatkan 10 orang dalam 10 unit untuk melakukan pekerjaan sederhana, atau 4 orang dalam 25 unit akan mengotomatiskan pekerjaan ini, dan kemudian melayaninya. Dan pemahaman Anda yang jelas tentang seluk-beluk kebutuhan bisnis dan persyaratan teknik dapat membantu membuat pilihan ini menuju jalur pengembangan intensif. Dan apa artinya bagi pelanggan untuk memilih jalan seperti itu?

Sebagian dari hari kita bekerja untuk diri kita sendiri, dan sebagian hari untuk majikan atau pelanggan. Saya akan membiarkan diri saya mengekspresikan ini dengan rumus nilai berikut:

dimana

c adalah modal tetap , mis. alat organisasi yang memungkinkannya untuk melakukan aktivitasnya (komputer, perangkat lunak, dll.)
v - gaji karyawan.
m adalah keuntungan nosional dari mereka yang memiliki produksi.

Dalam hal pengembangan perangkat lunak, ada nuansa - jika perangkat lunak adalah bagian layanan dari bisnis yang terus berkembang, maka Anda harus melakukan beberapa pekerjaan langsung yang tidak terkait dengan penyelesaian masalah bisnis. Rasakan perbedaannya - apa yang bisa dihabiskan untuk beberapa orang dengan keterampilan kurang dihabiskan " untuk pekerjaan demi pekerjaan di masa depan ." Jika kita mentransfer ini ke formula, itu berarti bahwa kita bekerja mendukung modal konstan c , kita harus mengeluarkan uang dari gaji seseorang v , dari laba m atau dari biaya barang W. Harus dipertimbangkan lebih detail.

Jadi, misalnya, jika Anda mengusulkan untuk mengerjakan arsitektur monolith Anda dan memecahnya menjadi layanan-layanan mikro, tetapi pelanggan Anda tidak memiliki kebutuhan langsung untuk ini, berapa biaya yang harus dikeluarkan untuk kecanggihan teknik?

• m - pelanggan dapat melepaskan keuntungannya. Nama investasi ini, mis. risiko terkendali dari laba yang lebih besar Dalam hal ini, risikonya harus diakui. Jika Anda memutuskan untuk belajar cara membuat kompleks besar untuk uang orang lain - ini adalah risiko yang tidak terkendali. Hal lain, sebagai bagian dari retrospektif, misalnya, adalah melakukan eksperimen kecil, mengevaluasi hasilnya dan bergerak maju lebih jauh.

  
  

• W - pelanggan dapat menaikkan harga produk dan layanan mereka. Monopoli bisa sangat mampu untuk meningkatkan biaya dan kemungkinan besar mereka melakukannya. Tetapi kemungkinan besar pelanggan selalu terguncang oleh kondisi pasar.

  
  

• v - Anda dapat melepaskan gaji orang lain, dan ada opsi.
  1) Anda akan mengorbankan milik Anda. Anda akan memproses atau membuat proyek Open Source yang akan membantu Anda di tempat kerja.
  2) Anda mengotomatiskan pekerjaan orang lain, yang akan memungkinkan lebih sedikit orang untuk menggunakannya.

  
  

  Sayangnya, orang naif seperti saya memilih opsi 1. Tetapi jika Anda berhasil dalam 2, maka Anda secara kualitatif mengubah rantai produksi: itu hanya membutuhkan lebih sedikit tangan dan lebih sedikit orang dengan keahlian yang dapat membuat dan memodifikasi proses dengan benar.

  
  

Masalah dengan tim adalah bahwa ia tidak memutuskan apa yang harus dilakukan. Tapi itu bisa mengarah pada argumen dan bisnis tidak akan tersentuh oleh apa pun selain yang material - keindahan kode, kerangka kerja baru, teknik modis - ini bukan tentang uang. Ada hubungan dalam investasi dalam kompleksitas teknologi dan kebutuhan bisnis. Seseorang harus sesuai dengan yang kedua.

Antagonisme persyaratan

Perangkat lunak adalah solusi kompleks yang merupakan keseimbangan dari dua kontradiksi dialektik: persyaratan bisnis dan arsitektur. Ketika menilai kompleksitas merancang sistem tertentu, akan sangat mudah untuk melewatkan argumen dari pihak-pihak yang ditentang oleh sifatnya. Penting untuk memahami konteksnya, tugas apa yang dihadapi Anda, terlepas dari peran Anda dalam proyek: Pemilik Produk atau tim .

• Sisi bisnis (PO, SH) ingin bekerja sehingga menghabiskan paling sedikit sumber daya di atasnya. Sayangnya, menyajikan posisi ini sangat sederhana, karena telah merambah tidak hanya kehidupan kita, tetapi juga cerita rakyat IT - burung hantu adalah manajer yang efektif, contoh yang paling mencolok.
• Pelaksana (Tim) perlu melakukan serangkaian pekerjaan untuk memastikan solusi dari aspek-aspek utama arsitektur untuk menyelesaikan masalah bisnis, tanpa mengumpulkan utang teknis, idealnya, dan alat untuk memecahkan masalah dengan lebih cepat. Tim bisnis adalah pasokan perangkat lunak, dan arsitekturnya adalah modal konstan yang tersedia untuknya.

Untuk menemukan penyebut yang umum, saya sarankan untuk mengajukan pertanyaan berikut kepada pelanggan sebelum setiap proyek baru:

• Apa yang sebenarnya kita lakukan untuk pelanggan, apa manfaat yang diharapkan?
• Frekuensi penerapan solusi ini.
• Kemungkinan perubahan / persyaratan ekspansi.
• Apakah ada koneksi dengan sistem / layanan / konteks lain?

Jumlah persyaratan pada bagian bisnis dan arsitektur harus proporsional, jika tidak kelas tugas yang diajukan dan diselesaikan tidak proporsional, dan jika persyaratan tumbuh dari satu sisi atau yang lain, solusinya dapat ditunda atau direstrukturisasi. Dengan kata lain, agar pelanggan dapat memecahkan masalah mereka dengan lebih baik, kita juga harus memiliki sarana yang tepat untuk menyelesaikan masalah pengembangan. Yaitu pengelasan gas dan palu godam, tidak ada yang akan membangun roket untuk astronot.

Jadi, jika tugasnya kecil , dan pelanggan harus menyelesaikannya dengan sumber daya minimum, jika tugas itu tidak diulangi, tidak terhubung dengan sistem besar, solusi TransactionSript, klien yang cerdas, dan semua pola-anti dapat diterima. Mari bersikap realistis - ada masalah seperti itu, dan mereka harus diselesaikan dengan cara yang sama, terkadang sangat cepat (tapi kami tidak lupa untuk menandainya dengan hutang teknis). Tetapi hanya dalam kasus ini, jangan tertipu oleh model anemia dalam pipa dan setengah ukuran lainnya.

Tugas yang terkait dengan sistem yang ada dapat diselesaikan berdasarkan sistem yang ada, membuat analisis minimum proses internal, jika tugas tidak diperluas atau perubahan persyaratan tidak diharapkan, solusi TableModule, Shared database, dll dapat diterima.

Persyaratan bisnis yang signifikan dapat membuat tuntutan signifikan pada arsitektur (misalnya, peningkatan ketersediaan, otorisasi, toleransi kesalahan, kinerja). Pada gilirannya, arsitektur dapat membuka peluang untuk memecahkan masalah baru (yang terutama terkait dengan transisi ke template arsitektur yang lebih kompleks dan menghindari skenario tertentu).

Sangat sering di konferensi dan pertemuan, pengembang bertanya kepada pembicara: bagaimana meyakinkan majikan kita bahwa mereka perlu mencurahkan waktu untuk sesuatu (tes, arsitektur, dokumentasi, dll.)? Untuk tugas-tugas kelas atas, mungkin tidak ada alternatif. Alasannya adalah siklus hidup produk, layanan, dan organisasi.

Siklus teknologi menentukan (pada batas waktu yang sama) pengembangan - untuk memasuki tahap pengembangan selanjutnya, perlu melampaui batas-batas proses teknologi saat ini. Yaitu perluas praktik Anda, coba sesuatu yang baru, buat eksperimen terkontrol.

Secara bertahap, karena jumlah solusi platform kompleks melebihi jumlah tertentu, itu akan berubah menjadi pertumbuhan kualitatif. Biaya negatif untuk hutang teknis, arsitektur dapat menjadi investasi dalam tugas-tugas yang lebih kompleks, menyangkal tujuan semula.

Agile, CI, DDD, dll. memungkinkan Anda untuk mendorong batas proses. Bidang pengetahuan dan metodologi ini, yang membantu mengevaluasi kerumitan tugas dalam banyak hal, membangun kerja tim. Benar menganggap hal-hal ini sebagai holistik , sebagai kesempatan bagi banyak orang untuk berkontribusi banyak untuk mendapatkan hasil yang Anda butuhkan!

Dari keseimbangan persyaratan untuk keseimbangan kerja

Ketika berbicara tentang siklus hidup perangkat lunak, pelatih yang modis dan pelatih Agile tidak akan mengingat diagram I. Adizes yang terkenal.

Semua yang ada di dalamnya bagus dan indah, tetapi satu sisi. Jadi subjektivitas model tidak mencerminkan proses organisasi internal. Banyak tim setuju dengan bisnis berapa banyak waktu yang akan mereka habiskan untuk hutang teknis dan berbagai aspek arsitektur. Saya menawarkan pemikiran saya tentang hal ini - sumbu siklus teknologi (OTC).

Sumbu absis dianggap sebagai kompleksitas fitur bisnis. Sumbu ordinat adalah kompleksitas pekerjaan arsitektur. Yang saya maksud dengan kompleksitas adalah poin cerita klise. Menunda kinerja fitur pada grafik ini, Anda dapat melihat seberapa adaptif Anda terhadap perangkat lunak yang Anda rilis untuk perubahan selanjutnya.

• Semakin tepat titik terakhir grafik relatif terhadap OTC , semakin dini produk akan berguna dan semakin sulit dikembangkan untuk tugas-tugas kompleks.
• Di sebelah kiri titik terakhir grafik relatif terhadap OTC , semakin Anda terbawa oleh platforming, dan Anda berisiko tidak menyediakan perangkat lunak yang berfungsi sesuai tenggat waktu.
• Oleh karena itu, layak untuk mengikuti pengembangan yang seragam, yaitu gerakan di sepanjang sumbu.

Pada gambar di atas, ide saya tentang bagaimana waktu yang dihabiskan untuk mengimplementasikan peluang bisnis X dan arsitektur Y terlihat, di mana sumbu Z mencerminkan kegunaan produk.

Kesimpulan

Jika tugas bisnis memerlukan arsitektur yang kompleks, maka akan muncul, dan sebaliknya, arsitektur dapat menjadi pendorong untuk memecahkan masalah yang kompleks, yang tetap harus memiliki prasyarat - kemungkinan optimasi proses. Ketika pelanggan memiliki sejumlah tugas kompleks yang sulit diselesaikan dengan alat saat ini, ada kemungkinan bahwa mereka dapat diselesaikan dengan bantuan perubahan kualitatif. Untuk sampai pada perubahan kualitatif, perubahan tertentu harus diakumulasikan secara berurutan. Sebagai contoh, untuk beralih ke layanan-layanan mikro, monolit sering secara konsisten dibagi menjadi konteks dan agregat terbatas, dan CI secara konsisten dicapai. Dan sebaliknya, sebagai kasus ketika Anda harus menambahkan fungsionalitas ke kode Legacy, dan untuk ini untuk melakukan refactoring berurutan.

Pekerjaan arsitektur yang kompleks - kontribusi Anda dapat membantu bisnis menjadi lebih menguntungkan dan kompetitif. Pada saat yang sama, menjadi penting untuk menghindari kompromi dan kompromi pendekatan dalam desain dan implementasi demi keuntungan cepat dan sesaat. Hari ini Anda akan membesarkan KPI seseorang, dan besok Anda tidak akan dapat membuat fungsionalitas baru tepat waktu karena akumulasi masalah produk.

Saya sarankan melihat hubungan antara penyetelan dan bisnis dalam laporan oleh perang Cyril Skrygan Platform (IDE) .