Mengapa proyek ditulis ulang dan mengapa gagal

Tema kuno - dapatkah Anda atau tidak dapat menulis ulang produk yang besar dan berfungsi dengan basis pengguna aktif? Jawabannya, secara umum, adalah - ya, Anda bisa. Satu-satunya pertanyaan adalah bagaimana caranya? Setelah melihat beberapa upaya serupa di masa lalu (baik yang berhasil maupun yang tidak), artikel ini adalah pandangan penulis tentang masalah ini.



Kode buruk, proses pembuatan yang terlalu rumit, teknologi usang, bahasa pemrograman yang buruk - semua masalah ini, dan banyak lagi lainnya, menyertai setiap proyek besar yang cukup berhasil, proses pengembangan perangkat lunak apa pun di organisasi mana pun. Seperti yang diperlihatkan oleh praktik, dalam banyak kasus, situasinya hanya menjadi lebih buruk dari waktu ke waktu - ketidaknyamanan kecil berkembang menjadi "fitur pekerjaan" yang tidak menyenangkan, skor terus meningkat saat merencanakan tugas, dan kualitas produk jadi mulai menurun. Sentuhan terakhir untuk gambar ini adalah kegagalan untuk memenuhi tenggat waktu dan rencana karena ketidakmungkinan fungsi debugging, atau bahkan mengirimkannya ke lingkungan kerja. Seringkali, dalam situasi seperti itu, kami mengatakan bahwa hutang teknis telah menumpuk.







Hutang ini muncul dengan cara yang sepenuhnya alami dan mengikuti semua sistem, tidak peduli seberapa suksesnya, ketika ada produk itu sendiri, penggunanya, saluran komunikasi dengan mereka. Tidak peduli apakah produk tersebut dijual secara langsung, atau merupakan bagian tambahan dari bisnis perusahaan, yang penting produk tersebut telah beroperasi dalam waktu yang lama. Pengguna ingin mendapatkan fungsionalitas baru (mungkin mereka bahkan akan membayarnya), manajemen ingin menyediakannya kepada pengguna sesegera mungkin, karena departemen pengembangan, di bawah tekanan tenggat waktu, menerapkan perubahan yang diperlukan. Prosesnya berulang berkali-kali, dan cepat atau lambat seseorang akan dengan lantang berkata - "sepertinya kita punya hutang, mungkin masalah teknis!"







Semua orang mulai memperhatikan bahwa setiap tugas baru lebih sulit daripada yang sebelumnya, dan ini bukan lagi kebetulan, kompleksitasnya tumbuh secara eksponensial. Ada tempat "rapuh" dalam kode yang sebaiknya tidak disentuh, lebih sering cacat dari pengguna dan alarm dari sistem untuk memantau lingkungan kerja "tiba". Pertama, inisiatif untuk memperkenalkan teknologi dan praktik baru yang dirancang untuk meningkatkan kualitas produk secara keseluruhan ditunda, dan kemudian dilupakan sama sekali. Ide umum terbentuk bahwa ada sesuatu yang salah, pencarian alasan untuk apa yang terjadi dan siapa yang harus disalahkan dimulai. Tentu saja, tidak ada yang baik dalam keadaan ini, terlebih lagi - hal negatif mulai meracuni atmosfer tim.







, , β€” , , , , , , , , , , .







, , , , , , . , β€” , ? , .









, . , . , , , - β€” , ? , ? ? , ? . , , , , β€” , . β€” .







β€” , , , , . , , . β€” . , IDE , , . .







β€” , :







  • , ? - , .
  • - , - , .
  • , , .
  • , .
  • , , , , .
  • - , , .
  • , - , .


, β€” , , . . , β€” , , . , β€” , , .







. , , . β€” , . β€” . β€” ? .







β€œ ?”. ! , 100% β€” , - , , . , , , β€” 50/50, 60/40, . β€” , , .









, , β€” , , . ! ! ! β€” . .







, , β€” , .







, β€” , , , β€” . , β€” ? , , . , Flash β€” , , . , , β€” . , , , .







. β€” , , β€” , . , , . , … , .







, . , , , , , . , , - . , , , β€” , , , , β€œ ”, . ? , , . , , , β€” .







? β€” . , β€” . , , , . , .









β€” , : , , , .. , , . , , , . . , , , , , β€” , . , β€” , . β€” , . β€” , , , , .







β€” , , , . . , , , . , , , , β€” .







, , . β€” , , , . , . - Terra incognita, . - - , , , - ( ) . - , - , . , , .







, , . . , . , API. http- . β€” , - , offline-, - Selenium-, UI, . , API.







, , . β€” . , . API , , -, ? , ? , , β€” , β€” .









. , , , , β€” . , , β€” . , :







  1. ,


- ? - β€” . β€” , . β€œ, ”: β€œ , , , , ”. , , β€œ ” , , , β€” , β€œβ€ , . , ?







, β€” , API, .. β€” , - . . , , , , , , . , , .







, . β€” , , , . , , , , , , , , . , β€” , . , , - , , , , . , , , , , , β€” , . .







β€” , , . , , , , : , , . β€” , .







, , , , β€” , . , β€” , .







, , - . . β€” β€œβ€, β€œβ€. , , .









, , , . , , web-, , β€” , . , , , β€” β€œβ€? ? , ? , . , , ?







, , , β€” . Twitter, , , , , . , , . , Ruby on Rails, JVM, . .







, β€” , . , , , . , , , , . , (-, ) . , . , .







. , , . β€” , , , , . , . β€” , , β€” .







P.S.



Semua yang tertulis di atas berlaku, tentu saja, untuk produk perangkat lunak besar yang berfungsi dengan basis pengguna aktif. Dan hanya untuk kasus-kasus ketika tidak mungkin untuk hanya merilis versi baru dari produk bersama dengan yang lama, seperti yang terjadi, misalnya, dengan Basecamp dan apa yang disebut. Perangkat lunak "kotak".








All Articles