ওপেন-সোর্স প্রকল্পগুলির জন্য কোড ওভারভিউ কেন নেই? [বন্ধ]


60

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

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

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

তবে এখনও আমি এই "কোড ওভারভিউগুলি" এর মধ্যে একটিও দেখিনি। কেন? এই মত জিনিস আছে এবং আমি সেগুলি মিস করছি? যে জিনিসগুলি আমি বর্ণনা করছি একই কাজ করে? বা এটি কি সম্পূর্ণরূপে অকেজো ধারণা, আমার ব্যতীত প্রত্যেকে হাজার হাজার কোডের কোড সহ প্রকল্পগুলি সহজেই বুঝতে পারে?


7
আপনি একটি ডিজাইন নথি বলতে চাচ্ছেন? আমি প্রতিটি প্যাকেজের বিবরণ সহ বিরল প্রকল্পটি দেখেছি তবে এটি ইতিমধ্যে ইতিমধ্যে একটি এপিআই।
রাচেট ফ্রিক 18

14
কেন? কারণ এমন কয়েকটি প্রকল্প রয়েছে যার রক্ষণাবেক্ষণকারীরা উচ্চমানের ডকুমেন্টেশন লিখতে এবং বজায় রাখার প্রচেষ্টাটি বিনিয়োগ করতে চান এবং প্রায়শই তারা সুবিধাগুলি বুঝতে পারেন না।
অ্যালেক্স

9
ডকুমেন্টেশন সত্যিকারের আচরণের সাথে তুলনায় পুরানো বা ভুল হতে পারে। কোড পারে না। সুতরাং বেশিরভাগ প্রকল্প কোড পছন্দ করে।
পল

5
এছাড়াও আপনি যদি 2 ঘন্টা বা তার জন্য একটি রান্নাঘরের টাইমার সেট করেন এবং জাস্ট রিড ইট (টিএম) রাখেন তবে কোনও প্রকল্প সম্পর্কে আপনি কতটুকু শিখতে পারবেন তা অনুমান করা সহজ।
কোস

43
সম্প্রদায়-পরিচালিত বিশ্বে আপনাকে স্বাগতম: যদি এটি সম্পন্ন না হয় তবে এটি আপনি করেননি কারণ :)
mgarciaisaia

উত্তর:


60

কারণ এ জাতীয় দলিল তৈরি এবং রক্ষণাবেক্ষণের জন্য এটি অতিরিক্ত প্রচেষ্টা এবং খুব বেশি লোক সম্পর্কিত বেনিফিট বুঝতে পারে না।

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

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


6
ঠিক আছে, মনে হচ্ছে উত্তরটি হ্যাঁ: gnunet.org/gnunet-source-overview
fiatjaf

5
আপনি যদি এটির অস্তিত্ব চান তবে এটি লিখতে স্বেচ্ছাসেবক। ওপেন-সোর্স প্রকল্পগুলির পুরো বিষয়টি হ'ল লোকেরা যা করতে পারে তা অবদান রাখতে পারে এবং তা করা উচিত, এটি সম্প্রদায়ের সম্মতিতে যে এটি সংহত করার উপযুক্ত।
কেশলাম

8
@ কেশলাম - যদি আপনি ইতিমধ্যে এই প্রকল্পের একজন সহযোগী হয়ে থাকেন তবে তা বোঝা যায় ... তবে আপনি যদি এমন কোনও সম্ভাব্য অবদানকারী যিনি কোডটি কীভাবে কাজ করে সে সম্পর্কে প্রাথমিক ধারণা পেতে চেষ্টা করছেন তবে আপনি লিখতে সবচেয়ে খারাপ ব্যক্তি person সেই দস্তাবেজ ....
জন গল্প

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

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

14

শুকনো, কঠোর সত্য?

ডকুমেন্টেশন তৈরি হয় না কারণ প্রকল্পগুলি এগুলি ছাড়া করতে পারে।

