Luar biasa produk Anda masih berfungsi

Sekarang saya akan memberi tahu Anda rahasia pintu terbuka. Siap?



Sebagian besar perangkat lunak ditulis dengan sangat buruk. Pada saat yang sama, mereka mendapat uang dari itu. Ini dapat memiliki jutaan pengguna, dapat diterjemahkan ke dalam beberapa bahasa, namun, dari sudut pandang kode sumber dan arsitektur, menjadi kompilasi omong kosong dari antipatterns dan kode spageti yang akan berantakan pada permintaan pertama yang salah dihasilkan.

Begitukah, mengapa dan apa yang harus dilakukan.

Cepat bagi mereka yang berpikir bahwa ia memiliki produk yang baik untuk dirinya sendiri dan Anda tidak dapat membaca lebih lanjut.

Pertama untuk teknisi. Jawab diri Anda: Anda mengikuti prinsip-prinsip kode bersih, SOLID, KERING dan segala sesuatu yang tertulis dalam artikel dan tentu saja Anda tidak memiliki nilai magis dalam kode tersebut. Anda benar-benar memiliki cakupan pengujian 100%, Anda memiliki CI / CD otomatis yang jujur, REST Anda menggunakan semua kode HTTP yang diperlukan, bukan hanya 200, 201, dan 404. Semua titik akhir dan utang teknis minimal dijelaskan dengan sempurna, dan kode lawas disempurnakan ulang di sana ? Jika tidak, maka Anda sendiri mengerti segalanya. Dan saya masih tidak berbicara tentang pemantauan, dan banyak hal.

Sekarang untuk para manajer. Kawan, kau tidak bekerja di air terjun, kan? Ya, scrum Anda jujur, Anda tidak menyamakan poin cerita dengan jam atau hari dan melakukan perencanaan poker, mendiskusikan hasilnya, kan? Dan Anda pasti tidak memiliki tugas pemblokiran dalam sprint dan defenisi yang dilakukan, dan setelah implementasi tugas tersebut segera masuk ke produksi. Anda memiliki peta jalan produk, dokumentasi, dan tugas-tugas yang diberikan kepada pengembang berisi lebih dari tiga kata dan menjelaskan mengapa kami melakukan ini, apa yang kami lakukan, bagaimana menguji dan apa yang akan menghasilkannya. Dan semua kasus bisnis dijelaskan ... Dan ini hanya beberapa hal yang perlu dilakukan, kita semua tahu.

Mereka yang memiliki semua ini, Anda bisa selesai membaca artikel. Anda sudah memiliki produk yang sangat bagus. Berikan saya referensi untuk itu, jika mudah, saya akan melihat dengan senang hati.

Bagi mereka yang masih di sini, dan saya pikir sebagian besar dari Anda, mari kita mengerti mengapa ini terjadi dan mengapa itu cocok untuk semua orang.

Ini terjadi karena manajer paling sering tidak mengerti apa-apa dalam pengembangan. Mereka memahami ROI dan KPI, mereka menerima MBA, dan jika mereka memiliki semacam latar belakang seperti pendidikan semi-spesialis, maka mereka tidak melangkah lebih jauh dari Hello World yang bersyarat. Secara umum, tenggat waktu mereka ada, dan membusuk tugas dengan benar ke MVP, tanpa pengetahuan teknis, cukup sulit. Ini menambahkan ketidaksukaan programmer kepada manajer, mereka jelas tidak akan membantu mereka. Jadi tetap bagi manajer untuk menulis cerita atau novel dengan cerita dan menghasilkan metrik tidak langsung untuk memahami apakah tugas ini atau itu dilakukan secara kualitatif. Ya, hanya semua metrik ini sintetik, tidak ada hubungannya dengan kualitas pengembangan, atau sangat tidak langsung.

Dan bagaimana dengan para pengembang. Ya, sebenarnya tidak ada, kebanyakan dari mereka tidak menginginkan apa-apa, dia sudah memiliki pengetahuan yang dimaksud surat-surat ini. Manajer masih tidak mengerti apa-apa, jadi di sini kami menggunakan beberapa antipatterns dan menempelkan beberapa kruk, mulai kompilasi tanpa tes, tapi mengapa memulai, ... dan mari kita minum kopi. Semuanya diputuskan berdasarkan pengalaman. Yah, tetapi fakta bahwa mereka melanggar penyebaran, itu tidak masalah;

Hampir tidak ada yang mau memahami teorinya, di industri ini ada banyak dari mereka yang tidak tahu bagaimana kerangka kerjanya, tetapi hanya tahu metode mana yang digunakan. Jadi untuk berbicara, gunakan sihir. Karena kurangnya pengembang, tingkat profesionalisme telah menurun secara signifikan.

Saya mengerti bahwa tidak ada yang suka kritik, tetapi pendekatan seperti itu sangat dekat. Mereka tidak akan melakukannya dengan cara itu, tidak akan ada apa yang saya jelaskan di paragraf pertama.

Sekarang mengapa itu cocok untuk semua orang. Ya, ya, sangat cocok untuk semua orang. Mereka yang tidak puas dengan hal ini, tidak mengerjakan produk-produk ini, atau memperbaiki mereka dan mengembalikannya ke bentuk normal.

Situasi ini cocok untuk manajer karena mereka bahkan tidak memahami besarnya masalah. Produk sudah menyala dan oke, dan pengguna akan menemukan bug di pagi hari. Mereka menulis dalam laporan, mendapat centang, koki memuji. Mereka tidak berlebihan, jadi programmer harus disalahkan. Secara umum, ketika ada seseorang untuk didorong, maka tidak ada yang perlu diperbaiki.

Mengapa ini sesuai dengan programmer? Mungkin karena banyak yang tidak bisa berbuat lebih baik, karena untuk melakukan yang lebih baik Anda harus terus-menerus memperbaiki diri sendiri. Dan bagi banyak orang bahkan tidak ada pertanyaan: mengapa, jika uang itu sudah dibayar. Anda membaca ebanoe.it, mereka langsung disarankan untuk bekerja sebanyak mungkin agar tidak dikeluarkan. Dan itu tidak ada artinya.

Jadi ternyata lingkaran setan, ada yang tidak bisa, ada yang tidak mau.

Apa hubungannya dengan itu? Setiap hari berkembang. Perbaiki tugas, pendekatan, terapkan praktik dan prinsip terbaik. Tidak setuju dengan fakta bahwa Anda ditawari untuk melihat-lihat. Buat agar Anda tidak malu untuk menunjukkan proyek Anda kepada orang luar. Dan lakukan di kedua sisi. Tidak ada resep lain.