আর প্যাকেজটি কখন এবং কখন তৈরি করবেন?

Question

আমি বুঝতে পেরেছি এই প্রশ্নটি বেশ বিস্তৃত, তবে আমি আশ্চর্য হয়েছি যে আর এর জন্য একটি নতুন প্যাকেজ তৈরি করার (বা না) সিদ্ধান্ত নেওয়ার ক্ষেত্রে সিদ্ধান্তমূলক পয়েন্টগুলি কী হওয়া উচিত। আরও নির্দিষ্ট করে বলার জন্য, আমি যুক্ত করব যে প্রশ্নটি কারণগুলির বিষয়ে নয় নিজে থেকে আর ব্যবহার করুন, বিভিন্ন স্ক্রিপ্টগুলি সংকলন করার সিদ্ধান্ত এবং আরও নতুন প্যাকেজে সংহত করার বিষয়ে আরও about

এই সিদ্ধান্তগুলির দিকে পরিচালিত করতে পারে এমন পয়েন্টগুলির মধ্যে, আমি ভেবেছি (বেশ অব্যাহত ফ্যাশনে), এর:

• একই উপ-ক্ষেত্রের অন্যান্য প্যাকেজগুলির অস্তিত্ব;
• অন্যান্য গবেষকদের সাথে মতবিনিময় এবং পরীক্ষার পুনরুত্পাদনযোগ্যতার অনুমতি দেওয়ার প্রয়োজন;

এবং বিপরীতে সিদ্ধান্ত গ্রহণ করতে পারে যে পয়েন্টগুলির মধ্যে:

• অন্যান্য প্যাকেজের মধ্যে ইতিমধ্যে ব্যবহৃত পদ্ধতির অংশ;
• একটি নতুন স্বতন্ত্র প্যাকেজ তৈরির পক্ষে ন্যায্যতা প্রমাণ করতে যথেষ্ট নতুন কর্মের সংখ্যা।

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

Answer 1

আমি আর তে প্রোগ্রাম করি না, তবে আমি অন্যথায় প্রোগ্রাম করি এবং আমি এখানে আর-নির্দিষ্ট সমস্যা দেখতে পাচ্ছি না।

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

জনসাধারণের কাছে যাওয়াই আত্মবিশ্বাসের বিষয় বলে মনে হচ্ছে যে আপনার কাছে ইতিমধ্যে প্রকাশ্য যা কিছু তার চেয়ে ভাল বা ভাল যা একটি শূন্যস্থান পূরণ করে। অন্যান্য লোকেরাও একই কাজ করতে চায় তা জেনে রাখা অবশ্যই একটি উত্সাহ।

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

এটিতে একটি বই থাকতে পারে তবে কয়েকটি পয়েন্টার মনে পড়তে পারে:

1. ভাল মানের ডকুমেন্টেশন ভাল সফ্টওয়্যার পাশাপাশি ভাল কোডও পৃথক করে তোলে, কখনও কখনও আরও স্পষ্টতই। কোডটি প্রাপ্য ডকুমেন্টেশন সরবরাহ করতে কতটা কাজের প্রয়োজন হবে তা কখনই অনুমান করবেন না। আর প্রোগ্রামাররা প্রায়শই প্রয়োজন মনে করেন যে আর ব্যবহারকারীরা কৌশলটি বাস্তবায়িত হওয়ার বিষয়ে এবং ন্যূনতমভাবে নথির বিষয়ে ঠিক ততটাই জানেন ....

2. যতদূর সম্ভব, আপনার কোডটি পরীক্ষা করুন যাতে আপনি অন্য কোথাও থেকে প্রকৃত ডেটা সহ প্রকাশিত সমাধানগুলি পুনরুত্পাদন করতে পারেন। (আপনি যদি একেবারে নতুন কিছু কোড করে রেখেছেন তবে এটি আরও বেশি কঠিন তবে অসম্ভব নয় Also এছাড়াও, আপনি প্রায়শই নিজেকে ভাবতে পারেন যে এটি তাদের বাগ বা আপনার))

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

Comments

