বাগ খুঁজে বের করার জন্য এটি ব্যবহার করার পরিবর্তে প্রক্রিয়াটিতে স্ট্যাটিক বিশ্লেষণ প্রয়োগ করুন

স্থির বিশ্লেষণে ক্রমবর্ধমানভাবে আমার নজরে আসা প্রচুর পরিমাণে উপকরণ দ্বারা এই নিবন্ধটি লেখার জন্য আমাকে অনুরোধ করা হয়েছিল। প্রথমত, এই পিভিএস-স্টুডিও ব্লগ, যেটি ওপেন সোর্স প্রকল্পে তাদের টুল দ্বারা পাওয়া ত্রুটির পর্যালোচনার সাহায্যে সক্রিয়ভাবে Habré-এ নিজেকে প্রচার করে। সম্প্রতি PVS-studio বাস্তবায়িত হয়েছে জাভা সমর্থন, এবং, অবশ্যই, IntelliJ IDEA এর বিকাশকারীরা, যাদের অন্তর্নির্মিত বিশ্লেষক সম্ভবত জাভা আজকের জন্য সবচেয়ে উন্নত, দূরে থাকতে পারেনি.

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

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

র্যাচেট (সূত্র: উইকিপিডিয়া).

স্ট্যাটিক অ্যানালাইজাররা যা করতে পারে না

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

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

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

স্ট্যাটিক বিশ্লেষণ বাগ খোঁজার বিষয়ে নয়

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

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

এর মানে কি স্ট্যাটিক বিশ্লেষণ ব্যবহার করা উচিত নয়? অবশ্যই না! এবং ঠিক একই কারণে যে প্রতিটি নতুন পাসওয়ার্ড "সহজ" পাসওয়ার্ডের স্টপ লিস্টে অন্তর্ভুক্ত করা হয়েছে তা নিশ্চিত করার জন্য এটি পরীক্ষা করা মূল্যবান।

স্ট্যাটিক বিশ্লেষণ বাগ খোঁজার চেয়ে বেশি

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

• শব্দের বিস্তৃত অর্থে কোডিং শৈলী পরীক্ষা করা হচ্ছে। এর মধ্যে রয়েছে ফরম্যাটিং পরীক্ষা করা, খালি/অতিরিক্ত বন্ধনীর ব্যবহার খোঁজা, লাইনের সংখ্যা/কোন পদ্ধতির সাইক্লোম্যাটিক জটিলতা ইত্যাদির মতো মেট্রিক্সে থ্রেশহোল্ড সেট করা - কোডের পঠনযোগ্যতা এবং রক্ষণাবেক্ষণযোগ্যতাকে সম্ভাব্যভাবে বাধা দেয় এমন কিছু। জাভাতে, এই ধরনের একটি টুল হল চেকস্টাইল, পাইথনে - flake8। এই শ্রেণীর প্রোগ্রামগুলিকে সাধারণত "লিন্টার" বলা হয়।
• শুধুমাত্র এক্সিকিউটেবল কোডই বিশ্লেষণ করা যাবে না। রিসোর্স ফাইল যেমন JSON, YAML, XML, .properties স্বয়ংক্রিয়ভাবে বৈধতার জন্য চেক করা যেতে পারে (এবং উচিত!) সর্বোপরি, এটি খুঁজে বের করা ভাল যে JSON কাঠামোটি পরীক্ষা সম্পাদন বা রান টাইমের চেয়ে স্বয়ংক্রিয় পুল অনুরোধ যাচাইকরণের প্রাথমিক পর্যায়ে কিছু জোড়াবিহীন উদ্ধৃতির কারণে ভেঙে গেছে? উপযুক্ত সরঞ্জাম উপলব্ধ: যেমন ইয়ামলিন্ট, JSONLint.
• সংকলন (বা গতিশীল প্রোগ্রামিং ভাষার জন্য পার্সিং)ও এক ধরনের স্ট্যাটিক বিশ্লেষণ। সাধারণভাবে, কম্পাইলাররা সতর্কতা তৈরি করতে সক্ষম যা সোর্স কোডের মানের সমস্যা নির্দেশ করে এবং উপেক্ষা করা উচিত নয়।
• কখনও কখনও সংকলন শুধুমাত্র এক্সিকিউটেবল কোড কম্পাইল করার চেয়ে বেশি হয়। উদাহরণস্বরূপ, যদি আপনার বিন্যাসে ডকুমেন্টেশন থাকে AsciiDoctor, তারপর এটিকে HTML/PDF-এ পরিণত করার মুহূর্তে AsciiDoctor হ্যান্ডলার (মাভেন প্লাগইন) সতর্কতা জারি করতে পারে, উদাহরণস্বরূপ, ভাঙা অভ্যন্তরীণ লিঙ্ক সম্পর্কে। এবং ডকুমেন্টেশন পরিবর্তন সহ পুল অনুরোধ গ্রহণ না করার এটি একটি ভাল কারণ।
• বানান পরীক্ষাও এক ধরনের স্ট্যাটিক বিশ্লেষণ। ইউটিলিটি অ্যাসপেল শুধুমাত্র ডকুমেন্টেশনেই নয়, C/C++, Java এবং Python সহ বিভিন্ন প্রোগ্রামিং ভাষায় প্রোগ্রাম সোর্স কোডে (মন্তব্য এবং আক্ষরিক) বানান পরীক্ষা করতে সক্ষম। ইউজার ইন্টারফেস বা ডকুমেন্টেশনে একটি বানান ত্রুটিও একটি ত্রুটি!
• কনফিগারেশন পরীক্ষা (সেগুলি কী তা সম্পর্কে - দেখুন। এই и এই রিপোর্ট), যদিও পাইটেস্টের মতো ইউনিট টেস্ট রানটাইমে সম্পাদিত হয়, প্রকৃতপক্ষে এটি এক ধরনের স্ট্যাটিক বিশ্লেষণ, যেহেতু তারা তাদের সম্পাদনের সময় সোর্স কোডগুলি চালায় না।

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

