আমাদের পেশায়, একটি অপরিচিত কোডবেসে কাজ করা সাধারণ। এটি প্রতিবারই ঘটে যখন কেউ একটি নতুন প্রকল্পে যোগ দেয় বা এমনকি বড় প্রকল্পে পূর্বে অস্পৃশ্য অংশে কাজ করার প্রয়োজন হয়৷
এই ঘটনাটি শুধুমাত্র একজন ডেভেলপারকে একটি বাগ সংশোধন করার জন্য সীমাবদ্ধ নয়; এটি একটি সমাধান আর্কিটেক্ট হতে পারে যা একটি নতুন বৈশিষ্ট্য ডিজাইন করতে পারে বা একটি ওপেনসোর্স অবদানকারী তাদের অবসর সময়ে একটি গিটহাব সমস্যা নিয়ে কাজ করে। তাই, আমি বর্ণনা করতে চাই কিভাবে আমি পরিস্থিতির সাথে যোগাযোগ করি যাতে এটি অন্যদের উপকার করতে পারে।
আমার পয়েন্ট ব্যাখ্যা করার জন্য, আমি একটি ওপেন সোর্স প্রকল্পে একটি নতুন বৈশিষ্ট্যের অনুরোধ করার জন্য একটি সাধারণ GitHub সমস্যা ব্যবহার করব।
হ্যাজেলকাস্টের জন্য কাজ করার সময়, হ্যাকাথনে কাজ করার জন্য আমি নিয়মিত তথাকথিত "ভাল প্রথম সমস্যা" স্ক্যান করেছি। আমি কখনই এমন হ্যাকাথন চালাতে পারিনি, তবে এটি বিন্দুর পাশে। আমার ধারণা ছিল ওপেন সোর্সে অবদান রাখতে আগ্রহী ব্যক্তিদের কোড বেসের সাথে পরিচিত হতে সাহায্য করা।
সেই সময়ে, আমি এই আকর্ষণীয় সমস্যাটি খুঁজে পেয়েছি:
getQuiet অপারেশনের জন্য সমর্থন যোগ করুন http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#getQuiet(java.lang.Object) ?
ধারণাটি এটি স্পর্শ না করে একটি এন্ট্রি পেতে সক্ষম হবেন, যার অর্থ এটি সর্বশেষ অ্যাক্সেস করা টাইম স্ট্যাম্প আপডেট করবে না।
এটির পিছনে ব্যবহারের ক্ষেত্রে সেই কীটির উচ্ছেদ পরিবর্তন না করে একটি কীটির অস্তিত্ব পর্যবেক্ষণ করতে সক্ষম হওয়া।
-- বিতরণ করা মানচিত্র: getQuiet অপারেশনের জন্য সমর্থন যোগ করুন
একজন ওপেনসোর্স কন্ট্রিবিউটর হিসেবে, আমি কিভাবে কাজটির সাথে যোগাযোগ করব?
ডকুমেন্টেশন একটি নতুন প্রকল্প শুরু করার প্রথম ধাপ। একটি নিয়মিত প্রকল্পে, ডকুমেন্টেশন সম্ভবত অনুপস্থিত, অসম্পূর্ণ বা আংশিকভাবে (যদি সম্পূর্ণ না হয়) বিভ্রান্তিকর হবে; একটি হ্যাকাথনে, এটি বিস্তারিতভাবে পড়ার জন্য সময় খুব কম হতে পারে।
সফল ওপেন সোর্স প্রকল্পে সাধারণভাবে ভালো ডকুমেন্টেশন থাকে। যাইহোক, ডকুমেন্টেশন প্রধানত ব্যবহারকারীদের দিকে ভিত্তিক, খুব কমই ডেভেলপারদের দিকে। এমনকি যখন এটি হয়, ডকুমেন্টেশন সমস্যাটির সমাধান করার সম্ভাবনা কম।
এই কারণে, আমার এন্ট্রি পয়েন্ট একটি ডায়াগ্রাম আঁকা হয়. মনে রাখবেন যে কিছু সরঞ্জাম প্রকৌশলী কোড বিপরীত করতে পারে এবং স্বয়ংক্রিয়ভাবে ডায়াগ্রাম আঁকতে পারে, আমি সেগুলি উদ্দেশ্যমূলকভাবে ব্যবহার করি না। ম্যানুয়ালি একটি ডায়াগ্রাম আঁকার স্বয়ংক্রিয়ভাবে উত্পন্ন একটি থেকে অনেক সুবিধা রয়েছে:
সমস্যার জন্য কোডের জন্য একটি ডায়াগ্রাম তৈরি করা যাক। প্রথমত, আমরা আমাদের প্রিয় IDE-তে এটি খুলতে স্থানীয়ভাবে রেপো ক্লোন করব; শুধুমাত্র প্রয়োজনীয় বৈশিষ্ট্য হল যে যখন কেউ একটি মেথড কলে ক্লিক করে, তখন একজনকে পদ্ধতিতে নির্দেশিত করা হয়।
ডায়াগ্রামের জন্য, আমাকে সেকেলে বলুন, তবে আমি এখনও দুটি কারণে UML সিকোয়েন্স ডায়াগ্রামের পক্ষে:
আর কোন আড্ডা ছাড়াই, এটি এখানে:
চিত্রটি আঁকার পরে, আমরা সমস্যাটি কোথায় তা খুব দ্রুত সনাক্ত করতে পারি:
public abstract class AbstractCacheRecordStore<R extends CacheRecord, CRM extends SampleableCacheRecordMap<Data, R>> implements ICacheRecordStore, EvictionListener<Data, R> { protected long onRecordAccess(Data key, R record, ExpiryPolicy expiryPolicy, long now) { record.setAccessTime(now); // 1 record.incrementAccessHit(); return updateAccessDuration(key, record, expiryPolicy, now); } //... }
DefaultRecordStore
Record
পড়ে, যা শেষ অ্যাক্সেস সময়ের আপডেটকে ট্রিগার করে।
সমস্যা সমাধান করা এই পোস্টের সুযোগের বাইরে। এটি সর্বোত্তম সমাধান বিকাশের জন্য সামগ্রিক নকশার সাথে আরও পরিচিত লোকেদের সাথে কথা বলা জড়িত। হ্যাকাথনে একটি ভাল পদ্ধতি হল প্রথমে কমপক্ষে দুটি বিকল্প অফার করা এবং তাদের নিজ নিজ ট্রেড-অফ নথিভুক্ত করা।
টুলিংয়ের জন্য, প্রচুর বিকল্প উপলব্ধ। আমার পছন্দগুলি PlantUML- এ যায়:
একজনের সঠিক প্রযুক্তিগত ভূমিকা নির্বিশেষে একটি বিদ্যমান কোডবেস বোঝা একটি গুরুত্বপূর্ণ দক্ষতা। ডকুমেন্টেশনের অতিরিক্ত সুবিধা সহ একটি ডায়াগ্রাম তৈরি করা এই লক্ষ্যের দিকে অনেক দূর এগিয়ে যায়।
আমি ইউএমএল ডায়াগ্রাম পছন্দ করি কারণ আমি তাদের সাথে পরিচিত, এবং তারা শেয়ার করা শব্দার্থ অফার করে।
সুতরাং, আপনি যদি একটি কোডবেসকে আরও ভালভাবে বুঝতে চান, তবে আপনার কেবলমাত্র এর কোড পড়ার চেয়ে আরও বেশি কিছু প্রয়োজন; আপনাকে ডায়াগ্রাম আঁকতে হবে।
মূলত 14 মে, 2023-এ A Java Geek এ প্রকাশিত