สมาชิกในทีมที่สงสัยจะย้ายจาก VBA ไปยัง C #

พื้นหลัง

เมื่อปีที่แล้วฉันถูกขอให้สร้างเครื่องมือที่จะใช้สำหรับการวางแผนธุรกิจสำหรับผู้ใช้ประมาณ 10 คน สิ่งนี้ทำในนามของทีมงานไอทีอีกคนที่ "ทำสัญญาย่อย" ทำงานให้ฉันและเนื่องจากกำหนดเวลาโครงการไม่ได้วางแผนมาก่อนที่ด้านข้างของพวกเขาฉันจึงต้องดำเนินการอย่างเร่งด่วน

ในเวลานั้นเราตัดสินใจว่าวิธีที่เร็วที่สุดคือการสร้างเวิร์กบุ๊ก Excel ด้วย VBA จากนั้นให้ผู้ใช้ดาวน์โหลดเวิร์กบุ๊กที่ปรับปรุงด้วย VBA นี้จากอินทราเน็ตเพื่อใช้บนพีซีของพวกเขา Excel เป็นข้อ จำกัด ในกรณีนี้เนื่องจากระบบการวางแผน (เช่นฐานข้อมูล) ที่เราใช้สามารถโต้ตอบผ่านทาง Add-in ของ Excel เท่านั้นซึ่งจะต้องโหลดในเวลาเดียวกันเมื่อสมุดงานการวางแผนเปิดอยู่ อย่างไรก็ตาม VBA ไม่ใช่ข้อ จำกัด ในเวลานั้น

สมุดงานที่ฉันสร้างขึ้นประมาณ 4,000 บรรทัดของรหัส VBA และในขณะที่ฉันพยายามแยกข้อมูลและเลเยอร์การนำเสนอฉันไม่สามารถทำได้ในทุกกรณีเนื่องจากกำหนดเวลาโครงการ จริงๆแล้วในขณะที่ฉันภูมิใจในการสร้างเวิร์กบุคนี้ฉันก็รู้สึกผิดหวังเล็กน้อยที่มันสามารถทำได้ดีกว่าทั้งในแง่ของการเข้ารหัสและการปรับใช้กับผู้ใช้

ในวันนี้

ย้อนกลับไปวันนี้และทีมไอทีได้มาหาฉันอีกครั้งเพื่อขอสมุดงานที่คล้ายกัน (ดังนั้นฉันจึงสามารถใช้ซ้ำบางส่วนของสมุดงานอื่นด้านบนได้) แต่คราวนี้มันซับซ้อนมากขึ้นและจะมีผู้ใช้จำนวนมากขึ้น ( ประมาณ 200)

อย่างไรก็ตามในครั้งนี้มันเป็นการวางแผนที่ดีขึ้นเล็กน้อยและฉันเห็นว่าเรามีเวลาอีกเล็กน้อยในการวางแผนสิ่งต่าง ๆ จากนี้ฉันคิดเกี่ยวกับโซลูชันและโครงสร้างพื้นฐานเนื่องจากการเขียนโปรแกรมสำหรับผู้ใช้ 100 คนมีผลกระทบมากกว่าผู้ใช้ 10 คน ดังนั้นฉันแนะนำทีมว่าบางทีเราควรพิจารณาย้ายรหัสที่มีอยู่ไปยังโซลูชัน C # เพื่อให้เราสามารถจัดการรหัสได้อย่างละเอียดยิ่งขึ้น ฉันยังคงคิดว่ามันเป็นส่วนเสริมที่เขียนโดยใช้ VSTO / Excel-DNA ซึ่งสามารถนำไปใช้กับผู้ใช้ได้

