เป็นความคิดที่ดีกว่าหรือไม่ที่จะเรียกแอปพลิเคชันบรรทัดคำสั่งภายนอกหรือเพื่อปรับตรรกะภายในของแอปพลิเคชัน


10

ฉันมีกระบวนการ "ขั้นตอน" ที่เชื่อมโยงเครื่องมือต่างๆที่มีอยู่เข้าด้วยกันเพื่อทำให้เวิร์กโฟลว์เป็นแบบอัตโนมัติ สำหรับขั้นตอนใดขั้นตอนหนึ่งมีเครื่องมือบรรทัดคำสั่งที่มีอยู่แล้วซึ่งทำหน้าที่เป็นเนื้อสัตว์ของขั้นตอนที่ต้องทำ

เครื่องมือ CLI ภายนอกเป็นแบบ java และไปป์ไลน์ของฉันดังนั้นจึงเป็นไปได้ที่จะรวมเครื่องมือเข้ากับขั้นตอนไปป์ไลน์โดยตรง แต่เครื่องมือมีความซับซ้อนมาก 37 ตัวเลือกการตั้งค่าสถานะ)

คำถามคือมันเป็นความคิดที่ดีกว่าที่จะเพียงแค่โทรออกและเรียกใช้กระบวนการภายนอกหรือจะเป็นการดีกว่าที่จะรวมรหัสภายนอกภายในแอปพลิเคชันของฉัน

อะไรคือข้อดี / ข้อเสียของการบูรณาการกับการเรียกกระบวนการภายนอก?


เครื่องมือบรรทัดคำสั่งเป็นสิ่งที่คุณควบคุมหรือเป็นสิ่งที่พัฒนาโดยบุคคลอื่นหรือไม่
whatsisname

มันเป็นโอเพ่นซอร์ส (สิทธิ์ใช้งาน Mozilla) ชุดเครื่องมือ dcm4che DICOM ดังนั้นจึงได้รับการพัฒนาโดยบุคคลอื่น แต่ฉันสามารถทำอะไรกับมันได้ทุกอย่างที่ฉันต้องการ
cdeszaq

คำตอบ:


12

เป็นความคิดที่ดีกว่าหรือที่จะเพียงแค่โทรออกและเรียกใช้กระบวนการภายนอกหรือจะเป็นการดีกว่าที่จะรวมรหัสภายนอกภายในแอปพลิเคชันของฉัน

มันจะดีกว่ามากที่จะรวมสิ่งเหล่านี้

อินเตอร์เฟสบรรทัดคำสั่งเป็นเพียงส่วนต่อประสานและส่วนติดต่อที่น่ากลัวเป็นพิเศษ มันสำคัญแต่ก็เต็มไปด้วยนิสัยใจคอและข้อ จำกัด ที่ไม่สมเหตุสมผล

"เครื่องมือที่มีอยู่เพื่อทำให้เวิร์กโฟลว์อัตโนมัติ" ควรมีคลาสที่เป็นระเบียบเรียบร้อยซึ่งทำงานจริงหลังจากตัวเลือกบรรทัดคำสั่งได้รับการแยกวิเคราะห์

ตามหลักการแล้วpublic static void mainฟังก์ชันจะทำสองสิ่งใน "เครื่องมือที่มีอยู่" แต่ละรายการ

  1. มันจะเรียกใช้ตัวเลือกบรรทัดคำสั่ง / ตัวแยกอาร์กิวเมนต์

  2. มันเรียกชั้นเรียนที่เป็นระเบียบเรียบร้อยซึ่งใช้งานได้จริง คิดว่าภารกิจ Ant หรือภารกิจ Maven ที่ทำงานจริงหลังจาก Ant หรือ Maven ได้จัดการการแยกวิเคราะห์และการตัดสินใจทั้งหมด

เมื่อคุณรวมสิ่งเหล่านี้เข้าด้วยกันคุณต้องการคลาสที่เป็นระเบียบที่ใช้งานได้จริง

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

สำหรับคำแนะนำเกี่ยวกับวิธีการเรียนที่เป็นระเบียบเรียบร้อยเหล่านี้ควรอ่าน Ant (หรือ Maven) เพื่อดูว่าพวกเขากำหนดงานผู้ปฏิบัติงานต่าง ๆ อย่างไร มันเป็นแบบจำลองทางจิตที่ดีสำหรับการรวมสิ่งต่าง ๆ เข้าด้วยกันโดยไม่ต้องกลับไปที่บรรทัดคำสั่ง


ในกรณีของฉันคลาสที่ทำงานเป็นเครื่องมือทั้งหมดและมีmainวิธีการวิธีการแยกวิเคราะห์ CLI ฯลฯ มันค่อนข้างน่ารังเกียจ :(
cdeszaq

@cdeszaq: ในกรณีนั้นจะต้องได้รับการแก้ไข มันไม่ใช่เรื่องยากที่จะเขียนซ้ำและต้องทำ
S.Lott

3
ฉันต้องการเพิ่มว่าขึ้นอยู่กับกำหนดเวลาของคุณคุณสามารถรวมเข้ากับส่วนต่อประสาน CL ที่มีอยู่และพอร์ตผ่านไปยังโซลูชันที่ผสานรวมอย่างเหมาะสมเมื่อเวลาผ่านไป แต่ถ้าคุณมีเวลาแก้ไขในตอนนี้ให้ทำดังนี้ :-)
Martijn Verburg

