বাহ্যিক কমান্ড-লাইন অ্যাপ্লিকেশন কল করা বা সেই অ্যাপ্লিকেশনটির যুক্তি অভ্যন্তরীণ করা কি আরও ভাল ধারণা?

10

আমার কাছে একটি "পাইপলাইন" ধরণের প্রক্রিয়া রয়েছে যা মূলত ওয়ার্কফ্লোটি স্বয়ংক্রিয় করার জন্য প্রচুর বিদ্যমান সরঞ্জামগুলির সাথে একসাথে যুক্ত হয়। একটি পদক্ষেপের জন্য, একটি বিদ্যমান কমান্ড-লাইন সরঞ্জাম রয়েছে যা ইতিমধ্যে সেই পদক্ষেপটি করার দরকারের মাংস করে।

বাহ্যিক সিএলআই সরঞ্জামটি জাভা ভিত্তিক, এবং এটি আমার পাইপলাইনও তাই পাইপলাইন ধাপে সরাসরি সরঞ্জামটি সংহত করা সম্ভব হবে, তবে সরঞ্জামটি খুব জটিল এবং বর্তমানে কমান্ড-লাইন ইনপুট থাকার সাথে ঘনিষ্ঠভাবে আবদ্ধ (যেমন কিছু 37 কনফিগার পতাকা বিকল্প))

প্রশ্নটি হ'ল: বাহ্যিক প্রক্রিয়াটি সহজভাবে কল করা এবং প্রার্থনা করা কি আরও ভাল ধারণা, বা আমার আবেদনের মধ্যে বাহ্যিক কোডকে একীভূত করা আরও ভাল be

বাহ্যিক প্রক্রিয়া কলকরণের বনাম সংহত করার পক্ষে কি কি?

java architecture

— cdeszaq
সূত্র

কমান্ড-লাইন সরঞ্জামটি এমন কিছু যা আপনি নিয়ন্ত্রণ করেন বা এটি অন্য কোনও পক্ষ দ্বারা বিকশিত হয়েছে?

— 15 এ

এটি ওপেন সোর্স (মজিলা লাইসেন্স) dcm4che DICOM টুলকিট, সুতরাং এটি অন্য পক্ষ দ্বারা বিকাশ করা হয়েছে, তবে আমি যা ইচ্ছা তা করতে পারি।

— সিডেসাক

12

বাহ্যিক প্রক্রিয়াটি সহজভাবে কল করা এবং প্রার্থনা করা কি আরও ভাল ধারণা, বা আমার আবেদনের মধ্যে বাহ্যিক কোডকে একীভূত করা আরও ভাল?

এটা অনেক এইসব সংহত করতে ভাল।

কমান্ড-লাইন ইন্টারফেসটি কেবল একটি ইন্টারফেস এবং বিশেষত ভয়াবহ। এটি অপরিহার্য তবে এটি কোয়ার্ক এবং সীমাবদ্ধতায় ভরাও বুদ্ধিমান নয়।

"একটি ওয়ার্কফ্লো স্বয়ংক্রিয় করার জন্য বিদ্যমান সরঞ্জামগুলির" প্রত্যেকের একটি পরিপাটি শ্রেণি থাকা উচিত যা কমান্ড-লাইন বিকল্পগুলি বিশ্লেষণ করার পরে আসল কাজ করে।

আদর্শভাবে, public static void mainফাংশনটি সেই "বিদ্যমান সরঞ্জামগুলির" প্রতিটিতে দুটি জিনিস করে।

এটি কিছু কমান্ড-লাইন বিকল্প / যুক্তি পার্সার আহ্বান করে।
এটি পরিশ্রমী ক্লাসকে আহ্বান করে যা আসল কাজ করে। একটি পিঁপড়া টাস্ক বা কোনও ম্যাভেন টাস্কের কথা চিন্তা করুন যা পিঁপড়া এবং মাভেনের সমস্ত পার্সিং এবং সিদ্ধান্ত গ্রহণের পরে আসল কাজ করে।

আপনি যখন এই জিনিসগুলিকে সংহত করতে যান, আপনি এমন পরিচ্ছন্ন ক্লাসগুলি চান যা আসল কাজ করে।

যদি সেগুলির অস্তিত্ব না থাকে, তবে আপনাকে সমস্ত কমান্ড-লাইন পার্সিং থেকে পৃথক করে প্রকৃত কাজ করে এমন পরিপাটি শ্রেণি তৈরি করতে আপনাকে সেই সমস্ত সরঞ্জাম পুনরায় লিখতে হবে।

এই পরিপাটি শ্রেণীর কীভাবে কাজ করা উচিত সে সম্পর্কে দিকনির্দেশের জন্য, এন্টি (বা ম্যাভেন) পড়ুন কীভাবে তারা বিভিন্ন কর্মী কর্মের সংজ্ঞা দেয় তা দেখতে। কমান্ড লাইনে ফিরে না গিয়ে একাধিক, বৈচিত্র্যময় জিনিসগুলি কীভাবে সংহত করা যায় তার জন্য এটি একটি ভাল মানসিক মডেল।