এমনকি ওপেন সোর্স প্রকল্পগুলি প্রায়শই কঠোর প্রতিযোগিতার মুখোমুখি হয়। এ জাতীয় বেশিরভাগ প্রকল্প বড় কাঁধ দিয়ে শুরু হয় না, তারা একটি উজ্জ্বল ধারণাটি শুরু করে, প্রায়শই এক ব্যক্তি উজ্জ্বল ধারণা।

এই হিসাবে, তারা নিখরচায় সহযোগিতা করার প্রস্তাব দিলেও, মানব ডকুমেন্টারদের নিয়োগের সময় এবং ব্যয় বহন করতে পারে না। একটি ডকুমেন্টেড প্রজেক্ট, ইনফ্যাক্ট, সাধারণত প্রথমে বেশ কয়েকটি শুরুর পুনরাবৃত্তির মধ্য দিয়ে যায়। এটি প্রায়শই 1-3- এর সাথে শুরু হয়, সম্ভবত 5 জন তাদের অভিনব ধারণাটি লিখে এবং ধারণার প্রমাণ হিসাবে এটি বিশ্বকে দেখায়। যদি ধারণাটি প্রমাণিত হয় তবে "অনুসারীরা" যুক্ত করতে পারেন, তারা এক্সটেনশান, নতুন বিকল্প, অনুবাদ জিজ্ঞাসা করতে শুরু করেন ... এই মুহুর্তে কোডটি এখনও একটি প্রোটোটাইপ, সাধারণত হার্ড কোডিং বিকল্প এবং বার্তা সহ।

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

তারপরেও, প্রকল্প পরিচালক ডকুমেন্টেশন তৈরি না করার বিকল্প বেছে নিতে পারেন।

একটি গতিশীল, বর্ধমান প্রকল্প উভয়ই ধীর হয়ে যাবে এবং ডকুমেন্টেশন কোডটির পিছনে সত্যই পিছিয়ে থাকবে যখন অনুবাদগুলি, বিকল্পগুলি, ম্যানেজারগুলিতে প্লাগ ইন করতে ...

সাধারণত যা ঘটে তা হ'ল:

  1. প্রকল্পটি কী এবং এটি কোথায় চলছে (বিখ্যাত "রোডম্যাপ") সম্পর্কে একটি সংক্ষিপ্ত পরিচিতি দলিল তৈরি করা হয়।
  2. যদি সম্ভব হয় তবে একটি এআইপি বিকাশ করা হয়েছে এবং অন্তর্নিহিত কোডের বেশিরভাগ অংশে একটি "ডকুমেন্টেড কোড" হিসাবে নির্বাচিত হয়।
  3. বিশেষত এপিআই তবে অন্যান্য কোডগুলিও পুনরায় ফর্ম্যাট করা হয় এবং "পিএইচপিডোক" / "জাভাদোক" ইত্যাদি বিশেষ মন্তব্য যুক্ত করা হয়। তারা ব্যয় করা সময় এবং পুরষ্কারের মধ্যে একটি শালীন সমঝোতার প্রস্তাব দেয়: এমনকি একজন পরিমিত প্রোগ্রামার সাধারণত জানেন যে কীভাবে একটি লাইনার তার ফাংশনগুলি বর্ণনা করতে পারে, পরামিতিগুলি "অটো" নথিও পেয়ে যায় এবং পুরোটি তার সম্পর্কিত কোডের সাথে আবদ্ধ থাকে এবং সুতরাং তারা ডকুমেন্টেশন এড়ায় " desycing "এবং পিছনে থাকা উন্নয়ন বিকাশ।
  4. প্রায়শই, একটি ফোরাম তৈরি হয়। এটি একটি শক্তিশালী সোশ্যাল মিডিয়া যেখানে শেষ ব্যবহারকারী এবং প্রোগ্রামাররা একে অপরের সাথে কথা বলতে পারে (এবং তাদের সমবয়সীদের মধ্যে সম্ভবত সম্ভবত "কেবলমাত্র ডিভল" সাবফোরামগুলিতে)। এটি ধীরে ধীরে জ্ঞানকে ধীরে ধীরে উত্থিত হতে এবং সম্প্রদায়ের তৈরি সংস্থাগুলি দ্বারা উত্থাপিত হতে দেয় (পড়ুন: বিকাশকারী দলের উপরে ওজন না করা) এফএকিউ এবং হাওটো।
  5. সত্যই বড় প্রকল্পগুলিতে একটি উইকিও উত্পাদিত হয়। আমি "বড় প্রকল্পগুলি" বর্ণনা করি কারণ তারা প্রায়শই পর্যাপ্ত অনুগামীদের সাথে উইকি তৈরি করতে সক্ষম হয় (কোনও দেবই করে) এবং তারপরে আসলে এটি "খালি হাড়" (সম্প্রদায়টি করে) এর বাইরে পূরণ করে।

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