আমি এই তিনটি পয়েন্টের সাথে আরও একমত হতে পারি না (যদিও পয়েন্ট 2 আমার বিশেষ ক্ষেত্রে প্রযোজ্য হবে না, যেহেতু আমি প্রশ্নটিতে পদ্ধতিটি তৈরি করেছি)। তৃতীয় পয়েন্টটি একটি অত্যন্ত গুরুত্বপূর্ণ একটি, এবং আরও সাধারণভাবে তথ্যের স্তরের বিষয়টি উত্থাপিত হয় যেটি ব্যবহারকারীর কাছ থেকে প্রত্যাশা করা যেতে পারে (বা: আমরা কার জন্য কোন প্যাকেজ প্রকাশ করি) আমরা কি কেবল ক্ষেত্রের বিশেষজ্ঞদের জন্য পরিচিত, পরিচিত হাতে থাকা পদ্ধতিতে, বা আমাদের সম্পর্কিত সমস্ত নিবন্ধগুলি পড়েনি এমন আগ্রহী পণ্ডিতদের দ্বারা আমাদের প্যাকেজটি ব্যবহারযোগ্য করে দেওয়ার চেষ্টা করবেন?

— জিন-ব্যাপটিস্ট ক্যাম্পগুলি

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

— নিক কক্স

পরাজয়কারীদের কাছ থেকে বিজয়ীদের এবং আপনার খুব কার্যকর পয়েন্টগুলি সম্পর্কে: # 1: সৌভাগ্যক্রমে, আরে কিছু পয়েন্ট রয়েছে যা সহজেই পরীক্ষা করতে পারে এবং কোনটি প্রথাগত প্রয়োজনীয় সহায়তা পৃষ্ঠাগুলির চেয়ে আরও ভাল ডকুমেন্টেশনের দিকে নির্দেশ করে point একটি ভিগনেট সরবরাহ করা হয়েছে ( sos::findFnফলাফলের ছকে এই তথ্যটি রাখার জন্য এই মানদণ্ডটি যথেষ্ট গুরুত্বপূর্ণ খুঁজে পেয়েছে!)? একটি ডেমো? আরও তথ্য সহ একটি ওয়েব পৃষ্ঠা? না citationএকটি সঠিক কাগজ দিতে বা বুক # 2 আপনি, আপনার কোড সহ উদাহরণ ডেটা অর্ণবপোত করতে পারে, তাই এমনকি যদি অন্য কোন বাস্তবায়ন আপনি, বিরুদ্ধে আপনার কোড পরীক্ষা করতে পারেন এখন অন্যদের পুলিশের বিরুদ্ধে তাদের বাস্তবায়ন পরীক্ষা করতে পারেন।

— সিবেলাইটস মনিকে

"আর প্রোগ্রামাররা প্রায়শই প্রয়োজন মনে করেন যে আর ব্যবহারকারীরা কৌশলটি বাস্তবায়িত হওয়ার বিষয়ে এবং ন্যূনতমভাবে নথির বিষয়ে ঠিক ততটাই জানে ...." - কোড বনামের ডকুমেন্টেশনটি বনাম পরিসংখ্যান পদ্ধতির মধ্যে পার্থক্য করা গুরুত্বপূর্ণ । আর ডকুমেন্টেশন স্ট্যাট পদ্ধতিগুলি শেখার জন্য একেবারে জায়গা নয়। এমনকি ভিগনেটস একটি নির্দিষ্ট স্তরের পরিশীলনের বিষয়টি ধরে নেন। আর-এর ন্যূনতম ডকুমেন্টেশন সম্পর্কে অনেক বেশি অভিযোগ অভিযোগ করার মতো যে ডক্সগুলি তাদের পরিসংখ্যান জ্ঞান খাওয়ানোর চামচ নয়।

— জোরান

উপবৃত্তাকার ... এর উদ্দেশ্য ছিল একপাশে একটি পলকে সিগন্যাল করা। এটি আর সম্প্রদায়ের নিজস্ব মান নির্ধারণ করার জন্য, বা কমপক্ষে তাদের বিতর্ক করার জন্য।

— নিক কক্স

Answer 2

এটি একটি গুরুত্বপূর্ণ এবং ব্যবহারিক প্রশ্ন। আসুন একটি প্যাকেজ লিখতে এবং এটি CRAN এ প্রকাশের মধ্যে পার্থক্য করে শুরু করি।

প্যাকেজ না লেখার কারণগুলি :

• ব্যয় দক্ষতা।
• অভিজ্ঞতার অভাব.

