দলকে নিঃশেষ না করে কীভাবে একটি উত্তরাধিকার প্রকল্পে একটি স্ট্যাটিক কোড বিশ্লেষক প্রয়োগ করবেন

স্ট্যাটিক কোড বিশ্লেষক চেষ্টা করা সহজ। কিন্তু এটি বাস্তবায়ন করতে, বিশেষ করে একটি বৃহৎ পুরানো প্রকল্পের উন্নয়নে, দক্ষতা প্রয়োজন। যদি ভুলভাবে করা হয়, বিশ্লেষক কাজ যোগ করতে পারে, বিকাশকে ধীর করে দিতে পারে এবং দলকে অবনমিত করতে পারে। আসুন সংক্ষিপ্তভাবে আলোচনা করি কিভাবে সঠিকভাবে উন্নয়ন প্রক্রিয়ায় স্ট্যাটিক বিশ্লেষণের একীকরণের সাথে যোগাযোগ করা যায় এবং এটিকে CI/CD-এর অংশ হিসাবে ব্যবহার করা শুরু করে।

ভূমিকা

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

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

সমস্যাযুক্ত

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

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

যদি স্ট্যাটিক বিশ্লেষক ইতিমধ্যে কনফিগার করা থাকে তবে মিথ্যা ইতিবাচক কোন সমস্যা নয়:

• নিষ্ক্রিয় অপ্রাসঙ্গিক নিয়ম সেট;
• কিছু অপ্রাসঙ্গিক ডায়গনিস্টিক অক্ষম করা হয়েছে;
• যদি আমরা C বা C++ নিয়ে কথা বলি, তাহলে ম্যাক্রোগুলিকে চিহ্নিত করা হয় যাতে নির্দিষ্ট কনস্ট্রাক্ট থাকে যার ফলে এই ধরনের ম্যাক্রো ব্যবহার করা হয় এমন প্রতিটি জায়গায় অকেজো সতর্কতা দেখা দেয়;
• নিজস্ব ফাংশনগুলি চিহ্নিত করা হয় যা সিস্টেম ফাংশনগুলির অনুরূপ ক্রিয়া সম্পাদন করে (এর নিজস্ব অ্যানালগ স্মৃতিচারণ বা printf,) [4];
• মিথ্যা ইতিবাচক মন্তব্য ব্যবহার করে বিশেষভাবে অক্ষম করা হয়;
• আর তাই

এই ক্ষেত্রে, আমরা প্রায় 10-15% কম মিথ্যা ইতিবাচক হার আশা করতে পারি [5]। অন্য কথায়, 9টির মধ্যে 10টি বিশ্লেষক সতর্কতা কোডে একটি বাস্তব সমস্যা নির্দেশ করবে, বা অন্ততপক্ষে "শক্তিশালী-গন্ধযুক্ত কোড"। সম্মত হন, এই দৃশ্যটি অত্যন্ত মনোরম, এবং বিশ্লেষক প্রোগ্রামারের প্রকৃত বন্ধু।

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

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

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

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

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

এটি কম্পাইলার সতর্কতার সাথে একই সাদৃশ্য। এটা কোন কারণ ছাড়াই নয় যে তারা কম্পাইলার সতর্কতার সংখ্যা 0 এ রাখার সুপারিশ করে। যদি 1000টি সতর্কবার্তা থাকে, তাহলে যখন 1001টি থাকবে, তখন কেউ তাতে মনোযোগ দেবে না এবং এই নতুন সতর্কবার্তাটি কোথায় দেখতে হবে তা পরিষ্কার নয়।

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

প্রযুক্তিগত ঋণ বাস্তবায়ন এবং নির্মূল করা

প্রকৃতপক্ষে, একটি বড় পুরানো প্রকল্পে স্ট্যাটিক বিশ্লেষণ প্রবর্তন সম্পর্কে কঠিন বা ভীতিকর কিছু নেই।

সিআই/সিডি

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

• পিভিএস-স্টুডিও মেঘে যায়: আজুর ডেভপস
• পিভিএস-স্টুডিও মেঘে যায়: ট্র্যাভিস সিআই
• পিভিএস-স্টুডিও মেঘে যায়: গিটল্যাব সিআই/সিডি
• পিভিএস-স্টুডিও মেঘে যায়: সার্কেলসিআই

তবে আসুন কোড বিশ্লেষণ সরঞ্জামগুলি বাস্তবায়নের প্রথম পর্যায়ে প্রচুর পরিমাণে মিথ্যা ইতিবাচক বিষয়ে ফিরে আসি।

বিদ্যমান প্রযুক্তিগত ঋণ সংশোধন করা এবং নতুন সতর্কতা মোকাবেলা করা

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

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

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

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

সুতরাং, একটি বড় পুরানো প্রকল্পে বিশ্লেষক বাস্তবায়নের সাথে প্রথম সমস্যাটি সমাধান করা হয়েছে। এখন আসুন প্রযুক্তিগত ঋণের সাথে কি করতে হবে তা খুঁজে বের করা যাক।

বাগ ফিক্স এবং রিফ্যাক্টরিং

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

if (a = b)