6
+1, আমি আপনার প্রায় সমস্ত পয়েন্টের সাথে একমত, কেবলমাত্র বিবৃতিটি আমি দৃ strongly়ভাবে প্রত্যাখ্যান করে তা হ'ল প্যারামিটারগুলি "অটো" নথিভুক্ত হয় । যখন আমরা নিছক বাক্য গঠন / ধরণের প্রতিবন্ধকতাগুলির পরিবর্তে ব্যাখ্যাগুলি বিবেচনা করি তখন কিছুই "স্বয়ং-ডকুমেন্টেড" হয় না; শৈলীতে একটি উত্পন্ন মন্তব্য এক্সকে রিটার্ন করে একটি গেটএক্স পদ্ধতির জন্য সহায়ক ডকুমেন্টেশন নয়, এটি কোনও অতিরিক্ত তথ্য ছাড়াই কেবল একটি ফিলার।
বা ম্যাপার

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

এই প্রকল্পগুলি নথি না দেওয়ার কারণে এটি কি ব্যর্থ হয়? এবং দস্তাবেজ দ্বারা, আমি পরিকল্পনা বলতে চাইছি, যাতে আপনি কী-বোর্ডে বসে বসে পাউন্ড না করে বোঝেন। এখানে একটি প্রকল্প জীবনচক্রের জন্য আমার অনুমান, সমস্ত পরিসংখ্যান +/- 5%। সামনের জিনিসপত্র (প্রয়োজনীয়তা এবং ব্যবহারের ক্ষেত্রে, আর্কিটেকচার, বিস্তারিত নকশা) 50%, কোডিং 10 থেকে 15%, পরীক্ষা, বাকি। "আপনি যদি পরিকল্পনা করতে ব্যর্থ হন তবে আপনি ব্যর্থ হওয়ার পরিকল্পনা করছেন"
মগ

6

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

যে কোনও সুগঠিত প্রকল্পে একটি ডিরেক্টরি ট্রি থাকবে যা তুলনামূলকভাবে স্ব-বর্ণনামূলক। কিছু প্রকল্প এই শ্রেণিবিন্যাস এবং / অথবা এটি যে কারণে বেছে নেওয়া হয়েছিল তা নথিভুক্ত করবে। অনেক প্রকল্প অপেক্ষাকৃত স্ট্যান্ডার্ড কোড লেআউটগুলি অনুসরণ করে, সুতরাং আপনি যদি একটি বুঝতে পারেন তবে একই প্রকল্পটি ব্যবহার করে অন্যান্য প্রকল্পগুলির বিন্যাস বুঝতে পারবেন।