— S.Lott
সূত্র

আমার ক্ষেত্রে, ক্লাসটি কাজ করছে এটি সম্পূর্ণ সরঞ্জাম এবং এতে mainপদ্ধতি, সিএলআই-পার্স পদ্ধতি ইত্যাদি রয়েছে এটি বরং

— মজাদার

@ cdeszaq: সেক্ষেত্রে এটি ঠিক করা দরকার। এটি খুব ভয়ঙ্করভাবে পুনর্লিখন নয়, এবং এটি করা আবশ্যক ।

— এস .লট

3

আমি যুক্ত করব যে আপনার সময়সীমার উপর নির্ভর করে আপনি বিদ্যমান সিএল ইন্টারফেসের সাথে একীভূত করতে পারেন এবং সময়ের সাথে সঠিকভাবে সংহত সমাধানে পোর্ট করতে পারেন। তবে এখনই এটি ঠিক করার সময় যদি আপনার কাছে থাকে তবে তা করুন :-)

— মার্তিজান ভার্গবার্গ

1

@ মার্তিজনভর্বার্গ: গুড পয়েন্ট প্রায়শই, একটি পরিষ্কার অগ্রাধিকার আছে। কিছু কর্মপ্রবাহ আরও দৃ tight়ভাবে সংহত হয়েছে বা সম্ভবত "উপ-ওয়ার্কফ্লো" হিসাবে পৃথক ব্যবহার করতে পারে। এটি সবচেয়ে মূল্যবান থেকে ন্যূনতম মূল্যবান থেকে পুনর্নির্মাণের একটি ব্যাকলগের দিকে নিয়ে যেতে পারে।

— এস .লট

আমার শেষ নিয়োগকর্তায় একটি ইউটিলিটি এক্সকে কার্যকর করতে আমাদের সমস্যা হয়েছিল (আমরা কিন্তু আমার কোডটি মোটেও করি না)। "সিনিয়র" বিকাশকারীকে নির্ধারণে সহায়তা করা কেন এই প্রতিবেদকটি কার্যকর হবে না আমি ব্যাট ফাইলটি বন্ধ করে দেওয়ার জন্য পরামর্শ দিয়েছিলাম। এটা কাজ করেছে. তিনি সমস্যাটি অনুসন্ধান করা বন্ধ করে দিয়েছিলেন এবং কীভাবে দরজাটি বাইরে চলে গেছে। আমি যে পাঠটি শিখেছি তা হল ১. সিদ্ধান্ত গ্রহণকারী কারও কাছে সমস্যা সমাধানের জন্য কোনও খারাপ ধারণা প্রস্তাব করবেন না। ২. গ্রন্থাগারগুলি ব্যবহার করুন বা যথাসম্ভব নিজের যুক্তিকে অভ্যন্তরীণ করুন। এই "ফিক্স" এর জন্য কয়েকটি মেশিনে বেশ কয়েকটি প্রযুক্তিগত সহায়তা ব্যয় করা হয়েছে। তিনি পরীক্ষা বা উত্স নিয়ন্ত্রণে বিশ্বাস করেননি তাই অবাক হওয়ার কিছু নেই ...

— রিগ

8

আমি বলব এটি যদি কাজ করে তবে একা ছেড়ে দিন।

প্রোগ্রামার হিসাবে আপনি সফ্টওয়্যার দিয়ে সমস্যাগুলি সমাধান করে আপনার সংস্থার মান আনেন। একটি নির্দিষ্ট সময়ের মধ্যে গুণমান এবং পরিমাণ উভয়ই আরও সমস্যার সমাধান সংস্থায় আপনার মূল্যের সাথে সরাসরি সম্পর্কিত। কোড তৈরি করতে এই সময় ব্যয় করা আপনার মানকে হ্রাস করে কারণ এটি আপনাকে আরও গুরুত্বপূর্ণ সমস্যা সমাধান থেকে দূরে নিয়ে যায়।

যাইহোক, বেশ কয়েকটি কারণ যা সময় ব্যয় প্রশমিত করতে পারে তা হ'ল স্কেলিবিলিটি এবং যদি বাহ্যিক প্রোগ্রামের স্থিতিশীলতার জন্য কোনও উদ্বেগ থাকে।

— bigtech
সূত্র

আমি রাজী. আপনার অ্যাপ্লিকেশনটিতে তৃতীয় পক্ষের প্রোগ্রাম / কোড একীভূত করার চেষ্টা করতে আপনি নিজেকে অনেক সমস্যার মুখোমুখি করতে পারেন। কখনও কখনও এটি প্রয়োজনীয় হয় তবে যেমন বলা হয়, "এটি যদি না ভাঙে তবে এটি ঠিক করবেন না"

— jfrankcarr

5