বেশিরভাগ সি++ কম্পাইলার এবং বিশ্লেষকরা এই ধরনের কোড সম্পর্কে অভিযোগ করেন, যেহেতু তারা আসলে লিখতে চেয়েছিলেন এমন একটি উচ্চ সম্ভাবনা রয়েছে (a == খ). তবে একটি অব্যক্ত চুক্তি রয়েছে এবং এটি সাধারণত ডকুমেন্টেশনে উল্লেখ করা হয় যে যদি অতিরিক্ত বন্ধনী থাকে তবে এটি বিবেচনা করা হয় যে প্রোগ্রামার ইচ্ছাকৃতভাবে এই জাতীয় কোড লিখেছেন এবং শপথ ​​করার দরকার নেই। উদাহরণস্বরূপ, ডায়াগনস্টিকসের জন্য পিভিএস-স্টুডিও ডকুমেন্টেশনে V559 (CWE-481) এটি স্পষ্টভাবে লেখা আছে যে নিম্নলিখিত লাইনটি সঠিক এবং নিরাপদ বলে বিবেচিত হবে:

if ((a = b))

আরেকটি উদাহরণ. এটা কি এই C++ কোডে ভুলে গেছে? বিরতি নাকি?

case A:
  foo();
case B:
  bar();
  break;

পিভিএস-স্টুডিও বিশ্লেষক এখানে একটি সতর্কতা জারি করবে V796 (CWE-484). এটি একটি ত্রুটি নাও হতে পারে, এই ক্ষেত্রে আপনাকে অ্যাট্রিবিউট যোগ করে পার্সারকে একটি ইঙ্গিত দিতে হবে [[ব্যর্থ হত্তয়া]] বা উদাহরণস্বরূপ __অ্যাট্রিবিউট__((ফলথ্রু)):

case A:
  foo();
  [[fallthrough]];
case B:
  bar();
  break;

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

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

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

এছাড়াও, কোনো সমস্যা দেখা দিলে আমরা সবসময় আমাদের ক্লায়েন্টদের PVS-Studio সেট আপ করতে সাহায্য করি। তদুপরি, এমন কিছু ঘটনা ছিল যখন আমরা নিজেরাই মিথ্যা সতর্কবাণী দূর করেছি এবং ত্রুটিগুলি সংশোধন করেছি [8]। শুধু ক্ষেত্রে, আমি উল্লেখ করার সিদ্ধান্ত নিয়েছি যে বর্ধিত সহযোগিতার জন্য এই বিকল্পটিও সম্ভব :)।

র্যাচেট পদ্ধতি

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

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

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

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

নিবন্ধটির লেখকেরও এই বিষয়ে একটি প্রতিবেদন রয়েছে: "ক্রমাগত স্ট্যাটিক বিশ্লেষণ".

উপসংহার

আমি আশা করি যে এই নিবন্ধের পরে, পাঠকরা স্ট্যাটিক বিশ্লেষণ সরঞ্জামগুলিকে আরও বেশি গ্রহণ করবে এবং সেগুলিকে উন্নয়ন প্রক্রিয়ায় প্রয়োগ করতে চাইবে৷ যদি আপনার কোন প্রশ্ন থাকে, আমরা সবসময় প্রস্তুত পরামর্শ আমাদের স্ট্যাটিক বিশ্লেষক PVS-Studio এর ব্যবহারকারীরা এবং এর বাস্তবায়নে সহায়তা করে।

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

আপনার মনোযোগ এবং আসা জন্য আপনাকে ধন্যবাদ ডাউনলোড এবং পিভিএস-স্টুডিও বিশ্লেষক চেষ্টা করুন।

অতিরিক্ত লিঙ্ক

1. আন্দ্রে কার্পভ। পিভিএস-স্টুডিও বিশ্লেষক C এবং C++ কোডের জন্য যে আকর্ষণীয় সতর্কতাগুলি তৈরি করে তা আমি কীভাবে দ্রুত দেখতে পারি?
2. উইকিপিডিয়া। ধানের উপপাদ্য.
3. আন্দ্রে কার্পভ, ভিক্টোরিয়া খানিয়েভা। প্রোগ্রাম সোর্স কোডের স্ট্যাটিক বিশ্লেষণে মেশিন লার্নিং ব্যবহার করা.
4. পিভিএস-স্টুডিও। ডকুমেন্টেশন। অতিরিক্ত ডায়গনিস্টিক সেটিংস.
5. আন্দ্রে কার্পভ। ইএফএল কোর লাইব্রেরির উদাহরণ ব্যবহার করে পিভিএস-স্টুডিও বিশ্লেষকের বৈশিষ্ট্য, 10-15% মিথ্যা ইতিবাচক.
6. পিভিএস-স্টুডিও। ডকুমেন্টেশন। বিশ্লেষক বার্তা গণ দমন.
7. ইভান আন্দ্রিয়াশিন। এক্স-রে এন্ডোভাসকুলার সার্জারির একটি শিক্ষাগত সিমুলেটরের আমাদের প্রকল্পে আমরা কীভাবে স্ট্যাটিক বিশ্লেষণ পরীক্ষা করেছি সে সম্পর্কে.
8. পাভেল এরেমিভ, স্ব্যাটোস্লাভ রাজমিস্লোভ। PVS-Studio টিম কিভাবে অবাস্তব ইঞ্জিন কোড উন্নত করেছে.
9. আন্দ্রে কার্পভ। উন্নয়ন প্রক্রিয়ার মধ্যে স্ট্যাটিক কোড বিশ্লেষক PVS-স্টুডিও প্রবর্তনের কারণ.

আপনি যদি এই নিবন্ধটি ইংরেজিভাষী দর্শকদের সাথে ভাগ করতে চান তবে অনুগ্রহ করে অনুবাদ লিঙ্কটি ব্যবহার করুন: আন্দ্রে কার্পভ। কীভাবে একটি উত্তরাধিকার প্রকল্পে একটি স্ট্যাটিক কোড বিশ্লেষক প্রবর্তন করবেন এবং দলকে নিরুৎসাহিত করবেন না.

উত্স: www.habr.com