কোডের একটি লাইন পরিবর্তন করতে আপনার চারপাশের কোডের একটি সীমিত ধারণা দরকার। এটি করার জন্য আপনাকে কখনই পুরো কোড বেসটি বুঝতে হবে না। আপনার যদি ভাঙ্গা ধরণের কার্যকারিতা সম্পর্কে যুক্তিসঙ্গত ধারণা থাকে তবে প্রায়শই ডিরেক্টরি শ্রেণিবিন্যাসের পরিবর্তে দ্রুত নেভিগেট করা সম্ভব।

কোডের একটি লাইন পরিবর্তন করতে আপনার লাইনটি খুঁজে পাওয়া যায় সেই পদ্ধতিটি বুঝতে হবে। আপনি যদি পদ্ধতির প্রত্যাশিত আচরণটি বুঝতে পারেন তবে আপনার কার্যকারিতাটিতে সংশোধনমূলক পরিবর্তন করতে বা এক্সটেনশানগুলি করতে সক্ষম হওয়া উচিত।

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

এই জাতীয় পরিবর্তনগুলি কীভাবে করা যায় তার উদাহরণের জন্য আমার নিবন্ধটি টিনিকায় SHA-2 যুক্ত করে দেখুন । ইন্টারফেস উত্পন্ন করতে ব্যবহৃত কোড সম্পর্কে আমার কাছে অত্যন্ত সীমিত ধারণা রয়েছে।


1
এখানে গুরুত্বপূর্ণ বিষয়টি পরিবর্তন করার জন্য কোড সম্পর্কে আপনার কতটা জানতে হবে তা জোর দেওয়া হয়নি। অবশ্যই এটি অনেক কিছুর উপর নির্ভর করবে, তবে আপনাকে কখনই পুরো কোডটি বোঝার দরকার পড়বে না, কোনও সংক্ষিপ্ত বিবরণ আপনাকে সেই উপলব্ধি দেবে না, এমনকি কোডের লাইনটি সন্ধান করতেও আপনাকে একটি নির্দিষ্ট জ্ঞানের প্রয়োজন হবে সাধারণ প্রকল্প কাঠামো।
fiatjaf

+1 ওপেন সোর্স সম্পর্কে বিশেষ কিছু নেই। শিল্পে কাজ করার আমার 10 বছরেরও বেশি অভিজ্ঞতায় আমি কখনই ওভারভিউ ডকুমেন্টটি দেখিনি। সাধারণত যা হয় তা হ'ল নিয়োগকর্তারা আপনার কর্মসংস্থানের প্রথম মাসের শূন্য উত্পাদনশীলতা অর্জনের প্রত্যাশা করেন কারণ আপনি কোডবেস অধ্যয়ন করছেন। "ওভারভিউ" সাধারণত আপনার সহকর্মীদের প্রশ্ন জিজ্ঞাসা হিসাবে প্রয়োগ করা হয়
স্ল্যাবটম্যান

5

এই মত জিনিস আছে এবং আমি সেগুলি মিস করছি? যে জিনিসগুলি আমি বর্ণনা করছি একই কাজ করে?

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


এটি আরও একটি মন্তব্যের মতো পড়ে, কীভাবে উত্তর দিতে হয় দেখুন
gnat

4
আপনার মন্তব্যটি আমি গঠনমূলক মনে করি না। বিশেষত, আপনার কি অভাব হচ্ছে বলে মনে হয়? এখানে অন্যান্য উত্তরগুলির মধ্যে অনেকগুলি সম্ভাব্য কারণ সম্পর্কে দীর্ঘ জল্পনা রয়েছে যা বিকাশকারীরা ওভারভিউ ডকুমেন্টেশন না লিখতে পারে। আমি ভাল ওভারভিউ নথিগুলির একটি নির্দিষ্ট উদাহরণের সাথে লিঙ্ক করেছি।
বিজেএমসি

1
আমি মনে করি জিজ্ঞাসা করা প্রশ্নের উত্তরটির অভাব রয়েছে, "ওপেন-সোর্স প্রকল্পগুলির জন্য কোড ওভারভিউ কেন নেই?"
gnat

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