এই ধরনের স্ট্যাটিক বিশ্লেষণের কোনটি আপনার প্রকল্পে ব্যবহার করা উচিত? অবশ্যই, আরো ভাল! প্রধান জিনিসটি সঠিকভাবে এটি বাস্তবায়ন করা, যা আরও আলোচনা করা হবে।

একটি মাল্টি-স্টেজ ফিল্টার হিসাবে ডেলিভারি পাইপলাইন এবং এটির প্রথম পর্যায় হিসাবে স্ট্যাটিক বিশ্লেষণ

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

1. স্ট্যাটিক বিশ্লেষণ
2. কম্পিলিটি
3. ইউনিট পরীক্ষা
4. ইন্টিগ্রেশন পরীক্ষা
5. UI পরীক্ষা
6. ম্যানুয়াল চেক

পাইপলাইনের Nth পর্যায়ে প্রত্যাখ্যান করা পরিবর্তনগুলি N+1 পর্যায়ে স্থানান্তরিত হয় না।

কেন ঠিক এই ভাবে এবং অন্যথায় না? পাইপলাইনের পরীক্ষার অংশে, পরীক্ষকরা সুপরিচিত টেস্টিং পিরামিড চিনতে পারবে।

পরীক্ষা পিরামিড। উৎস: একটি নিবন্ধ মার্টিন ফাওলার।

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

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

মাল্টি-স্টেজ ফিল্টার। উৎস: উইকিমিডিয়া কমন্স

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

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

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

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

একটি উত্তরাধিকার প্রকল্পে বাস্তবায়ন

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

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

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

মানের গেট প্রবর্তনের নিম্নলিখিত পদ্ধতিগুলি পরিচিত:

• সতর্কতার মোট সংখ্যা বা কোডের লাইনের সংখ্যা দ্বারা ভাগ করা সতর্কতার সংখ্যার একটি সীমা নির্ধারণ করা। এটি খারাপভাবে কাজ করে, কারণ এই ধরনের একটি গেট অবাধে নতুন ত্রুটিগুলির সাথে পরিবর্তনগুলিকে অতিক্রম করার অনুমতি দেয়, যতক্ষণ না তাদের সীমা অতিক্রম করা হয়।
• একটি নির্দিষ্ট মুহুর্তে, কোডের সমস্ত পুরানো সতর্কতাগুলিকে উপেক্ষা করা ঠিক করা, এবং নতুন সতর্কতাগুলি ঘটলে তৈরি করতে অস্বীকার করা৷ এই কার্যকারিতা PVS-studio এবং কিছু অনলাইন সংস্থান দ্বারা প্রদান করা হয়, উদাহরণস্বরূপ, Codacy. আমার পিভিএস-স্টুডিওতে কাজ করার সুযোগ ছিল না, কোড্যাসির সাথে আমার অভিজ্ঞতার জন্য, তাদের প্রধান সমস্যা হল কোনটি "পুরানো" এবং কোনটি "নতুন" ত্রুটি তা নির্ধারণ করা একটি জটিল অ্যালগরিদম যা সবসময় কাজ করে না সঠিকভাবে, বিশেষ করে যদি ফাইলগুলি খুব বেশি পরিবর্তিত বা পুনঃনামকরণ করা হয়। আমার অভিজ্ঞতায়, কোড্যাসি একটি পুল অনুরোধে নতুন সতর্কতা উপেক্ষা করতে পারে, একই সময়ে একটি প্রদত্ত পিআর কোডের পরিবর্তনের সাথে সম্পর্কিত নয় এমন সতর্কতার কারণে একটি পুল অনুরোধ পাস করেনি।
• আমার মতে, সবচেয়ে কার্যকর সমাধান হল বইটিতে বর্ণিত একটি অবিচ্ছিন্ন বিতরণ "র্যাচেটিং পদ্ধতি"। মূল ধারণা হল যে স্ট্যাটিক বিশ্লেষণ সতর্কতার সংখ্যা প্রতিটি রিলিজের একটি বৈশিষ্ট্য, এবং শুধুমাত্র পরিবর্তনগুলি অনুমোদিত যা সতর্কতার মোট সংখ্যা বাড়ায় না।