ฉันคุยเรื่องนี้กับทีมไอทีเมื่อสองสัปดาห์ก่อนและทุกอย่างดูเหมือนจะดีจนกระทั่งเมื่อวานฉันได้รับจดหมายจากทีมหนึ่ง (ผู้ที่ไม่รู้ VBA หรือ C #) ถามว่าทำไมเราควรเริ่มโครงการใหม่นี้ใน C # กับการใช้ วิธีการเช่นเดียวกับก่อน ความกังวลของพวกเขาคือ:

• มันเป็นโครงการที่สำคัญพอสมควรดังนั้นจึงต้องทำงาน - โซลูชัน C # จะไม่เสถียรหรือทำงานได้ดีเท่ากับ VBA ที่มีอยู่เดิม
• เราจะต้องทิ้งสิ่งที่เรา [I] ทำไว้ในโซลูชัน VBA และสร้างใหม่จากศูนย์ใน C #
• บางคนจะต้องสนับสนุนโซลูชันที่แยกกันสองรายการโซลูชันหนึ่งใน VBA และอีกโซลูชันหนึ่งใน C # [ที่จริงแล้วพวกเขาไม่มีใครให้การสนับสนุนฉันมักจะก้าวเข้ามา]

ตอนนี้ฉันสามารถเข้าใจความกังวลของพวกเขาในระดับหนึ่ง แต่ฉันต้องตัดสินใจในขั้นตอนต่อไปและจะกลับไปหาพวกเขาด้วย โดยส่วนตัวฉันต้องการนำไปใช้ใน C # เพราะฉันรู้สึกว่ามันจะให้ยืมตัวเองได้ดีขึ้นในการสร้างโซลูชัน "Enterprise" เช่นนี้ นอกจากนี้ฉันต้องการที่จะใช้โอกาสนี้ทำความเข้าใจกับทักษะ C # ของฉันเนื่องจากฉันยังไม่มีความสามารถใน C # เหมือนกับ VBA และฉันต้องการโครงการเช่นนี้เพื่อนำฉันไปสู่ ​​"ระดับต่อไป"

ฉันเตรียมรายการของจุดที่ฉันสามารถใช้เพื่อลองและโน้มน้าวใจพวกเขาว่าโซลูชัน C # น่าจะดีกว่าสำหรับโครงการนี้นี่คือสิ่งที่ฉันมีจนถึงตอนนี้:

• การทดสอบหน่วย
• การควบคุมแหล่งที่มา
• รหัสเอกสาร - สำหรับการถ่ายโอนความรู้ไปยังผู้สนับสนุนอื่น ๆ
• ระเบียบการเข้ารหัสที่ดีขึ้น - สามารถใช้สิ่งต่าง ๆ เช่น ReSharper เพื่อบังคับใช้การตั้งชื่อและโครงสร้างที่ดีขึ้น
• Better IDE - ข้อผิดพลาดน้อยลงเนื่องจากการเน้นข้อผิดพลาด
• ความเป็นโมดูลที่มากขึ้นผ่านชุดประกอบ - สามารถส่งเสริมการใช้ซ้ำในเครื่องมือในอนาคต
• การปรับใช้ที่มีการจัดการ - สามารถควบคุมได้ว่าใครเป็นผู้ใช้เครื่องมือนี้

คำถาม: ฉันสามารถเพิ่มประเด็นอื่น ๆ เพื่อโน้มน้าวพวกเขาได้อย่างไร หรือฉันพยายามกัดมากกว่าที่ฉันสามารถเคี้ยวกับโปรเจ็กต์นี้ได้? ฉันควรจะเงียบ ๆ และทำใน VBA อยู่ดี

ฉันทราบดีว่าการย้ายไปใช้ภาษาใหม่เพราะ "ใหม่กว่า" หรือเห็นว่า "เย็นกว่า" ไม่ควรเป็นพื้นฐานสำหรับการตัดสินใจและดังนั้นฉันจึงไม่เห็นด้วยที่จะรวมไว้เป็นจุดตัดสินใจ - นี่เป็นเรื่องจริง

นอกจากนี้ฉันไม่ขอเปรียบเทียบตัวอักษรระหว่าง C # และ VBA เป็นภาษาเนื่องจากมีการเปรียบเทียบมากมายใน SO

จุดสามจุดที่คุณระบุไว้นั้นยุติธรรม:

มันเป็นโครงการที่สำคัญพอสมควรดังนั้นจึงต้องทำงาน - โซลูชัน C # จะไม่เสถียรหรือทำงานได้ดีเท่ากับ VBA ที่มีอยู่เดิม

แน่นอนในภายหลังคุณบอกว่า: "ฉันต้องการที่จะใช้โอกาสนี้แปรงขึ้นทักษะ C # ของฉันในขณะที่ฉันไม่ได้มีความสามารถใน C # ขณะที่ฉัน VBA " (เน้นฉัน)

คุณมีโซลูชันที่ใช้งานได้และผ่านการทดสอบผู้ใช้อย่างเข้มข้น คุณต้องการที่จะโยนสิ่งนี้และเขียนทุกอย่างใหม่ในภาษาที่คุณไม่ค่อยรู้จัก เห็นปัญหาไหม

เราจะต้องทิ้งสิ่งที่เรา [I] ทำไว้ในโซลูชัน VBA และสร้างใหม่จากศูนย์ใน C #

สิ่งที่คุณไม่ควรทำอยู่ในใจ คุณกำลังโยนรหัสเช่นเดียวกับการทดสอบของผู้ใช้ ไม่ใช่สิ่งที่ดี

บางคนจะต้องสนับสนุนโซลูชันที่แยกกันสองรายการโซลูชันหนึ่งใน VBA และอีกโซลูชันหนึ่งใน C # [ที่จริงแล้วพวกเขาไม่มีใครให้การสนับสนุนฉันมักจะก้าวเข้ามา]

หากยังคงใช้เวอร์ชัน VBA อยู่การเขียนซ้ำจะเป็นปัญหามากกว่า ทำไมคุณถึงมีระบบที่แตกต่างกันสองระบบที่คุณต้องให้ความสนใจเมื่อคุณมีเพียงระบบเดียวที่ใช้งานได้แล้วและคุณสามารถสร้างระบบใหม่และเพิ่มคุณสมบัติให้

ในทางกลับกันบางประเด็นคุณสามารถถูกวิพากษ์วิจารณ์ได้:

• การทดสอบหน่วย

  คุณสามารถทดสอบโครงการปัจจุบันของคุณได้เช่นกัน หากไม่มีกรอบการทำงานที่สะดวกให้สร้างขึ้นมา

• การควบคุมแหล่งที่มา

  ข้อตกลงการควบคุมแหล่งที่มาพร้อมกับข้อความ รหัสปัจจุบันของคุณคือข้อความดังนั้นคุณสามารถใช้การควบคุมแหล่งที่มาได้

  ภาษาระบบปฏิบัติการกรอบงานหรือระบบนิเวศไม่เกี่ยวข้องอย่างสมบูรณ์ คุณสามารถ (และควร) การควบคุมการใช้แหล่งสำหรับรหัสใด ๆ ที่คุณเขียน: รหัสใน Visual Studio หรือชิ้นส่วนของรหัสคุณร่างในไม่กี่นาทีใน LinqPad หรือสคริปต์ PowerShell ซึ่งโดยอัตโนมัติงานหรือคีมาฐานข้อมูลหรือแมโคร Excel

• รหัสเอกสาร - สำหรับการถ่ายโอนความรู้ไปยังผู้สนับสนุนอื่น ๆ

  ตกลง

• ระเบียบการเข้ารหัสที่ดีขึ้น - สามารถใช้สิ่งต่าง ๆ เช่น ReSharper เพื่อบังคับใช้การตั้งชื่อและโครงสร้างที่ดีขึ้น

  กำหนด "ดีกว่า" มีอนุสัญญาการเข้ารหัสสำหรับมาโครของ Excel หรือไม่ ถ้าใช่ใช้มัน: มันดีกว่าหรือแย่กว่าอื่น ๆ ถ้าไม่ใช่ให้สร้างและเผยแพร่เพื่อให้คนอื่นสามารถใช้งานได้เช่นกัน คำตอบของคำถามที่โพสต์ในปี 2010 นั้นค่อนข้างน่าผิดหวัง แต่อาจมีเครื่องมือใหม่ให้ใช้งานตั้งแต่นั้นมา

  โปรดทราบว่าส่วนสำคัญของข้อตกลงการเข้ารหัสคือควรบังคับใช้การส่งข้อมูล

• Better IDE - ข้อผิดพลาดน้อยลงเนื่องจากการเน้นข้อผิดพลาด

  ตกลง ความจริงที่ว่าเราไม่สามารถเขียนมาโครใน Visual Studioนั้นเป็นเรื่องที่โชคร้ายมาก

• ความเป็นโมดูลที่มากขึ้นผ่านชุดประกอบ - สามารถส่งเสริมการใช้ซ้ำในเครื่องมือในอนาคต

  ฉันค่อนข้างมั่นใจว่าผลิตภัณฑ์ในปัจจุบันของคุณสามารถใช้โมดูลในระดับหนึ่งได้เช่นกัน

• การปรับใช้ที่มีการจัดการ - สามารถควบคุมได้ว่าใครเป็นผู้ใช้เครื่องมือนี้

  ตกลง

แทนการเขียนเสร็จสมบูรณ์แล้วคุณอาจจะค้นหาวิธีการที่จะมีความก้าวหน้ารหัสย้ายจากแมโครเพื่อการชุมนุมสามัญเขียนใน VB.NET ทำไมใน VB.NET? สามเหตุผล:

• มีความแตกต่างน้อยกว่าระหว่าง VBA และ VB.NET เนื่องจากมีระหว่าง VBA และ C #

• คุณรู้ VBA ได้ดีขึ้นและสิ่งนี้เป็นเหตุผลที่ดีที่จะใช้ VB.NET แทน C # หากคุณต้องการ "ฝึกฝนทักษะ C #" ของคุณให้ทำกับโครงการส่วนตัวของคุณไม่ใช่เรื่องสำคัญทางธุรกิจ

• การเขียนจากภาษาหนึ่งไปอีกภาษาหนึ่งจะทำให้เกิดข้อบกพร่องที่อาจเกิดขึ้นได้ คุณไม่จำเป็นสำหรับโครงการนี้

การย้ายไปที่แอสเซมบลี. NET สามารถทำให้คุณมีสภาพแวดล้อมที่สะดวกสบายของ Visual Studio ด้วยการทดสอบหน่วยที่สะดวก TFS และข้อผิดพลาดที่เน้นคุณกำลังใช้ในโครงการอื่น ๆ

ในเวลาเดียวกันหากคุณย้ายโค้ดทีละขั้นตอนคุณจะไม่เสี่ยงกับการเขียนซ้ำทั้งหมด (เช่นการใช้เวลาสี่เดือนในการสร้างสิ่งที่ไม่มีใครต้องการใช้เพราะมีข้อบกพร่องใหม่จำนวนมาก) ตัวอย่างเช่นคุณต้องทำงานกับคุณสมบัติเฉพาะหรือไม่ คิดว่าคุณสามารถย้ายคุณสมบัตินี้ไปเป็น. NET ได้อย่างไรก่อน

สิ่งนี้ค่อนข้างคล้ายกับการปรับโครงสร้างใหม่ แทนที่จะเขียนใหม่ทั้งหมดเพราะคุณได้เรียนรู้รูปแบบการออกแบบและคุณสมบัติภาษาใหม่ ๆ คุณเพียงแค่ทำการเปลี่ยนแปลงเล็กน้อยในรหัสที่คุณใช้งานอยู่ในขณะนี้

ฉันจะสนับสนุนการไปที่ C # คนอื่น ๆ ได้คะแนนของคุณเป็นอย่างดีดังนั้นฉันจะไม่ปรับปรุงสิ่งที่พวกเขาพูด มีเหตุผลที่ดีมากมายในการใช้ VBA

อย่างไรก็ตามหนึ่งในนายจ้างของฉันทำงานที่ไร้ที่ติในการสร้างเอกสารที่มีความหมาย มากเสียจนการตัดสินใจออกแบบนั้นถูกบันทึกด้วยเหตุผล - ถ้ามีเพียงโครงการซอฟต์แวร์เท่านั้นที่มีสิ่งนั้น! จุดของฉัน? หนึ่งในการตัดสินใจด้านการออกแบบคือ "เรากำลังเลือกที่จะเขียนโปรแกรมนี้ใน Java เพราะคุณต้องการอย่างมากที่จะนำประสบการณ์จาวามาใช้ในการดำเนินการ x ปี" หากนั่นเป็นเหตุผลที่ดีสำหรับคุณที่จะย้ายไปที่ C # คุณจะไม่สามารถเพิกเฉยต่อเรื่องเล็กน้อยได้ มันไม่สามารถเป็นหนึ่งในเหตุผลที่คุณใช้พิสูจน์ความเหมาะสมให้กับทีมไอทีเพราะพวกเขาไม่สนใจสิ่งที่คุณต้องการในประวัติย่อของพวกเขาพวกเขาใส่ใจเกี่ยวกับผลิตภัณฑ์ที่ใช้งานได้

นอกจากนี้ยังมีการรับรู้ของ VBA ที่จะคิดเกี่ยวกับ ฉันรู้ว่ามันไม่เป็นความจริง แต่ฉันรู้ว่ามีคนไม่กี่คนที่เห็น 'VBA' ในประวัติย่อและคิดว่า "ชายคนนี้ทำงานติดกับการฝึกงานทำไมเขาไม่มีประสบการณ์กับภาษาจริง " พวกเขาเห็น 'VBA' และคิดว่า 'นักพัฒนาแมโครที่ยอดเยี่ยม' เช่นการคัดลอก / วางเซลล์หนึ่งไปยังอีกเซลล์หนึ่งทำการคำนวณอย่างง่าย ฯลฯ โดยทั่วไปแล้วคนที่สามารถชื่นชมการพัฒนาที่แท้จริงใน VBA คือคนที่ทำมันและดูเหมือนว่าจะเป็นสระน้ำขนาดเล็กที่เพิ่มขึ้นอย่างน้อยในประสบการณ์ของฉัน คุณอาจรู้สึกได้ถึงการรับรู้ VBA ที่ดีขึ้นในพื้นที่ของคุณ แต่ฉันได้เห็นการปฏิเสธในทางที่ไม่ยุติธรรมหลายประการ

สิ่งอื่น ๆ ที่ฉันต้องการเป็นศูนย์ใน: MainMa กล่าวถึงความคล้ายคลึงกันระหว่าง VBA และ C # นี่เป็นความจริงอย่างแน่นอนและคำตอบของ JMK นำเสนอเทคโนโลยีสองสามอย่างที่จะอ่าน ลองคัดลอก / วางโค้ด VBA ของคุณไปยังโปรเจ็กต์ C # และดูว่าข้อผิดพลาดทางไวยากรณ์นั้นดูง่ายแค่ไหนที่จะแก้ไข

คุณบอกว่าคุณมีโค้ด 4,000 บรรทัดซึ่งเป็นโค้ดที่ดีและอาจรวมถึงฟังก์ชั่นมากมาย ... แต่มันเป็นโค้ดเพียง 4,000 บรรทัด ลองทำสำเนาและวาง ฉันจะไม่แปลกใจจริงๆถ้าคุณสามารถล้างข้อผิดพลาดทางไวยากรณ์เหล่านั้นและมีโครงการทำงาน โดยไม่ทราบรายละเอียดของรหัสของคุณหรือจำนวนเวลาว่างที่มีให้คุณฉันคิดว่าคุณสามารถทำให้เรื่องนี้หมดไปในช่วงสุดสัปดาห์

อาจไม่เป็นไปตามแนวทางปฏิบัติที่ดีที่สุดของ C # อาจไม่มีประสิทธิภาพ แต่คุณจะต้องจบโครงการที่เทียบเท่ากับหน้าที่ใน C # คุณอาจมั่นใจได้ว่ารหัส C # ใหม่ของคุณนั้นไม่มีข้อบกพร่องได้ง่ายกว่ารหัส VBA เดิมของคุณ

การแปลงรหัส VBA ของคุณเป็น C # ในเวลาของคุณเองจะทำสองสิ่งให้คุณ:

• ในขณะที่คุณค้นคว้าข้อผิดพลาดทางไวยากรณ์คุณจะคุ้นเคยกับการปฏิบัติ C # มากขึ้น - ไพรเมอร์ชนิดหนึ่งสำหรับการทำงานใน C #
• มันจะส่องแสงในประเด็นที่ชัดเจนใด ๆ กับการโหลดปลั๊กอินลงใน excel (เนื่องจาก excel ยังคงเป็นข้อกำหนด) อาจมีปัญหาที่คุณยังไม่ได้พิจารณาซึ่งอาจเป็นสิ่งกีดขวางบนถนน
• มันจะแสดงหลักฐานพิสูจน์แนวคิดให้กับลูกค้าของคุณ (ทีมไอที) หากพวกเขาสามารถเห็นคุณมีปลั๊กอิน C # ที่ใช้งานได้กับฟังก์ชั่นปัจจุบันคุณจะลดระดับความเสี่ยงที่รับรู้ด้วย C #

และกลับไปที่สามจุดของไอที:

•เป็นโครงการที่สำคัญพอสมควรดังนั้นจึงต้องใช้งาน - โซลูชัน C # จะไม่เสถียรหรือทำงานได้ดีเท่ากับ VBA ที่มีอยู่เดิม

ดังที่ได้กล่าวมาแล้วโค้ด C # ของคุณจะครอบคลุมฟังก์ชั่นการใช้งานเดียวกันและมีความเสถียรเท่ากับ VBA ของคุณ พูดอย่างเคร่งครัดมีเป็นโอกาสที่คุณแนะนำข้อบกพร่อง / ข้อบกพร่องหรือความไร้ประสิทธิภาพ แต่ที่ดูเหมือนว่าไม่น่า เราไม่ได้พูดถึงพอร์ตจาก iOS / Objective C ถึง Android / Java เรากำลังพูดถึงพอร์ตระหว่างสองภาษาที่มีความคล้ายคลึงกันมากในรูปแบบไวยากรณ์และสามารถใช้เทคโนโลยีเดียวกัน - สมุดงาน Excel

•เราจะต้องทิ้งสิ่งที่เรา [ฉัน] ได้ทำไว้ในการแก้ปัญหา VBA และสร้างมันใหม่จากศูนย์ใน C #

ด้วยวิธีนี้คุณจะไม่ละทิ้งความพยายามหรือรหัสใด ๆ

•บางคนจะต้องสนับสนุนโซลูชันที่แยกกันสองรายการโซลูชันหนึ่งใน VBA และอีกโซลูชันหนึ่งใน C # [ที่จริงแล้วพวกเขาไม่มีใครให้การสนับสนุนฉันมักจะก้าวเข้ามา]

คุณจะมีเพียง 1 ทางออกทั้งหมดใน C #

โดยรวมแล้วลูกค้าของคุณเห็นความเสี่ยง หากคุณสามารถทำตามขั้นตอนเพื่อลดความเสี่ยงดังกล่าวพวกเขาอาจยอมรับการเปลี่ยนแปลงเป็น C #

ฉันเกลียดที่จะพูด แต่ข้อโต้แย้งของคุณไม่ได้กักน้ำไว้

การทดสอบหน่วย

ปัญหานี้ได้รับการแก้ไขแล้วเป็นเวลานานมาก มีกรอบการทดสอบหน่วยจำนวนมากออกมี เลือกหนึ่ง. คุณน่าจะทำสิ่งนี้ได้แล้ว ฉันแนะนำของเราเพราะมันรวมเข้ากับ IDE และมีคุณสมบัติที่ยอดเยี่ยมอื่น ๆ

การควบคุมแหล่งที่มา

อันนี้ค่อนข้างยากขึ้นมีโซลูชั่นสำเร็จรูปที่สร้างขึ้นไม่กี่ตัว นี่เป็นวิธีการเขียนคิ้วที่ต่ำแต่มีตัวเลือกอื่นที่ดีกว่าเช่นกัน

รหัสเอกสาร

ยังแก้ไขปัญหา MZ-Toolshas เป็นคุณลักษณะเอกสาร XMLที่ทำงานคล้ายกับเอกสารความคิดเห็น XML ของ. Net

แบบแผนการเข้ารหัสที่ดีกว่า

เช่นเดียวกับ Visual Studio ที่มีปลั๊กอิน ReSharper ทั้งMZ-ToolsและRubberduckมีคุณสมบัติดังกล่าว

IDE ที่ดีขึ้น

อีกครั้งมีปลั๊กอินสำหรับ VBA IDE

ความเป็นโมดูลที่มากขึ้นผ่านชุดประกอบ - สามารถส่งเสริมการใช้ซ้ำในเครื่องมือในอนาคต

ยังแก้ไขปัญหา ไม่คุณไม่สามารถสร้างแอสเซมบลี แต่คุณสามารถอ้างอิงโครงการ VBA อื่น ๆ

การปรับใช้ที่มีการจัดการ - สามารถควบคุมได้ว่าใครเป็นผู้ใช้เครื่องมือนี้

สติกเกอร์เล็กน้อยคุณจะต้องเขียนรหัสเพื่อควบคุมผู้ที่สามารถเข้าถึงโปรแกรมและผู้ที่ไม่สามารถทำได้ แต่คุณ (อีกครั้ง) อาจมีรหัสรักษาความปลอดภัยที่เขียนไว้แล้ว

ในฐานะที่เป็นสำหรับการใช้งานมันเป็นยังเป็นปัญหาที่แก้ไขได้ ใช่มันต้องใช้รหัส แต่มีตัวอย่างออกมีที่คุณสามารถใช้ / แก้ไข

เหนือสิ่งอื่นใดคือความจริงที่ว่าคุณจะเริ่มต้นจากศูนย์ ฉันก็จะแนะนำบทความของโจ Spolsky

พวกเขาทำโดยการทำผิดพลาดเชิงกลยุทธ์เพียงครั้งเดียวที่ บริษัท ซอฟต์แวร์รายใดสามารถทำได้:

พวกเขาตัดสินใจที่จะเขียนรหัสใหม่อีกครั้งตั้งแต่เริ่มต้น

พวก IT ของคุณถูกต้อง คุณไม่ควรเขียนซ้ำตั้งแต่ต้น คุณควรจะแก้ปัญหาด้วยวิธีแก้ปัญหาปัจจุบันของคุณ

ตอนนี้จากทั้งหมดที่กล่าวมาฉันสามารถเข้าใจได้อย่างสมบูรณ์ว่าทำไมคุณถึงอยากทำสิ่งนี้ใน C # หรือ VB.Net พวกเขาเป็นทางออกที่ดีกว่าถ้าคุณเริ่มโครงการใหม่แต่จากเสียงของมันมันไม่ใช่โครงการใหม่ มันจะดีกว่ามากในการปรับปรุงสิ่งที่คุณมีเพื่อทำลายมันโดยเริ่มต้นใหม่

คุณสามารถชี้ให้เห็นว่าแม้ไมโครซอฟท์ระบุในนี้บทความ:

การอัปเดตรหัสเพื่อปรับปรุงคุณสมบัติหรือแก้ไขข้อบกพร่องจะต้องมีการส่งสิ่งประดิษฐ์ Office อีกครั้งจัดโครงสร้างใหม่และทำงานซ้ำโดยผู้ใช้ทุกคนและในไฟล์เดียวที่ใช้การปรับแต่ง

บทความนี้เกี่ยวกับวิธีการต่าง ๆ ในการพัฒนาสิ่งต่าง ๆ โดยใช้ Office บางทีคุณอาจใช้ข้อดีและข้อเสียอื่น ๆ ในการอภิปรายของคุณ

ขึ้นอยู่กับว่าคุณตั้งใจจะย้ายไปที่ C # (เช่นเทคโนโลยีที่คุณจะใช้)

หากคุณกำลังจะใช้ OpenXML แสดงว่าคุณกำลังพูดถึงการเขียนซ้ำทั้งหมดซึ่งหากคุณมีโซลูชันที่ใช้งานได้ไม่แนะนำให้ใช้

หากคุณกำลังพูดถึงการใช้ Interop คุณอาจพบว่ากระบวนการนั้นราบรื่นอย่างน่าประหลาดใจ ฉันได้ย้ายรหัสจำนวนมากจาก VBA เป็น C # (ด้วย Interop) ในอดีตและเมื่อคุณเสียบเข้ากับสมุดงานแล้วเช่น:

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

ในหลายกรณีคุณสามารถคัดลอก / วางรหัส VBA ของคุณการเรียกฟังก์ชันล่วงหน้าด้วยworkbook.แทนที่Dimด้วยvarฯลฯ ตามความเหมาะสมและเพิ่มเครื่องหมายอัฒภาคในตอนท้าย

มันคือ Framework เดียวกันภายใต้ (Excel) คุณเพียงแค่เปลี่ยนไวยากรณ์จาก VBA เป็น C #

เมื่อเสร็จแล้วให้แน่ใจว่าได้บันทึกและปิดแอปพลิเคชัน:

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

จากนั้นปล่อยแอปพลิเคชันด้วย Marshal:

Marshal.ReleaseComObject(excelApplication);

ฉันอาจจะเขียนคลาส wrapper การใช้ IDisposable รอบวัตถุ Excel Application แล้วให้แน่ใจว่าใช้usingเมื่อวัตถุนี้ถูกใช้

วิธีที่ดีในการทำให้กรณีของคุณคือการใช้เวลาหนึ่งชั่วโมงหรือมากกว่านั้นในการทำสิ่งนี้ซึ่งในระยะเวลาอันสั้นจะแสดงให้เห็นว่าคุณสามารถแปลงรหัสผ่านได้อย่างรวดเร็วและโน้มน้าวเพื่อนร่วมงานของคุณว่านี่เป็นความคิดที่ดี

รหัสจะยังคงไม่เปลี่ยนแปลงส่วนใหญ่ในทาง แต่คุณมีประโยชน์ทั้งหมดที่คุณกล่าวถึงการมีโครงการ C # ภายใน Visual Studio

ฉันอยู่ในตำแหน่งเดียวกันโดยมีแอปพลิเคชันขนาดใหญ่มาก (20k + บรรทัดของรหัส VBA) ติดตั้งไว้ในสมุดงาน EXCEL เมื่อทดสอบกับ Office 2013 มันก็ล้มเหลวในการทำงานเชื่อว่าเกิดจากการเปลี่ยนแปลงลำดับของเหตุการณ์เริ่มต้นในรูปแบบสำนักงานใหม่และอาจมีการบังคับใช้ EMET ที่เข้มงวดยิ่งขึ้น ฉันจึงอยู่ในฐานะที่จะทำการแปลงล้มเหลวเป็น C # และ VB.NET ก่อนที่จะเปิดตัว Office 2013 ในปีนี้ สมุดงานอื่น ๆ ที่เรียบง่าย (ปรับปรุง VBA) ที่ใช้รอบองค์กรไม่ได้รับภูมิคุ้มกันบางงานและบางเล่มไม่

ข้อผิดพลาดเกิดขึ้นในเหตุการณ์Workbook_Openโดยที่แผ่นงานของเวิร์กบุ๊กไม่สามารถใช้งานได้อีกต่อไปและในรหัส EXCEL ภายในก่อนรหัส VBA ใด ๆ ที่ถูกอ้างอิง

ความสะดวกสบายใน VBA, C # และ VB.NET ทั้งหมดฉันกำลังเขียนการแปลงทั้งสองอย่างหลัง รหัส Framework ถูกเขียนใน C # เพราะสำนวนภาษาอนุญาตให้ฉันเขียนโครงสร้างการทำงานบางอย่างในภาษานั้นเร็วกว่าใน VB.NET 3-4 เท่า ส่วนใหญ่ของรหัสอยู่ใน VB.NET เพราะจากนั้นการเขียนของฉันจะน้อยกว่าและมีสำนวนบางอย่างที่ไม่มีใน C #

ก่อนที่จะทำการตัดสินใจใด ๆ ฉันขอแนะนำอย่างยิ่งให้คุณทดสอบแอปพลิเคชันที่มีอยู่กับ OFFICE 2013 และขอบเขตการบังคับใช้ EMET อย่างเต็มที่ที่องค์กรคาดการณ์ไว้ในอีก 2-3 ปีข้างหน้า คุณอาจค้นพบว่าแอปพลิเคชันที่มีอยู่จะไม่ทำงานในสภาพแวดล้อมนั้นโดยไม่ต้องเขียนใหม่ แต่อย่างใดการเขียนซ้ำอาจอยู่ใน DOT NET และ VSTO

ภาคผนวก:

การเขียนยูทิลิตี้แยกแบบอัตโนมัติเล็ก ๆ น้อย ๆ ที่วนรอบเนื้อหาทั้งหมดของเวิร์กบุ๊ก VBA และส่งออกโมดูลคลาสและฟอร์มไปยังไฟล์ทั้งหมดนั้นใช้งานได้ 1-2 วันขึ้นอยู่กับว่าคุณต้องการให้มันเป็นอย่างไร เช่นเดียวกันกับการย้อนกลับเพื่อนำเข้าไฟล์จากไดเรกทอรีไปยังสมุดงานเปล่า ด้วยสองสิ่งนี้เป็นไปได้ที่จะมีรหัส VBA ทั้งหมดของคุณในการควบคุมแหล่งที่มาที่เหมาะสมและมีกระบวนการสร้างจากซอร์สโค้ดสำหรับสมุดงานของคุณ

หรือ - ใช้โปรแกรมอรรถประโยชน์ฟรีเช่นExcel VBA Code Cleaner

ฉันต้องการที่จะใช้โอกาสนี้ทำความเข้าใจกับทักษะ C # ของฉันในขณะที่ฉันไม่เก่งใน C # เหมือนฉัน VBA และฉันต้องการโครงการเช่นนี้เพื่อพาฉันไปสู่ ​​"ระดับต่อไป"

ซื่อสัตย์.คุณวางแผนที่จะแบ่งปันข้อมูลนี้กับคนอื่น ๆ ที่เกี่ยวข้องในการตัดสินใจนี้หรือไม่? ถ้าไม่ฉันจะโทษทั้งคุณถ้าโครงการล้มเหลว เนื่องจากโครงการที่คล้ายกันได้ถูกสร้างขึ้นแล้วและนำออกสู่สนามทุกคนได้สร้างสิ่งที่พวกเขาคาดหวังที่จะเกิดขึ้นในใจของพวกเขาเอง พวกเขารู้ว่าใช้เวลานานแค่ไหนในการสร้างสิ่งสุดท้ายและจะเชื่อว่าคุณสามารถสร้างสิ่งนี้ได้ในเวลาน้อยลง (ซึ่งอาจจะจริงหรือไม่จริงก็ได้ตามข้อกำหนดเพิ่มเติม) คุณพร้อมที่จะรับผิดชอบในเรื่องนี้พร้อมกับการเรียนรู้ภาษาใหม่หรือยัง?

ฉันแนะนำให้ย้ายแอพเก่าไปที่ C # ASAP บางทีคุณสามารถเรียนรู้ได้มากพอในกระบวนการก่อนที่จะตัดสินใจ อย่างน้อยคุณก็จะบรรลุเป้าหมายของการพัฒนาทักษะด้วยภาษาใหม่และยังคงทำโครงงานให้เสร็จทันเวลา

จากนั้นอีกครั้งหากคุณรู้สึกว่ามีความแข็งแกร่งเกี่ยวกับมันและการสร้างโครงการคือการพักผ่อนบนไหล่ของคุณให้ทำในแบบที่คุณต้องการ การให้อภัยง่ายกว่าการอนุญาตเสมอ