1
লিখিত হিসাবে প্রশ্নটি জিজ্ঞাসা করে "এই জাতীয় জিনিসগুলি কি আছে এবং আমি সেগুলি মিস করছি?" এই উত্তরটি এরূপ কোড ওভারভিউয়ের বিদ্যমান সংকলনের দিকে ইঙ্গিত করে যথাযথভাবে সাড়া দেয়। যেমন আমি মনে করি এটি প্রশ্নের একটি দুর্দান্ত (এবং উপযুক্ত) উত্তর।
জিম গ্যারিসন

4

কারণ ওপেন সোর্স প্রযুক্তিবিদদের চেয়ে অনেক বেশি ওপেন সোর্স প্রোগ্রামার রয়েছে।

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

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

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

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

তবে সাফল্যের মতো কিছুই বিক্রি হয় না: এমন একটি প্রকল্প যা কাজ করছে না বা আকর্ষণীয় কিছু করছে না এমনটি খুব কমই বিকাশকারীদের আকর্ষণ করে।

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

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

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


+1 "ডকুমেন্টেশন সহজেই কোডটি প্রথম স্থানে লিখতে পারে" - বা আরও দীর্ঘ!
মার্কো

-1

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

কেবলমাত্র একটি জনপ্রিয় নামকরণের জন্য: ব্লুজ ভাগ্য ভাল কাছাকাছি ডিভাইসগুলির জন্য স্ক্যান করার জন্য একটি ভাল টিউটোরিয়াল সন্ধান করুন।


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

@ ওরম্পার "ব্লুজ - দুর্দান্ততম লিনাক্স রহস্য" দিয়ে শুরু করুন । লিনাক্সের একমাত্র ব্লুটুথ গ্রন্থাগার হিসাবে, এটি বিশ্বাস করা আমার পক্ষে কঠিন যে এটি ডকুমেন্টেশন হিসাবে নয় কারণ এটি একটি অতিরিক্ত প্রচেষ্টা। হেল, সেখানে অক্সিজেন রয়েছে, এবং সহজ টিউটোরিয়াল লিখতে কতটা কঠিন?
BЈовић

@ ORMapper তারপরে লিনাক্স কার্নেল রয়েছে। আপনি যদি কোনও কিছু হারিয়ে ফেলেন (কার্নেল ড্রাইভারের মতো), যদি আপনার সংস্থা দক্ষতা হারিয়ে ফেলছে তবে আপনি হয় কাউকে নিয়োগ দিতে পারেন, বা কোনও ফ্রিল্যান্সার বা কোনও সংস্থা খুঁজে পেতে পারেন যা এটি আপনার জন্য করবে। সুতরাং, এটি ওপেন সোর্স, তবে এটি একটি দাম নিয়ে আসছে
BЈовић

@ ওরম্পার এরপরে কাগজের ফর্ম্যাটে ডকুমেন্টেশন সহ ওপেন সোর্স প্রকল্প রয়েছে। সুতরাং আপনি একটি বই কিনেছেন, এবং অন্য কোনও ডকুমেন্টেশন নেই। এই ডকুমেন্টেশন পঙ্গু, না?
BЈовић

2
এটি মূল্যবান কিসের জন্য, আমি কমপক্ষে এটি উদ্দেশ্যমূলক কিনা তা অবাক করার জন্য নোংরা ডকুমেন্টেশনগুলি যথেষ্ট লাভজনক দেখেছি seen অর্ধ-অ্যাসেসড ডকুমেন্টেশন অনলাইনে থাকা একই গোষ্ঠীগুলি যখন আপনাকে একটি বই বা একটি প্রশিক্ষণ ক্লাস বিক্রি করে বেশি খুশি করে, তখন এই সিদ্ধান্তে পৌঁছাতে মোটেও নিন্দা লাগে না।
সিএওও
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.