একটি আর প্যাকেজ লেখার কারণগুলি:

• লোক এবং প্ল্যাটফর্মের সাথে ভাগ করে নেওয়া।
• পরিপাটি কোড এবং কাজের প্রক্রিয়া জোর করে।
• ব্যবহারের সহজতা (এমনকি নিজের জন্যও) যখন ফাংশনগুলি জমা হতে শুরু করে।

প্যাকেজ জমা দেওয়ার কারণগুলি (সিআরএএন, বায়োকন্ডাক্টর, ...):

• সম্প্রদায়ের অবদান।
• বিতরণ সহজ।

Comments

আমি যোগ করতে চাই যে অভিজ্ঞতার অভাব একটি কারণ নেই করার একটি r- প্যাকেজ লিখুন। প্রথমবারের জন্য একটি প্যাকেজ লেখা কেবল মজাদার এবং চ্যালেঞ্জ নয়, তবে এটি আসলে 'উপযুক্ত' প্যাকেজটি কীভাবে নিজের এবং সম্প্রদায়ের জন্য উপকারী হবে তা কীভাবে ডিজাইন করা যায় সে সম্পর্কে ধারণা তৈরি করতে সহায়তা করে। অন্য কথায়, কারও কাছে অভিজ্ঞতা না থাকলেও অভিজ্ঞতা অর্জনের জন্য প্যাকেজ লেখার জন্য এটি এখনও ভাল ধারণা।

— গ্রিম ওয়ালশ

আপনার দৃষ্টিভঙ্গি, গ্রামীণ, একজন অভিজ্ঞ-অভিজ্ঞ-প্রোগ্রামারের পক্ষে যথেষ্ট অনুপ্রেরণাকারী যা কোনও প্যাকেজ ডিজাইনে যেতে দ্বিধা বোধ করবে। অন্যদিকে, যদিও এটি অবশ্যই নিজের জন্য পরিপূর্ণ হবে, আমি নোট করি যে উভয় উত্তরই জোর দিয়েছিল (এবং আমি এটিও বুঝতে পারি) একটি পরিষ্কার, দক্ষ এবং সর্বোপরি ত্রুটিমুক্ত কোডের জন্য প্রোগ্রামিং এবং বৈজ্ঞানিক প্রয়োজন। সুতরাং, এটি একটি নতুন প্রশ্নের উদ্বোধন করে যা হতে পারে "কীভাবে এটি নিশ্চিত করা যায় যে কোনও আর প্যাকেজটি ত্রুটিমুক্ত রয়েছে?", সম্ভবত এটি সম্প্রদায়ের কাজ, তবে নতুন প্যাকেজগুলির ক্রমবর্ধমান সংখ্যা এটির সীমা হতে পারে।

— জিন-ব্যাপটিস্ট ক্যাম্পগুলি

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

— গ্রিম ওয়ালশ

Answer 3

মনে রাখবেন যে বিকল্প রয়েছে # 3; আপনি কোনও প্রাসঙ্গিক প্যাকেজটির রক্ষণকারীকে আপনার কোড বা ডেটা অন্তর্ভুক্ত করতে বলতে পারেন।

Answer 4

প্যাকেজিংয়ের জন্য আমার ব্যক্তিগত ট্রিগারগুলি হ'ল:

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

• একজন সহকর্মী আমাকে কোড জিজ্ঞাসা করলেন। আমি যে কোডটি লিখি তার একটি উল্লেখযোগ্য অংশটি কমপক্ষে সহকর্মীদের অনুরোধে (যারা আর ব্যবহার করেন তবে নিজেরাই তেমন প্রোগ্রাম করেন না) as

• আমার কোড সাফ করা এবং ডকুমেন্ট করতে "বাধ্য" করতে আমি কোনও প্যাকেজ (ডকুমেন্টেশন) এর আনুষ্ঠানিক প্রয়োজনীয়তা ব্যবহার করি।

আমি @ জনরসের সাথে একমত যে প্যাকেজ লেখার এবং প্যাকেজ প্রকাশের মধ্যে বেশ পার্থক্য রয়েছে।

