Karena itu, saya bekerja pada penelitian saya tentang kesulitan mendukung Legacy, dan saya memperhatikan satu hal yang jelas bahwa saya benar-benar kehilangan pandangan.
Pengguna IDE dan pengembang IDE memiliki masalah dalam memahami alat mereka. Digunakan secara intuitif dan bagaimanapun juga. Anehnya (menyenangkan), penggunaan tersebut hampir tidak bertentangan dengan ketidaktahuan, meskipun menimbulkan holivar yang sesuai di forum.
Sekarang kita akan menganalisis bagaimana hal-hal dalam pengembangan dengan alat, apa yang salah dengan konsep "IDE", dan alat mana yang seharusnya muncul, tetapi belum dikembangkan.
E
Tidak akan menjadi penemuan bahwa lingkungan berbeda untuk proyek yang berbeda. Bahkan jika mereka bekerja pada satu tumpukan. Dapat digunakan:
- Berbagai cara berinteraksi dengan pengguna, yang memberikan perbedaan besar tentang bagaimana proyek dimulai dan bagaimana itu diuji. (CLI, TUI, moncong web, GUI dalam arti Qt, GTK, dll.)
- Kerangka kerja pengujian yang berbeda (unittest dalam satu proyek, pytest dalam yang berdekatan, dalam konteks Python). Binding tes bertingkat (misalnya, menggabungkan kesimpulan dari tes yang berdiri sendiri dan integrasi melalui TAP) juga jatuh di sini.
- VCS berbeda, tetapi di suatu tempat mungkin ada hibrida (Git, sebagai klien untuk Subversion dalam kasus khusus).
- Dalam proyek yang sama dapat digunakan, termasuk berbagai editor. Misalnya, Vim atau nano untuk mengedit skrip rebase interaktif di Git, untuk mengedit potongan dengan pendaftaran sebagian perubahan. Atau untuk mengedit konfigurasi dari bawah root.
Dan ini jauh dari semua opsi, saya pikir setiap pengembang dengan pengalaman 2 atau lebih proyek dapat memberikan lebih banyak contoh serupa. Seringkali saya mendengar mereka dalam bentuk cerita "Bagaimana saya menghabiskan dua hari untuk membuat proyek untuk pekerjaan baru."
Dari sini kita dapat menyimpulkan bahwa tata letak dan konfigurasi lingkungan pengembangan dalam hal apa pun terletak pada pengguna.
Terintegrasi?
Mengingat hal di atas, masuk akal untuk mempertimbangkan tidak lingkungan "terintegrasi", tetapi "terintegrasi" .
Kemudian, dari sudut pandang pengguna, alat integrasi yang baik adalah ketika:
- Lingkungan diatur dengan cepat.
- Konfigurasinya dapat disimpan dan ditransfer.
- Kemampuan untuk mengembalikan lingkungan kerja "satu tombol".
Misalnya, Unixoids yang berpengalaman sering mengurangi "transisi ke mode kerja" menjadi satu tim.
"Cepat" di sini tidak berarti "mudah bagi pemula . " Secara pribadi, posisi saya pada masalah ini adalah: ketergantungan kompleksitas dari solusi masalah pada kompleksitas tugas itu sendiri harus paling tidak linier.
Poin tidak jelas lainnya: antarmuka mungkin tidak seragam.
Contoh paling umum adalah menggunakan GUI dan CLI dalam sebuah proyek.
Saya berbicara tentang penggunaan beberapa editor ketika bekerja di lingkungan yang sama pada satu proyek.
Pengembangan
Sekarang kita dapat melanjutkan langsung ke alat itu sendiri.
Peramban Reaktor
Tidak mungkin membuat refactor browser yang kuat dan universal hanya karena refactoring tidak ada sekarang, karena, secara kondisional, suatu disiplin akademis.
Buku Fowler , bagaimanapun, dibangun di sekitar Jawa dengan langkah-langkah minimal ke samping. Plus, teknik refactoring sangat melekat pada konteks "style-language-library" sehingga dihasilkan langsung di tempat oleh setiap programmer.
Saya percaya bahwa prinsip-prinsip dasar refactoring dapat dijelaskan dari sudut pandang melintasi pohon data dalam bagian kode, dan teknik-teknik khusus sudah dapat diambil darinya . Untuk melakukan ini, implementasi refactor browser harus memiliki:
- Antarmuka yang mudah diperluas (untuk menampilkan teknik yang dibuat oleh pengembang untuk kebutuhan spesifiknya)
- Analisis, basis (prinsip-prinsip yang disebutkan di atas) dan skema pengeditan harus disembunyikan untuk memberikan kesempatan kepada pengembang untuk memperluas rangkaian teknik tanpa harus masuk ke dalam keberanian editornya. Artinya, DSL untuk menggambarkan teknik refactoring.
- Karena ekstensibilitas akan diikuti oleh peningkatan tajam dalam jumlah resepsi, untuk tampilan perlu memperhitungkan cakupan konteks untuk ditampilkan dalam menu pilihan hanya operasi yang berlaku dalam situasi tertentu.
Analisis pohon data runtime.
Aspek ini adalah tentang menggabungkan debugging dan pengeditan teks. Bahkan, untuk sebagian besar bahasa, untuk memeriksa bagaimana perubahan memengaruhi program, diperlukan restart program secara eksplisit. Jauh lebih mudah dan lebih visual (dan, sebagai akibatnya, dengan kemungkinan kesalahan yang lebih sedikit), akan mungkin untuk melihat dalam satu ruang bagaimana seluruh array data di bagian kode yang di-debug berubah ketika kode diedit .
Pengembangan alat semacam itu untuk bahasa yang berbeda sangat berbeda dalam kompleksitas, dan ini bukan hanya masalah sintaksis, tipe sistem dan fitur kinerja, tetapi pada esensi dari masing-masing bahasa. Untuk bahasa Data Driven, membangun ini jauh lebih mudah. Contoh: konstruktor ekspresi reguler, di mana dalam prosesnya Anda dapat segera melihat bagian teks mana yang dicakup teks biasa.
Menurut saya, hal yang paling penting dalam daftar yang tidak lengkap ini.
Kami membagi semua informasi yang dibutuhkan pengembang, secara langsung, pemrograman ke dalam dua kelompok besar
- Dokumentasi
- Resepsi \ heuristik pengembangan.
Pertama, untuk menyederhanakan pekerjaan programmer, akses ke dokumentasi harus langsung dari jendela editor.
Berbagai IDE dan editor menyelesaikan masalah ini dengan baik: IDE khusus bahasa dari Microsoft, Emacs dengan Info-mode-nya, Frescobaldi, Sunny Builder; baik untuk diintegrasikan ke dalam sumber, dan untuk eksternal. Namun, banyak perpustakaan dan kerangka kerja sekarang mengunggah dokumentasinya hanya pada jaringan dan / atau menggunakan format yang berbeda untuk menyimpannya, yang mempersulit kemungkinan integrasi ke dalam satu antarmuka.
Kelompok kedua jauh lebih menarik.
Ini mencakup pengetahuan, baik pemrograman dan pengembangan secara keseluruhan, dan metode khusus untuk bahasa / tumpukan tertentu. Saat ini, ceruk ini hampir sepenuhnya ditangkap oleh Stack Overflow, dan bahkan ada integrasi ke dalam IDE, tetapi kualitas keahlian di sana sering rendah . Demi kebaikan, akan jauh lebih efisien untuk memilih keputusan, kesalahan, trik dan menguranginya ke basis tertentu yang dapat dihubungi pengguna ketika dia perlu menyelesaikan masalahnya sendiri.
Selain itu, penganalisa modern memungkinkan Anda untuk memperingatkan tentang kesalahan yang mungkin, belum dilakukan ,. Faktanya, kami memiliki, dari sudut pandang teknis, semua yang kami butuhkan untuk membuat sistem pakar bagi pengembang yang menawarkan solusi saat kami menulis / mengedit kode. Yang hilang hanyalah basis keputusan / metode / kesalahan itu sendiri.
Kesimpulan
Jadi, ringkasannya:
- Pengembangan browser refactor harus didasarkan pada operasi pada pohon data dan direduksi menjadi deskripsi skrip seperti DSL untuk mengedit kode otomatis.
- Analisis Runtime harus menampilkan tampilan instan perubahan data selama mengedit dan menulis program. Artinya, pendekatan JAI dapat diterapkan ke bahasa pemrograman lain.
- Hapus browser web dari case pengguna sebagai cara untuk mencari dan membaca dokumentasi.
- Kita perlu mengembangkan plug-in (karena fakta bahwa lingkungannya beragam) sistem pakar yang akan membantu pengembang membuat keputusan dalam proses.