সমস্যা সমাধান দুর্দান্ত। অন্যান্য সমস্যার দরজা খোলার সময় কিছু সমস্যা সমাধান করা এত দুর্দান্ত নয়।

— yfeldblum

5

এটি "আরও ভাল" বা "খারাপ" নয়। কেবল বিভিন্ন ব্যয় এবং সুবিধা রয়েছে।

সংযুক্তি পয়েন্ট সংখ্যক জটিলতার তুলনায় বৃহত সংখ্যক সফ্টওয়্যার লিখতে এবং বজায় রাখা আরও ব্যয়বহুল।

আপনি যে ফাংশনটি লেখেন তাতে ইন্টিগ্রেশন ব্যয় খুব কম হয়।
তৃতীয় পক্ষের লাইব্রেরিতে কিছুটা বড় সংহতকরণের ব্যয় হয়।
আপনাকে কার্যকর করতে হবে এমন একটি পৃথক প্রোগ্রামের আরও বেশি সংহতকরণের ব্যয় হবে।

নোট করুন এটি হ'ল ইন্টিগ্রেশন ব্যয়গুলি যা আপনাকে মোট ব্যয়ের তুলনায় ভারী করতে হবে যা সফ্টওয়্যার লেখার এবং রক্ষণাবেক্ষণের জন্য অন্যান্য জিনিসের মধ্যে অন্তর্ভুক্ত।

এটি এমন পরিস্থিতিতে হতে পারে যে আপনি খুব অনভিজ্ঞ প্রোগ্রামার, তবে দীর্ঘ সময়ের শক্তি ব্যবহারকারী।

উচ্চতর ইন্টিগ্রেশন ব্যয় সত্ত্বেও আপনি যদি "শেল আউট" করতে পারেন তবে আপনার মোট ব্যয় কম হতে পারে, কারণ আপনি নিজের অভিজ্ঞতা এবং জ্ঞানের সাহায্যে ইন্টিগ্রেশন ব্যয় হ্রাস করতে পারেন।
আপনি যদি নিজে নিজে এই ফাংশনটি লিখতে থাকেন তবে আপনার অনভিজ্ঞ প্রোগ্রামিংয়ের কারণে কম সংহতকরণ ব্যয়ের পরেও আপনার মোট ব্যয় বেশ বেশি হতে পারে।

খুঁজে বের করার সর্বোত্তম উপায়:

বাহ্যিক কমান্ড-লাইন অ্যাপ্লিকেশন কল করা বা সেই অ্যাপ্লিকেশনটির যুক্তি অভ্যন্তরীণ করা কি আরও ভাল ধারণা?

নিজের জন্য ব্যয় গণনা করা হয়। খরচ বিভিন্ন পরিবেশ, পরিস্থিতি এবং মানুষের জন্য আলাদা হবে different বেশিরভাগ সময় কমান্ড লাইনে কল করতে আরও বেশি খরচ হবে, তবে সর্বদা নয় এবং বিশ্লেষণটি করা নিশ্চিত হওয়ার একমাত্র উপায়।

— dietbuddha
সূত্র

আমার ক্ষেত্রে, এটা মূলত একটি বহিরাগত অ্যাপ্লিকেশন যে ঘটবে ওপেন সোর্স এবং জাভা লেখা শুধু মত হতে আমার আবেদন। দুর্ভাগ্যবশত, নয় কেবল একটি লাইব্রেরি বহিরাগত অ্যাপ্লিকেশন ব্যবহারের, যেহেতু লাইব্রেরির নিজেই ইন্টারফেস CLI মধ্যে শক্তভাবে একত্রিত অবস্থায় থাকে। তা ছাড়া, সমস্ত ভাল পয়েন্ট।

— সিডেসাক

1

আদর্শভাবে আপনি এটি সংহত করতে চান। বিশেষত যদি এটি এমন কোনও অ্যাপ্লিকেশন যা বিতরণ করা হয় - নির্ভরতা এবং কনফিগারেশনের সংখ্যা হ্রাস করা এটিকে আরও সহজ করে তুলবে। তবে এটি অবশ্যই আপনার নির্দিষ্ট ক্ষেত্রে একটি ব্যয় / বেনিফিট ইস্যু।

এই বলেছিল, একটা বিষয় বিবেচনা করা উচিত স্থিতিশীলতা। কয়েক বছর আগেও আমি একই জাতীয় কিছু মুখোমুখি হয়েছি এবং ক্লাইটি প্রোগ্রামটি রেখেছি। এটি খুব অস্থির ছিল এবং আমি চাইনি যে এটির ক্রাশটি প্যারেন্ট অ্যাপ্লিকেশনটি নেবে, যা 24/7 চালানো দরকার। এখন এটি জাভা অ্যাপ্লিকেশনটি অপ্রয়োজনীয়, তবে এর চেয়ে কম কোনওটিই নয়, যদি এটি প্রয়োগ করে তবে এমন কোনও সমস্যা যদি আপনি এটি বিবেচনায় রাখতে চান।

— GrandmasterB
সূত্র