Tanya jawab anggota tim pindah dari VBA ke C #

Latar Belakang

Tahun lalu, saya diminta untuk membuat alat yang akan digunakan untuk perencanaan bisnis untuk sekitar 10 pengguna. Ini dilakukan atas nama tim TI lain yang "mensub-kontrakkan" pekerjaan itu kepada saya, dan karena tenggat waktu proyek sedikit tidak terencana di pihak mereka, saya harus mengimplementasikannya dengan sedikit terburu-buru.

Pada saat itu, kami memutuskan bahwa cara tercepat adalah membuat workbook Excel dengan VBA dan kemudian meminta pengguna mengunduh workbook yang ditingkatkan VBA ini dari Intranet untuk digunakan di PC mereka. Excel merupakan kendala dalam hal ini karena sistem perencanaan (yaitu basis data) yang kami gunakan hanya dapat berinteraksi melalui add-in Excel yang harus dimuat pada saat yang sama buku kerja perencanaan terbuka. Namun, VBA bukanlah kendala saat itu.

Buku kerja yang saya buat sekitar 4.000 baris kode VBA dan sementara saya mencoba memisahkan data dan lapisan presentasi, saya tidak bisa dalam semua kasus karena tenggat waktu proyek. Sejujurnya, sementara saya bangga membuat buku kerja ini, saya pada saat yang sama sedikit kecewa karena itu bisa dilakukan dengan lebih baik, baik dalam hal pengkodean dan juga penyebaran kepada pengguna.

Hari ini

Kembali ke hari ini dan tim IT sekali lagi datang kepada saya untuk meminta buku kerja yang serupa (jadi saya bisa menggunakan kembali bagian-bagian dari buku kerja lain di atas), tetapi kali ini jauh lebih rumit dan akan digunakan oleh lebih banyak pengguna ( sekitar 200).

Namun, kali ini, ini sedikit lebih terencana dan saya dapat melihat bahwa kita memiliki sedikit lebih banyak waktu untuk merencanakan sesuatu. Berdasarkan hal ini, saya memikirkan solusi dan infrastruktur karena pemrograman untuk 100 pengguna memiliki dampak yang lebih besar daripada untuk 10 pengguna. Oleh karena itu, saya menyarankan kepada tim bahwa mungkin kita harus mempertimbangkan memigrasikan kode yang ada ke solusi C # sehingga kita dapat mengelola kode dengan cara yang lebih disempurnakan. Saya masih mempertimbangkan itu sebagai add-in yang ditulis menggunakan VSTO / Excel-DNA yang kemudian dapat digunakan untuk pengguna.