• আমি সাধারণত তাড়াতাড়ি প্যাকেজ করি তবে প্যাকেজটি কেবল "আধা প্রজাতন্ত্র" তৈরি করি make এটি কোনও অভ্যন্তরীণ সার্ভারে (বা আর-ফোর্জে) উপলভ্য হতে পারে, তাই আমার সহকর্মীরা প্যাকেজটি অ্যাক্সেস করতে পারে। তবে আমি প্যাকেজটি কয়েক মাস বা কয়েক বছর এমনকি ঘনিষ্ঠ সহকর্মীদের দ্বারা ব্যবহৃত হওয়ার পরে সিআরএএন-তে প্রকাশ করব। এটি @ নিক কক্সের পয়েন্ট # 3 অনুসারে সমস্ত ত্রুটি আনবে না, তবে এগুলির একটি মোটামুটি পরিমাণ।
  প্যাকেজের সংস্করণগুলি (আমি সংস্করণ নম্বরটিতে ড্যাশের পরে তারিখটি রেখেছি) জিনিসগুলি ঠিক করা সহজ করে তোলে ("এটি করার জন্য এবং এটি, আপনি অন্তত গত সপ্তাহের সংস্করণটি অন্তর্নিহিত করেছেন তা নিশ্চিত করুন")

• আমার কাজের চুক্তি অনুসারে, কোনও প্যাকেজ বাইরের বিশ্বের কাছে প্রকাশিত হতে পারে কি না এবং সেই সিদ্ধান্তের বিষয়ে আমার নিয়োগকর্তার শেষ কথা রয়েছে।

জিনিস যেখানে আমি না এখনো প্যাকেজিং জন্য একটি ভাল কৌশল আছে তথ্য।

---

আপনার কারণগুলির তালিকাতে মন্তব্যগুলি:

• একই উপ-ক্ষেত্রের অন্যান্য প্যাকেজগুলির অস্তিত্ব;

এমন একটি প্যাকেজ সন্ধান করা হচ্ছে না যা কোড কোডটি লেখার জন্য আমার প্রয়োজন হয় , তবে এটি প্যাকেজ করবে কি না সে সিদ্ধান্তের সাথে এটি করার দরকার নেই।

• অন্যান্য গবেষকদের সাথে মতবিনিময় এবং পরীক্ষার পুনরুত্পাদনযোগ্যতার অনুমতি দেওয়ার প্রয়োজন;

নিশ্চিতভাবেই। সম্ভবত আমি ইতিমধ্যে ব্যবহার করা বেশ কয়েকটি কম্পিউটারের মধ্যে ভাগ করে নেওয়ার প্রয়োজন।

এবং বিপরীতে সিদ্ধান্ত গ্রহণ করতে পারে যে পয়েন্টগুলির মধ্যে:

• অন্যান্য প্যাকেজের মধ্যে ইতিমধ্যে ব্যবহৃত পদ্ধতির অংশ;

আপনি আপনার প্যাকেজ / কোডে এই পদ্ধতিগুলি আমদানি করতে পারেন: এটি এই জাতীয় কোড লেখার বিরুদ্ধে একটি বিষয় , তবে প্যাকেজিংয়ের সাথে কেবল পরোক্ষভাবে তা করতে পারে।

• একটি নতুন স্বতন্ত্র প্যাকেজ তৈরির পক্ষে ন্যায্যতা প্রমাণ করতে যথেষ্ট নতুন কর্মের সংখ্যা।

আমার জন্য, প্যাকেজ শুরু করার জন্য কোনও ন্যূনতম সংখ্যা নেই functions আমার অভিজ্ঞতায় প্যাকেজগুলি "স্বয়ংক্রিয়ভাবে" বাড়তে থাকে। বিপরীতে, আমি নিজেকে কয়েকবার অন্যের বাইরে একটি নতুন প্যাকেজটি শাখা বন্ধ করার পরে খুঁজে পেয়েছি (কারণ উদাহরণস্বরূপ কিছু সহায়ক ফাংশন থিম্যাটিকভাবে ভিন্ন এবং অন্যান্য পরিস্থিতিতেও কার্যকর হতে দেখা গেছে), আমি এখন বরং অবিলম্বে নতুন প্যাকেজ তৈরি।

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

Comments

+1 টি। প্যাকেজগুলি আধা-জনসাধারণ করার আরও একটি ভাল উপায় হ'ল প্যাকেজ উত্সটি গিটহাবের উপরে স্থাপন করা - এটি কোডটি সন্ধান করা আরও সহজ করে তোলে এবং CRAN- এ কোনও প্যাকেজের অন্তর্ভুক্ত পোলিশ ছাড়াই অন্যকে অবদান রাখতে উত্সাহিত করে।