1
@ MartijnVerburg: จุดที่ดี บ่อยครั้งมีลำดับความสำคัญที่ชัดเจน เวิร์กโฟลว์บางตัวถูกรวมเข้าด้วยกันอย่างแน่นหนามากขึ้นหรืออาจมีการใช้งานแยกต่างหากเป็น "เวิร์กโฟลว์ย่อย" สิ่งนี้อาจนำไปสู่การค้างจากการทำงานซ้ำจากค่าที่มีค่ามากไปหาน้อยที่สุด
S.Lott

ที่นายจ้างคนสุดท้ายของฉันเราพบปัญหาในการเรียกใช้ยูทิลิตี้ exe (เรา แต่ไม่ใช่รหัสของฉันเลย) ช่วยผู้พัฒนา "รุ่นพี่" วินิจฉัยว่าเหตุใด exe นี้จะไม่ทำงานฉันแนะนำให้เขียนไฟล์ bat เพื่อเริ่มการทำงาน มันได้ผล เขาหยุดมองหาปัญหาและนั่นเป็นวิธีที่มันออกไปนอกประตู บทเรียนที่ฉันเรียนรู้คือ 1 อย่าเสนอแนวคิดที่ไม่ดีในการแก้ไขปัญหาให้กับคนที่ตัดสินใจ 2. ใช้ไลบรารีหรือปรับตรรกะภายในของคุณเองให้มากที่สุด การ "แก้ไข" นั้นต้องเสียค่าใช้จ่ายในการสนับสนุนด้านเทคนิคในเครื่องบางเครื่อง นอกจากนี้เขายังไม่เชื่อในการทดสอบหรือการควบคุมแหล่งจึงไม่แปลกใจ ...
Rig

8

ฉันจะบอกว่าปล่อยไว้คนเดียวถ้ามันใช้งานได้

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

อย่างไรก็ตามสองสามปัจจัยที่อาจลดการใช้จ่ายในเวลานั้นคือความสามารถในการปรับขนาดได้และหากมีข้อกังวลใด ๆ เกี่ยวกับความเสถียรของโปรแกรมภายนอก


ฉันเห็นด้วย. คุณสามารถเปิดตัวเองได้ถึงปัญหามากมายที่พยายามรวมโปรแกรม / รหัสของบุคคลที่สามไว้ในแอพของคุณ บางครั้งก็เป็นสิ่งที่จำเป็น แต่เป็นว่าไป "ถ้ามันยังไม่หักไม่ซ่อมมัน"
jfrankcarr

5
การแก้ปัญหาเป็นสิ่งที่ดี การแก้ไขปัญหาบางอย่างในขณะที่เปิดประตูสู่ปัญหาอื่น ๆ นั้นไม่ค่อยดีนัก
yfeldblum

5

ไม่ใช่ "ดีกว่า" หรือ "แย่กว่า" มีค่าใช้จ่ายและผลประโยชน์ที่แตกต่างกันเพียง

บ่อยครั้งที่การเขียนและบำรุงรักษาซอฟต์แวร์มีราคาแพงกว่าจำนวนจุดรวมที่เพิ่มขึ้นตามความซับซ้อนที่เพิ่มขึ้น

  • ฟังก์ชั่นที่คุณเขียนมีค่าใช้จ่ายในการรวมน้อยมาก
  • ห้องสมุดบุคคลที่สามมีต้นทุนการรวมที่สูงขึ้นเล็กน้อย
  • โปรแกรมแยกต่างหากที่คุณต้องดำเนินการจะมีและต้นทุนการรวมที่สูงขึ้น

หมายเหตุเหล่านี้คือค่าใช้จ่ายในการรวมซึ่งคุณต้องเทียบกับค่าใช้จ่ายทั้งหมดซึ่งรวมถึงค่าใช้จ่ายในการเขียนและบำรุงรักษาซอฟต์แวร์

อาจเป็นกรณีที่คุณเป็นโปรแกรมเมอร์ที่ไม่มีประสบการณ์ แต่เป็นผู้ใช้ที่ใช้เวลานาน

  • หากคุณต้อง "คัดค้าน" ค่าใช้จ่ายทั้งหมดของคุณอาจต่ำแม้จะมีค่าใช้จ่ายในการรวมที่สูงขึ้นเพราะคุณสามารถลดต้นทุนการรวมด้วยประสบการณ์และความรู้ของคุณ
  • หากคุณต้องเขียนฟังก์ชั่นด้วยตัวคุณเองค่าใช้จ่ายทั้งหมดของคุณอาจจะค่อนข้างสูงแม้จะมีค่าใช้จ่ายในการรวมที่ต่ำเนื่องจากการเขียนโปรแกรมที่ขาดประสบการณ์

วิธีที่ดีที่สุดในการคิดออก:

เป็นความคิดที่ดีกว่าหรือไม่ที่จะเรียกแอปพลิเคชันบรรทัดคำสั่งภายนอกหรือเพื่อปรับตรรกะภายในของแอปพลิเคชัน

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


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

1

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

สิ่งที่ต้องพิจารณาคือเสถียรภาพ ฉันพบสิ่งที่คล้ายกันสองสามปีที่ผ่านมาและเก็บโปรแกรม cli ในสถานที่ มันไม่เสถียรเกินไปและฉันไม่ต้องการให้ระบบหยุดทำงานเพื่อลบแอปพลิเคชันหลักซึ่งจำเป็นต้องเรียกใช้ 24/7 ทีนี้นี่ไม่ใช่แอปพลิเคชัน java แต่ก็ไม่น้อยไปกว่านี้หากเป็นปัญหาที่อาจนำมาใช้คุณอาจต้องการพิจารณาสิ่งนั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.