র্যাচেট

এটি এই ভাবে কাজ করে:

1. প্রাথমিক পর্যায়ে, বিশ্লেষকদের দ্বারা পাওয়া কোডে সতর্কতার সংখ্যা প্রকাশের বিষয়ে মেটাডেটাতে একটি রেকর্ড তৈরি করা হয়। সুতরাং, যখন আপনি আপস্ট্রিম তৈরি করেন, তখন আপনার সংগ্রহস্থল ম্যানেজার শুধু "7.0.2 রিলিজ" নয়, "রিলিজ 7.0.2 100500 চেকস্টাইল সতর্কতা সমন্বিত" লেখেন। আপনি যদি একটি উন্নত রিপোজিটরি ম্যানেজার ব্যবহার করেন (যেমন আর্টিফ্যাক্টরি), আপনার রিলিজ সম্পর্কে এই ধরনের মেটাডেটা সংরক্ষণ করা সহজ।
2. এখন প্রতিটি পুল অনুরোধ, নির্মিত হলে, বর্তমান রিলিজে উপলব্ধ সতর্কতার সংখ্যার সাথে ফলাফলের সতর্কতার সংখ্যা তুলনা করে। যদি PR এই সংখ্যা বৃদ্ধির দিকে পরিচালিত করে, তাহলে কোড স্ট্যাটিক বিশ্লেষণের জন্য মানের গেট পাস করে না। যদি সতর্কতার সংখ্যা হ্রাস পায় বা পরিবর্তন না হয় তবে এটি পাস হয়।
3. পরবর্তী রিলিজে, রিলিজ মেটাডেটাতে পুনরায় গণনা করা সতর্কতার সংখ্যা আবার রেকর্ড করা হবে।

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

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

আমি এই পদ্ধতির একটি পরিবর্তিত সংস্করণ ব্যবহার করি, আলাদাভাবে প্রজেক্ট মডিউল এবং বিশ্লেষণ টুল দ্বারা সতর্কতা গণনা করি, যার ফলে বিল্ড মেটাডেটা সহ একটি YAML ফাইল যা দেখতে এইরকম কিছু:

celesta-sql:
  checkstyle: 434
  spotbugs: 45
celesta-core:
  checkstyle: 206
  spotbugs: 13
celesta-maven-plugin:
  checkstyle: 19
  spotbugs: 0
celesta-unit:
  checkstyle: 0
  spotbugs: 0

যেকোন উন্নত CI সিস্টেমে, প্লাগইন এবং তৃতীয় পক্ষের টুলের উপর নির্ভর না করে যেকোন স্ট্যাটিক অ্যানালাইসিস টুলের জন্য র্যাচেট প্রয়োগ করা যেতে পারে। প্রতিটি বিশ্লেষক একটি সাধারণ পাঠ্য বা XML বিন্যাসে তার নিজস্ব প্রতিবেদন তৈরি করে যা বিশ্লেষণ করা সহজ। যা বাকি থাকে তা হল সিআই স্ক্রিপ্টে প্রয়োজনীয় যুক্তি লিখতে। জেনকিন্স এবং আর্টিফ্যাক্টরি ভিত্তিক আমাদের ওপেন সোর্স প্রকল্পগুলিতে এটি কীভাবে প্রয়োগ করা হয় তা আপনি দেখতে পারেন এখানে বা এখানে. উভয় উদাহরণ লাইব্রেরির উপর নির্ভর করে ratchetlib: পদ্ধতি countWarnings() স্বাভাবিক উপায়ে চেকস্টাইল এবং স্পটবাগ দ্বারা উত্পন্ন ফাইলগুলিতে xml ট্যাগ গণনা করে এবং compareWarningMaps() একই র্যাচেট প্রয়োগ করে, যেকোনও বিভাগে সতর্কতার সংখ্যা বৃদ্ধি পেলে একটি ত্রুটি নিক্ষেপ করে।

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

বিশ্লেষক সংস্করণ ঠিক করার গুরুত্ব সম্পর্কে

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

তথ্যও

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

রেফারেন্স

1. অবিচ্ছিন্ন বিতরণ
2. উ: কুদ্র্যাভতসেভ: প্রোগ্রাম বিশ্লেষণ: কীভাবে বুঝবেন যে আপনি একজন ভালো প্রোগ্রামার কোড বিশ্লেষণের বিভিন্ন পদ্ধতি সম্পর্কে রিপোর্ট করুন (কেবল স্ট্যাটিক নয়!)

উত্স: www.habr.com