Saya membahas hal ini dengan tim TI dua minggu lalu dan semuanya tampak baik-baik saja, sampai kemarin saya menerima email dari salah satu tim (yang tidak tahu VBA atau C #) yang mempertanyakan mengapa kita harus memulai proyek baru ini dalam C # dibandingkan menggunakan pendekatan yang sama seperti sebelumnya. Beberapa kekhawatiran mereka adalah:

• Ini adalah proyek yang cukup penting sehingga harus bekerja - solusi C # tidak akan stabil atau berfungsi sebaik solusi berbasis VBA yang ada.
• Kita harus membuang apa yang telah kita [saya] lakukan dalam solusi VBA dan membuatnya kembali dari awal di C #.
• Seseorang harus mendukung dua solusi terpisah, satu di VBA dan satu di C #. [sebenarnya, mereka saat ini tidak memiliki siapa pun untuk dukungan, saya biasanya ikut].

Sekarang, saya bisa memahami beberapa kekhawatiran mereka sampai taraf tertentu, tetapi saya perlu mengambil keputusan tentang langkah selanjutnya dan apa yang harus kembali kepada mereka. Secara pribadi, saya ingin menerapkan dalam C # karena saya merasa akan lebih baik untuk membangun solusi "Perusahaan" seperti ini. Selain itu, saya ingin mengambil kesempatan ini memoles keterampilan C # saya karena saya saat ini tidak kompeten dalam C # karena saya VBA dan saya ingin proyek seperti ini untuk membawa saya ke "level selanjutnya".

Saya menyiapkan daftar poin yang dapat saya gunakan untuk mencoba dan meyakinkan mereka bahwa solusi C # akan lebih baik untuk proyek ini, inilah yang saya miliki sejauh ini:

• Pengujian unit.
• Kontrol sumber.
• Dokumentasi kode - untuk transfer pengetahuan kepada orang-orang pendukung lainnya.
• Konvensi kode yang lebih baik - dapat menggunakan hal-hal seperti ReSharper untuk menegakkan penamaan dan struktur yang lebih baik.
• IDE yang lebih baik - lebih sedikit kesalahan karena penyorotan kesalahan.
• Lebih banyak modularitas melalui rakitan - dapat mempromosikan penggunaan kembali di alat masa depan.
• Penempatan terkelola - dapat mengontrol oleh siapa alat ini digunakan.

Pertanyaan: Apa poin lain yang bisa saya tambahkan untuk meyakinkan mereka? Atau apakah saya mencoba untuk menggigit lebih dari yang saya bisa mengunyah dengan proyek ini? Haruskah saya tetap diam dan melakukannya di VBA?

Saya sadar bahwa hanya pindah ke bahasa baru karena "lebih baru" atau dianggap "lebih dingin" seharusnya tidak menjadi dasar untuk keputusan dan karena itu saya menolak untuk memasukkannya sebagai titik keputusan - ini adalah tentang fakta.

Juga, saya tidak meminta perbandingan literal antara C # dan VBA sebagai bahasa, karena ada banyak perbandingan pada SO.

Tiga poin yang Anda daftarkan tampak adil:

Ini adalah proyek yang cukup penting sehingga harus bekerja - solusi C # tidak akan stabil atau berfungsi sebaik solusi berbasis VBA yang ada.

Memang, nanti, Anda mengatakan: "Saya ingin mengambil kesempatan ini memoles keterampilan C # saya karena saya saat ini tidak kompeten dalam C # seperti saya VBA " (penekanan milikku).

Dengan kata lain, Anda memiliki solusi yang berfungsi dan melalui pengujian pengguna intensif. Anda ingin membuang semua ini dan menulis ulang semuanya dalam bahasa yang tidak Anda ketahui dengan baik. Lihat masalahnya?

Kita harus membuang apa yang telah kita [saya] lakukan dalam solusi VBA dan membuatnya kembali dari awal di C #.

Hal-hal yang Seharusnya Tidak Pernah Anda pikirkan. Anda melempar kode, serta pengujian pengguna. Bukan hal yang baik.

Seseorang harus mendukung dua solusi terpisah, satu di VBA dan satu di C #. [sebenarnya, mereka saat ini tidak memiliki siapa pun untuk dukungan, saya biasanya ikut].

Jika versi VBA masih akan digunakan, penulisan ulang memang lebih bermasalah. Mengapa Anda memiliki dua sistem berbeda yang memerlukan perhatian Anda, padahal Anda mungkin hanya memiliki satu yang sudah berfungsi dan yang dapat Anda refactor dan menambahkan fitur?

Beberapa poin Anda, di sisi lain, dapat dikritik:

• Pengujian unit.

  Anda dapat menguji unit proyek Anda saat ini juga. Jika tidak ada kerangka kerja yang nyaman untuk itu, buatlah.

• Kontrol sumber.

  Kontrol sumber berkaitan dengan teks. Kode Anda saat ini adalah teks, oleh karena itu Anda dapat menggunakan kontrol sumber untuk itu.

  Bahasa, sistem operasi, kerangka kerja atau ekosistem sama sekali tidak relevan. Anda bisa (dan harus) menggunakan kontrol sumber untuk kode apa pun yang Anda tulis: kode dalam Visual Studio, atau sepotong kode yang Anda konsep dalam beberapa menit di LINQPad, atau skrip PowerShell yang mengotomatisasi tugas, atau skema database , atau makro Excel.

• Dokumentasi kode - untuk transfer pengetahuan kepada orang-orang pendukung lainnya.

  Sepakat.

• Konvensi kode yang lebih baik - dapat menggunakan hal-hal seperti ReSharper untuk menegakkan penamaan dan struktur yang lebih baik.

  Tentukan "lebih baik". Apakah ada konvensi pengkodean untuk makro Excel? Jika ya, gunakan: mereka tidak lebih baik atau lebih buruk daripada yang lain. Jika tidak, buat dan publikasikan sehingga orang lain dapat menggunakannya juga. Jawaban atas pertanyaan yang diposting pada 2010 tampak agak mengecewakan, tetapi mungkin ada alat baru yang tersedia sejak saat itu.

  Perhatikan bahwa bagian penting dari konvensi pengkodean adalah bahwa konvensi tersebut harus ditegakkan dengan komitmen.

• IDE yang lebih baik - lebih sedikit kesalahan karena penyorotan kesalahan.

  Sepakat. Fakta bahwa kami tidak dapat menulis makro di Visual Studio sangat disayangkan.

• Lebih banyak modularitas melalui rakitan - dapat mempromosikan penggunaan kembali di alat masa depan.

  Saya cukup yakin produk Anda saat ini dapat menggunakan beberapa tingkat modularitas juga.

• Penempatan terkelola - dapat mengontrol oleh siapa alat ini digunakan.

  Sepakat.

Alih-alih menulis ulang lengkap, Anda mungkin mencari cara untuk secara progresif memindahkan kode dari makro ke majelis biasa yang ditulis dalam VB.NET. Kenapa di VB.NET? Tiga alasan:

• Ada sedikit perbedaan antara VBA dan VB.NET karena ada antara VBA dan C #.

• Anda tahu VBA lebih baik, dan ini saja merupakan alasan yang baik untuk menggunakan VB.NET daripada C #. Jika Anda ingin "memoles keterampilan C # Anda", lakukan dengan proyek pribadi Anda, bukan hal-hal penting bisnis.

• Setiap penulisan ulang dari bahasa ke bahasa lain mengarah ke potensi bug. Anda tidak memerlukan itu untuk proyek ini.

Pindah ke .NET assembly dapat memberi Anda lingkungan yang nyaman dari Visual Studio, dengan pengujian unit yang mudah digunakan, TFS dan kesalahan yang menyoroti yang saat ini Anda gunakan dalam proyek lain.

Pada saat yang sama, jika Anda memindahkan kode Anda langkah demi langkah, Anda tidak mengambil risiko penulisan ulang yang lengkap (yaitu menghabiskan empat bulan membuat sesuatu yang tidak ingin digunakan oleh siapa pun karena banyaknya bug baru). Misalnya, Anda perlu mengerjakan fitur tertentu? Pikirkan bagaimana Anda dapat memindahkan fitur khusus ini ke .NET terlebih dahulu.

Ini sangat mirip dengan refactoring. Alih-alih menulis ulang semuanya karena Anda mempelajari beberapa pola desain baru dan fitur bahasa, Anda cukup melakukan perubahan kecil pada kode tempat Anda bekerja saat ini.

Saya akan mendukung pergi ke C #. Orang lain telah membahas poin Anda dengan sangat baik, jadi saya tidak akan mengulangi apa yang mereka katakan. Pasti ada banyak alasan bagus untuk tetap menggunakan VBA.

Namun , salah satu atasan saya melakukan pekerjaan yang sempurna dalam menciptakan dokumentasi yang bermakna. Begitu banyak sehingga keputusan desain sebenarnya ditulis dengan pembenaran - jika saja semua proyek perangkat lunak memilikinya! Maksud saya? Salah satu keputusan desain adalah "Kami memilih untuk menulis program ini di Jawa, karena Tn. Si-dan-begitu ingin memasukkan x tahun pengalaman Java dalam resumenya". Jika itu alasan kuat bagi Anda untuk pindah ke C #, maka itu tidak dapat diabaikan sebagai hal sepele. Itu tidak bisa menjadi salah satu alasan yang Anda gunakan untuk membenarkannya kepada tim TI, karena mereka tidak benar-benar peduli dengan apa yang Anda inginkan dalam resume Anda, mereka peduli dengan produk yang berfungsi.

Ada juga persepsi VBA untuk dipikirkan. Saya tahu itu tidak benar, tetapi saya tahu beberapa orang yang melihat 'VBA' di resume dan berpikir, "Apa, orang ini terjebak melakukan pekerjaan magang? Mengapa dia tidak memiliki pengalaman dengan bahasa nyata ?" Mereka melihat 'VBA' dan berpikir 'unggul pengembang makro'. Seperti menyalin / menempelkan satu sel ke sel lain, melakukan perhitungan sederhana, dll. Biasanya jenis orang yang dapat menghargai perkembangan nyata dalam VBA adalah mereka yang telah melakukannya, dan itu tampak seperti kumpulan yang semakin kecil, setidaknya dalam pengalaman saya. Anda mungkin memiliki perasaan yang lebih baik tentang persepsi VBA di daerah Anda, tetapi saya telah melihat banyak hal negatif yang tidak dapat dibenarkan terhadapnya.

Hal lain yang ingin saya masukkan: MainMa menyebutkan kesamaan antara VBA dan C #. Ini benar-benar benar, dan jawaban JMK menawarkan beberapa teknologi untuk dibaca. Coba salin / tempel kode VBA Anda ke proyek C # dan lihat betapa mudahnya kesalahan sintaks terlihat untuk dikoreksi.

Anda bilang punya 4.000 baris kode, yang merupakan kumpulan kode yang bagus dan mungkin mencakup banyak fungsi ... tetapi hanya 4.000 baris kode. Coba salin dan tempel. Saya benar-benar tidak akan terkejut jika Anda bisa membersihkan kesalahan sintaks dan memiliki proyek yang berfungsi. Tanpa mengetahui detail kode Anda atau jumlah waktu luang yang tersedia untuk Anda, saya pikir Anda bisa merobohkannya di akhir pekan.

Mungkin tidak mengikuti praktik terbaik C #, mungkin tidak efisien, tetapi Anda akan berakhir dengan proyek yang secara fungsional setara dalam C #. Anda juga dapat relatif yakin bahwa kode C # baru Anda tidak lebih rentan terhadap cacat daripada kode VBA lama Anda.

Mengubah kode VBA Anda ke C # pada waktu Anda sendiri akan melakukan beberapa hal untuk Anda:

• Saat Anda meneliti kesalahan sintaksis, Anda akan menjadi lebih akrab dengan praktik C # - semacam primer untuk benar-benar bekerja di C #
• Ini akan menyoroti masalah yang jelas dengan memuat plug-in ke excel (karena excel mungkin masih merupakan persyaratan). Mungkin ada masalah yang belum Anda pertimbangkan yang mungkin menjadi penghalang jalan.
• Ini akan menunjukkan bukti konsep kepada pelanggan Anda (tim TI). Jika mereka dapat melihat Anda memiliki plug-in C # yang berfungsi dengan fungsi saat ini, maka Anda akan mengurangi tingkat risiko yang dirasakan dengan C #.

Dan kembali ke tiga poin IT:

• Ini adalah proyek yang cukup penting sehingga harus bekerja - solusi C # tidak akan stabil atau berfungsi sebaik solusi berbasis VBA yang ada.

Seperti disebutkan, kode C # Anda akan mencakup fungsi yang sama dan sama stabilnya dengan VBA Anda. Sebenarnya, ada adalah kesempatan Anda memperkenalkan bug / cacat atau inefisiensi, tapi itu tampaknya tidak mungkin. Kita tidak berbicara tentang port dari iOS / Objective C ke Android / Java, kita berbicara tentang port antara dua bahasa yang memiliki banyak kesamaan dalam sintaks dan dapat memanfaatkan teknologi yang sama persis - buku kerja excel.

• Kita harus membuang apa yang telah kita [saya] lakukan dalam solusi VBA dan membuatnya kembali dari awal di C #.

Dengan ini, Anda tidak membuang upaya atau kode apa pun.

• Seseorang harus mendukung dua solusi terpisah, satu di VBA dan satu di C #. [sebenarnya, mereka saat ini tidak memiliki siapa pun untuk dukungan, saya biasanya ikut].

Anda hanya akan memiliki 1 solusi, semuanya dalam C #.

Secara keseluruhan, pelanggan Anda melihat banyak risiko. Jika Anda dapat mengambil langkah-langkah untuk mengurangi risiko itu, mereka mungkin merangkul perubahan ke C #.

Aku benci mengatakannya, tapi argumenmu tidak tahan air.

Pengujian unit.

Ini telah menjadi masalah yang dipecahkan untuk waktu yang sangat lama. Ada banyak kerangka kerja Unit Testing di luar sana. Pilih salah satu. Anda seharusnya sudah melakukan ini. Saya merekomendasikan kami , karena terintegrasi ke dalam IDE dan menyediakan fitur hebat lainnya.

Kontrol sumber

Yang ini sedikit lebih sulit, ada beberapa solusi yang siap pakai, tapi itu benar-benar hanya masalah memasukkan dan mengeluarkan kode Anda dari repositori. Berikut cara alis rendah untuk melakukannya , tetapi ada opsi lain yang lebih baik juga.

Dokumentasi kode

Juga masalah yang terpecahkan. MZ-Tool memiliki fitur dokumentasi XML yang bekerja sangat mirip dengan dokumen komentar XML .Net.

Konvensi pengkodean yang lebih baik

Sama seperti Visual Studio memiliki plugin ReSharper, MZ-Tools dan Rubberduck memiliki fitur seperti itu.

IDE yang lebih baik

Sekali lagi, ada plug-in yang tersedia untuk VBA IDE.

Lebih banyak modularitas melalui rakitan - dapat mempromosikan penggunaan kembali di alat masa depan.

Juga masalah yang terpecahkan. Tidak, Anda tidak dapat membuat rakitan, tetapi Anda dapat merujuk Proyek VBA lainnya.

Penempatan terkelola - dapat mengontrol oleh siapa alat ini digunakan.

Sedikit stiker, Anda harus menulis kode untuk mengontrol siapa yang dapat mengakses program dan siapa yang tidak bisa, tetapi Anda (sekali lagi) mungkin sudah memiliki kode keamanan tertulis.

Adapun penyebaran, itu juga masalah yang dipecahkan. Ya, ini membutuhkan kode, tetapi ada contoh di luar sana yang dapat Anda gunakan / modifikasi .

Di atas semua ini, adalah kenyataan bahwa Anda akan mulai dari awal. Saya juga akan merekomendasikan artikel Joel Spolsky .

Mereka melakukannya dengan membuat kesalahan strategis tunggal terburuk yang dapat dilakukan oleh perusahaan perangkat lunak:

Mereka memutuskan untuk menulis ulang kode dari awal.

Kawan-kawan TI Anda benar. Anda seharusnya tidak menulis ulang ini dari awal. Anda harus memecahkan masalah dengan solusi Anda saat ini.

Sekarang, dengan semua yang dikatakan, saya benar-benar dapat memahami mengapa Anda ingin melakukan ini di C # atau VB.Net. Mereka benar-benar solusi yang lebih baik, jika Anda memulai proyek baru , tetapi dari suaranya, itu bukan proyek baru. Adalah jauh lebih baik untuk meningkatkan apa yang Anda miliki kemudian memecahkannya dengan memulai dari awal.

Anda dapat menunjukkan bahwa bahkan Microsoft menyatakan dalam artikel ini :

Memperbarui kode untuk meningkatkan fitur atau untuk memperbaiki bug akan mengharuskan artefak Office dikirim ulang melalui email, disusun ulang, dan dikerjakan ulang oleh setiap pengguna tunggal dan di setiap file tunggal yang telah menggunakan penyesuaian.

Artikel ini adalah tentang berbagai pendekatan pengembangan barang berdasarkan Office, mungkin Anda juga dapat mengambil beberapa pro dan kontra dari itu dalam diskusi Anda.

Ini benar-benar tergantung pada bagaimana Anda berniat untuk pindah ke C # (yaitu teknologi apa yang akan Anda gunakan).

Jika Anda akan menggunakan OpenXML, maka Anda berbicara total menulis ulang yang, jika Anda memiliki solusi yang berfungsi, tidak disarankan.

Jika Anda berbicara tentang menggunakan Interop, Anda mungkin menemukan bahwa prosesnya ternyata sangat lancar. Saya telah memindahkan banyak kode dari VBA ke C # (dengan Interop) di masa lalu dan begitu Anda terhubung ke buku kerja, seperti:

var excelApplication = new Application();
var workbook = excelApplication.Workbooks.Open(@"C:\location.xlsx");

Dalam banyak kasus Anda dapat menyalin / menempelkan kode VBA Anda, awalan panggilan fungsi dengan workbook., mengganti Dim dengan var dll yang sesuai dan menambahkan tanda titik koma pada akhirnya.

Ini pada dasarnya Kerangka yang sama di bawahnya (Excel), Anda hanya mengubah Sintaks dari VBA ke C #.

Setelah selesai, pastikan untuk menyimpan dan menutup aplikasi:

workbook.Save();
excelApplication.Quit();

Kemudian lepaskan aplikasi dengan Marshal:

Marshal.ReleaseComObject(excelApplication);

Saya mungkin akan menulis kelas pembungkus mengimplementasikan IDisposable di sekitar objek Aplikasi Excel, kemudian pastikan untuk menggunakan usingketika objek ini digunakan.

Cara yang baik untuk menyelesaikan kasus Anda adalah dengan menghabiskan satu jam atau lebih melakukan ini, yang dalam waktu singkat akan menunjukkan seberapa cepat Anda bisa memasukkan kode, dan meyakinkan kolega Anda bahwa ini adalah ide yang bagus.

Kode sebagian besar akan tetap tidak berubah dengan cara, tetapi Anda memiliki semua manfaat yang Anda sebutkan memiliki proyek C # dalam Visual Studio.

Saya berada di posisi yang sama, memiliki aplikasi (20k + baris kode VBA) yang sangat besar yang dibangun ke dalam workbook EXCEL. Setelah pengujian dengan Office 2013 itu hanya gagal berfungsi, diyakini karena perubahan dalam urutan acara start-up dalam model kantor baru, dan mungkin penegakan EMET yang lebih ketat. Dengan demikian saya berada dalam posisi untuk melakukan crash-conversion ke C # dan VB.NET sebelum peluncuran Office 2013 tahun ini. Buku kerja lain yang lebih sederhana (ditingkatkan VBA) yang digunakan di sekitar organisasi belum kebal, beberapa bekerja dan yang lainnya tidak.

Kesalahan terjadi di acara Workbook_Open , di mana lembar-lembar buku kerja tidak lagi tersedia, dan dalam kode EXCEL internal sebelum kode VBA yang direferensikan.

Menjadi nyaman di semua VBA, C # dan VB.NET saya menulis konversi di kedua yang terakhir. Kode framework sedang ditulis dalam C # karena idiom bahasa memungkinkan saya untuk menulis konstruksi fungsional tertentu dalam bahasa itu 3-4 kali lebih cepat daripada di VB.NET. Sebagian besar kode ada di VB.NET karena dengan demikian penulisan ulang saya kurang luas, dan ada idiom tertentu di sana yang tidak hadir dalam C #.

Sebelum membuat keputusan, saya sangat menyarankan agar Anda menguji aplikasi yang sudah ada dengan OFFICE 2013 dan tingkat penegakan penuh EMET yang diramalkan organisasi akan diluncurkan selama 2-3 tahun ke depan. Anda mungkin, seperti saya, mengetahui bahwa aplikasi yang ada tidak akan berjalan di lingkungan itu tanpa menulis ulang - dalam hal ini penulisan ulang mungkin juga di DOT NET dan VSTO.

Tambahan:

Menulis sedikit utilitas ekstrak otomatis, yang memotong seluruh isi buku kerja VBA dan mengekspor semua modul, kelas, dan formulir ke file, adalah 1-2 hari kerja, tergantung pada seberapa suka Anda inginkan. Begitu juga dengan sebaliknya untuk mengimpor file dari direktori ke buku kerja kosong. Dengan kedua hal ini sangat mungkin untuk memiliki semua kode VBA Anda dalam kontrol sumber yang tepat, dan untuk memiliki proses Build dari kode sumber untuk buku kerja Anda.

ATAU - gunakan utilitas gratis seperti Excel VBA Code Cleaner

Saya ingin mengambil kesempatan ini memoles keterampilan C # saya karena saya saat ini tidak kompeten dalam C # karena saya VBA dan saya ingin proyek seperti ini untuk membawa saya ke "level selanjutnya".

Jujur. Apakah Anda berencana berbagi informasi ini dengan orang lain yang terlibat dalam pengambilan keputusan ini? Jika tidak, saya akan menyalahkan Anda jika proyek gagal. Karena proyek serupa telah dibuat dan diletakkan di lapangan, semua orang telah membentuk apa yang mereka harapkan terjadi dalam pikiran mereka sendiri. Mereka tahu berapa lama untuk membangun yang terakhir dan akan percaya Anda dapat membuatnya dalam waktu yang lebih singkat (yang mungkin atau mungkin tidak benar berdasarkan persyaratan tambahan). Apakah Anda siap untuk mengambil tanggung jawab ini bersama dengan belajar bahasa baru?

Saya merekomendasikan porting aplikasi lama ke C # ASAP. Mungkin Anda bisa belajar cukup banyak dalam prosesnya sebelum mengambil keputusan. Setidaknya Anda akan mencapai tujuan Anda meningkatkan keterampilan Anda dengan bahasa baru dan tetap menyelesaikan proyek tepat waktu.

Kemudian lagi, jika Anda merasa kuat tentang hal itu dan membangun proyek semuanya bertumpu pada bahu Anda, lakukan seperti yang Anda inginkan. Selalu lebih mudah mendapatkan pengampunan daripada izin.