— ম্যাট পার্কার

Answer 5

আমি যখনই আর-তে অনুরূপ কাজগুলির একটি বৃহত্তর সেট করে যাচ্ছি তখনই একটি প্যাকেজ তৈরি করতে বলব যে আপনি এমন একটি প্যাকেজ থেকে উপকৃত হবেন যেটিতে আপনি কোনও নামস্থানে জিনিস রাখতে পারবেন (একইভাবে নামযুক্ত ক্রিয়াকলাপগুলির সাথে দ্বন্দ্ব এড়াতে), যেখানে আপনি লিখতে পারেন ডকুমেন্টেশন। এমনকি গিথুবে একটি প্যাকেজ রয়েছে যা সম্পর্কিত নয় এমন একটি ফাংশন গ্র্যাব ব্যাগ বান্ডিল করার জন্য, তবে আমি প্রায়শই এটি ব্যবহার করি যে আমি ভেবেছিলাম যে তারা ডকুমেন্টেশন, ম্যান ফাইলস ইত্যাদি প্রাপ্য served

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

আমি যে তিনটি সরঞ্জাম বলি তা গুরুত্বপূর্ণ:

• devtools pkg , প্যাকেজগুলি তৈরি করা অত্যন্ত সহজ করার জন্য (ডেভটোলস গিথুব পৃষ্ঠাগুলিতে উইকিও দেখুন
• আপনার প্যাকেজটির জন্য ডকুমেন্টেশন রাইটিং সহজ করার জন্য roক্স22 pkg
• গিটহাব, আপনি install_githubগিটহাব থেকে সরাসরি ইনস্টল করতে (বা একইভাবে ইনস্টল_বিটবকেট ইত্যাদি) ব্যবহার করতে পারেন যা অন্যের সাথে ভাগ করে নেওয়ার জন্য দুর্দান্ত।

Answer 6

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

আর-প্যাকেজ লেখার জন্য নির্দিষ্ট কারণ:

• কারণ আপনি সি লিখেন

আপনি যে সময় সি, সি ++ বা ফরট্রান (বেশিরভাগ উচ্চ পারফরম্যান্স কম্পিউটিংয়ের জন্য) হিসাবে বিদেশী ভাষা ব্যবহার করেন না কেন প্যাকেজ লিখতে সমস্যাটি বেশিরভাগ ক্ষেত্রেই মূল্যবান। আপনার যদি এক বা দুটিরও বেশি ফাংশন থাকে, আপনি খুব দ্রুত সমস্ত স্থান এবং R এবং C কোডের মধ্যে নির্ভরতাগুলি বজায় রাখা এবং বন্দর বজায় রাখার মধ্যে জটিলতার সাথে শেষ করে ফেলবেন।

Answer 7

অন্যান্য দুর্দান্ত উত্তরে উল্লেখ না করার একটি কারণ: আপনার কাছে একটি বৃহত বা জটিল ডেটা বিশ্লেষণ প্রকল্প রয়েছে। প্যাকেজিং, প্রথমে, প্যাকেজ হিসাবে ডেটা এবং তারপরে নির্দিষ্ট বিশ্লেষণগুলি রূপান্তর, প্লট করা বা গণনা করার জন্য দরকারী ফাংশনগুলির সাথে প্রসারিত। এইভাবে আপনি রিপোর্ট করা বিশ্লেষণ গণনা করতে ব্যবহৃত সমস্ত ফাংশন সমেত ডেটার একটি ডকুমেন্টেড সংস্করণ পান version তারপরে প্রকল্প থেকে প্রাপ্ত প্রতিবেদন (গুলি) প্রজননযোগ্য গবেষণার জন্য নিটার বা অন্যান্য প্যাকেজ ব্যবহার করে লেখা যেতে পারে!

এটি কিছুটা পুনরায় বিশ্লেষণ করতে হলে তা উল্লেখযোগ্যভাবে সময় সাশ্রয় করতে পারে বা বিশ্লেষণ প্রকাশিত হলে এটি প্রকাশিত (বা সেমিপ্রকাশিত )ও হতে পারে।