ওপেন সোর্স প্রকল্পগুলি কীভাবে তাদের নকশা বা আর্কিটেকচার সম্পর্কে দলিল ছাড়াই সফল হতে পারে?

Question

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

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

সুতরাং আমি ভাবতে শুরু করেছি: নতুন-আগত বিকাশকারীদের যদি পড়ার মতো কোনও স্থাপত্য / নকশার ডকুমেন্টেশন না থাকে বা প্রকল্প পরিচালক যদি কেবল উত্স কোডটি খোলেন তবে এর ডকুমেন্টেশন বন্ধ করে দিয়েছেন তবে ওপেন সোর্স প্রকল্পটি কীভাবে সফল হতে পারে?

Comments

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

— এসলট

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

— টমক্যাপস

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

— এসলট

আমার সন্দেহ হয় যে ASP.NET MVC- এ ইউএমএল ডায়াগ্রাম অন্তর্ভুক্ত না করার কারণ ভিজুয়াল স্টুডিওগুলি উত্স কোড থেকে এগুলি তৈরি করতে পারে।

— ব্যবহারকারী16764

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

— o11c

Answer 1

নতুন আগত বিকাশকারীদের যদি কোনও স্থাপত্য / নকশার ডকুমেন্ট পড়ার জন্য না থাকে তবে ওপেন সোর্স প্রকল্পটি কেন সফল হতে পারে?

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

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

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

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

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

Comments

যদিও আপনি মেইলিং তালিকার দিকে নজর দিলে লিনাক্স কার্নেলের আর্কিটেকচার সম্পর্কে যখনই কারও সমস্যা হয় বা কিছু পরিবর্তন করতে ইচ্ছুক তার সম্পর্কে বিস্তর আলোচনা হয়। এটি সম্পর্কে বেশ কয়েকটি নথি লিখিত রয়েছে - যদিও এটি কার্নেল উত্স ট্রিতে নেই।

— এডিএ-কিএ মর্ট-ওরা-y

Answer 2

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

Comments

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

— টমক্যাপস

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

— জেফ ওয়েলিং

@TomCaps: এই পদ্ধতি সবচেয়ে কোম্পানীর জন্য অস্বাভাবিক যে, আমি জানি ...

— Treb

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

— এলিন

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

— জেমস অ্যান্ডারসন

Answer 3

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

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

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

Answer 4

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

মূলত ডকুমেন্টেশন লেখা মজাদার নয়। এবং যদি তারা এর জন্য অর্থ পাচ্ছে না, তবে কে তাদের ফ্রি সময়টি এমন কিছু করে ব্যয় করতে চায় যাতে মজা হয় না?

Comments

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

— বেসাইল স্টারিনকিভিচ