কীভাবে এআই কোডে পারফরম্যান্স, পঠনযোগ্যতা ও সরলতা সামঞ্জস্য করে

পারফরম্যান্স, পঠনযোগ্যতা এবং সরলতা সমন্বয়ের মানে\n\nকোনো কিছুই “ব্যালান্স” হয়েছে কিনা বিচার করবার আগে, যে ধরনের কোডের কথা বলছেন তা নামকরণ করা সহায়ক।\n\nঅ্যাপ্লিকেশন লজিক হলো সেই কোড যা আপনার প্রোডাক্টের নিয়ম ও ওয়ার্কফ্লো প্রকাশ করে: যোগ্যতা চেক, মূল্য নির্ধারণ, অর্ডার স্টেট ট্রানজিশন, অনুমতি এবং “পরবর্তী কী ঘটবে” ধরণের ধাপ। এটা ব্যবসায়িক আচরণের সঙ্গে সবচেয়ে ঘনিষ্ঠ এবং সবচেয়ে দ্রুত পরিবর্তিত অংশ।\n\nইনফ্রাস্ট্রাকচার কোড হলো প্লাম্বিং: ডেটাবেস কানেকশন, HTTP সার্ভার, মেসেজ কিউ, ডিপ্লয়মেন্ট কনফিগ, লোগিং পাইপলাইন এবং ইন্টিগ্রেশন। এগুলো গুরুত্বপূর্ণ, কিন্তু সাধারণত আপনি যেখানে মূল নিয়মগুলো এনকোড করেন তা এখানে নেই।\n\n### তিনটি লক্ষ্য—এবং সেগুলি আসলে কী বোঝায়\n\nপারফরম্যান্স মানে কোডটি যুক্তিসঙ্গত সময় ও রিসোর্স (CPU, মেমরি, নেটওয়ার্ক কল, DB কোয়েরি) ব্যবহার করে কাজটি করে। অ্যাপ্লিকেশন লজিকে পারফরম্যান্স সমস্যা সাধারণত অতিরিক্ত I/O থেকে হয় (অনেক কোয়েরি, বারবার API কল)—ধীর লুপ থেকে কম।\n\nপঠনযোগ্যতা মানে একজন সহকর্মী কীভাবে কোডটি কি করে, কেন করে, এবং কোথায় পরিবর্তন করবে তা সঠিকভাবে বুঝতে পারে—ঘন্টা খানিক “মনে করে ডিবাগ” না করেই।\n\nসরলতা মানে কম মুভিং পার্ট: কম অ্যাবস্ট্রাকশন, কম স্পেশাল কেস এবং কম গোপন সাইড ইফেক্ট। সরল কোড সাধারণত টেস্ট করা সহজ ও নিরাপদে মডিফাই করা যায়।\n\n### বাস্তব প্রকল্পে কেন এই লক্ষ্যগুলো সংঘাত করে\n\nএকটি লক্ষ্য উন্নত করলে প্রায়ই অন্যগুলো চাপিয়ে পড়ে।\n\nক্যাশিং দ্রুত করে কিন্তু ইনভ্যালিডেশন নিয়ম যোগ করে। ভারী অ্যাবস্ট্রাকশন ডুপ্লিকেশন দূর করে কিন্তু ফ্লোকে বোঝা কঠিন করে। মাইক্রো-অপ্টিমাইজেশন রানটাইম কমায় কিন্তু উদ্দেশ্য অস্পষ্ট করে।\n\nAI ওভার-সল্ভও করতে পারে: এটি জেনারালাইজড প্যাটার্ন (ফ্যাক্টরিস, স্ট্র্যাটেজি অবজেক্ট, জটিল হেল্পার) প্রস্তাব করতে পারে যেখানে সরল ফাংশন পরিষ্কার থাকত।\n\n### “ভাল-পর্যাপ্ত” কেমন দেখায়\n\nঅধিকাংশ টিমের জন্য “ভাল-পর্যাপ্ত” হচ্ছে:\n\n- স্বচ্ছ কন্ট্রোল ফ্লো ও নামকরণ, ন্যূনতম অ্যাবস্ট্রাকশন\n- বর্তমান SLA মেট করে এমন পারফরম্যান্স, স্পষ্ট বোতলনেক এড়ানো (বিশেষ করে অতিরিক্ত DB/API রাউন্ড ট্রিপ)\n- টেস্ট করার জন্য সরল সিমস, যাতে পরিবর্তনগুলো নিরাপদে করা যায়\n\nব্যালান্স সাধারণত এমন কোড শিপ করা যেটা রক্ষণাবেক্ষণযোগ্য—এবং কেবলমাত্র মেজারমেন্ট (বা প্রকৃত ইনসিডেন্ট) যখন প্রয়োজন তখন জটিলতা নেয়া।\n\n## AI সাধারণত কিভাবে কোড স্ট্রাকচার বেছে নেয়\n\nAI একজন ইঞ্জিনিয়ারের মত সমাধান ‘নির্বাচন’ করে না। এটি আপনার প্রম্পট ও যে প্যাটার্নগুলো দেখতে পেয়েছে সেগুলি থেকে পরবর্তী সম্ভাব্য টোকেনগুলো ভবিষ্যদ্বাণী করে। অর্থাৎ কোডের আকার বেশ নির্ভর করে আপনি কী চাইছেন এবং আপনি কী দেখাচ্ছেন তার উপর।\n\n### এটা আপনার অনুরোধ (এবং আপনার উদাহরণ) অনুযায়ী অপ্টিমাইজ করে\n\nআপনি যদি বলুন “সবচেয়ে দ্রুত সলিউশন,” তাহলে প্রায়ই অতিরিক্ত ক্যাশিং, আরলি এক্সিট, এবং গতি অগ্রাধিকার দেয় এমন ডেটা স্ট্রাকচার পাবেন—যদিও পারফরম্যান্স লাভ নগণ্য হতে পারে। যদি আপনি বলুন “পরিষ্কার ও পড়ার উপযোগী,” তাহলে সাধারণত বেশি বর্ণনামূলক নাম, ছোট ফাংশন, এবং স্পষ্ট কন্ট্রোল ফ্লো পাবেন।\n\nএকটি উদাহরণ বা বিদ্যমান কোড স্টাইল দিতে পারলে সেটি বিশেষভাবে শক্তিশালী। একটি মডেল নকল করবে:\n\n- নামকরণ কনভেনশন ও ফাংশন বাউন্ডারি\n- এরর-হ্যান্ডলিং প্যাটার্ন (exception বনাম রিটার্ন ভ্যালু)\n- পছন্দের অ্যাবস্ট্রাকশন (হেল্পার, সার্ভিস, রিপোজিটরি)\n\n### সতর্ক হওয়ার প্রচলিত ব্যর্থতার ধরন\n\nকারণ AI প্যাটার্ন গঠন করতে বেশ ভাল, সেটি “ক্লেভার” সলিউশনে সরিয়ে পড়তে পারে যা চমকপ্রদ দেখলেও রক্ষণাবেক্ষণে কঠিন:\n\n- ওভার-ইঞ্জিনিয়ারিং: সরল ফিচারের জন্য অপ্রয়োজনীয় লেয়ার, ফ্যাক্টরি, ইন্টারফেস বা জেনেরিক হেল্পার\n- চতুর কোড: ঘন এক-লাইনার, জটিল কম্প্রিহেনশন, বা ভারী ফাংশনাল চেইনিং যা উদ্দেশ্য লুকায়\n- প্রিম্যাচিউর অপ্টিমাইজেশন: মেপে না দেখে মাইক্রো-অপ্টিমাইজেশন (ম্যানুয়াল ক্যাশিং, কাস্টম সর্টিং)\n\n### ট্রেনিং ডেটা স্টাইল ও ডিফল্ট গঠন করে\n\nAI বাস্তব কোডের মিশ্রণ থেকে শেখে: ক্লিন লাইব্রেরি, তাড়াহুড়োর অ্যাপ কোড, ইন্টারভিউ সলিউশন, ফ্রেমওয়ার্ক উদাহরণ—এই বৈচিত্র্যের কারণে আপনি কখনও ইডিওমেটিক, কখনও অত্যধিক অ্যাবস্ট্রাক্ট এবং কখনও অপ্রয়োজনীয়ভাবে বর্ণনামূলক কোড দেখতে পারেন।\n\n### চূড়ান্ত ট্রেড-অফ মানুষরাই নির্ধারণ করবে\n\nমডেল বিকল্প প্রস্তাব করতে পারে, কিন্তু এটি পুরোপুরি আপনার কনস্ট্রেইন্ট জেনে চূড়ান্ত সিদ্ধান্ত নিতে পারে না: টিম স্কিল লেভেল, কোডবেস কনভেনশন, প্রোডাকশন ট্রাফিক, ডেডলাইন, এবং দীর্ঘ-মেয়াদী মেইনটেন্যান্স কস্ট। AI আউটপুটকে খসড়া হিসাবে বিবেচনা করুন। আপনার কাজ হচ্ছে কোন ট্রেড-অফ বাস্তবে চান তা বেছে নেওয়া—এবং যতক্ষণ না উদ্দেশ্য স্পষ্ট হয় ততক্ষণ সরল করা।\n\n## প্রতিদিনকার অ্যাপ্লিকেশন লজিকে ট্রেড-অফ ট্রায়াঙ্গল\n\nদৈনন্দিন অ্যাপ্লিকেশন লজিক একটি ত্রিভুজের মধ্যে থাকে: পারফরম্যান্স, পঠনযোগ্যতা, এবং সরলতা। AI-জেনারেটেড কোড প্রায়ই “যুক্তিসঙ্গত” মনে হয় কারণ এটি তিনটি লক্ষ্যই সন্তুষ্ট করার চেষ্টা করে—কিন্তু বাস্তব প্রকল্প আপনাকে নির্দিষ্ট অংশের জন্য কোন কোর্নারটি সবচেয়ে গুরুত্বপূর্ণ তা বেছে নিতে বাধ্য করবে।\n\n### আপনি সঙ্গে সঙ্গে চিনতে পারবেন এমন ট্রেড-অফগুলো\n\nক্লাসিক উদাহরণ হলো ক্যাশিং বনাম স্পষ্টতা। একটি ক্যাশ যোগ করলে ধীর অনুরোধ দ্রুত হতে পারে, কিন্তু এটি প্রশ্ন যোগ করে: ক্যাশ কখন এক্সপায়ার করবে? আপডেট পরে কী হবে? যদি ক্যাশ নিয়ম স্পষ্ট না হয়, ভবিষ্যৎ রিডাররা তা ভুলভাবে ব্যবহার করবে বা “ঠিক করবে” ভুলভাবে।\n\nআরেকটা সাধারণ টানটানিঃ অ্যাবস্ট্রাকশন বনাম সরাসরি কোড। AI হেল্পার এক্সট্র্যাক্ট করতে পারে, জেনেরিক ইউটিলিটি তৈরি করতে পারে, বা লেয়ার যোগ করতে পারে (“service”, “repository”, “factory”) যাতে কোড পরিষ্কার দেখায়। কখনও কখনও এটা পঠনযোগ্যতা বাড়ায়; কখনও এটি ব্যবসায়িক নিয়মকে ইন্ডিরেকশনের পিছনে লুকিয়ে দেয়।\n\n### কখন মাইক্রো-অপ্টিমাইজেশন বোঝা কমপ্রিহেনশনকে ক্ষতিগ্রস্ত করে\n\nছোট ট weakীক—অ্যারে প্রি-অ্যালোকেট করা, চতুর এক-লাইন, অস্থায়ী ভ্যারিয়েবল এড়ানো—মিলিসেকেন্ড বাঁচাতে পারে কিন্তু মানুষের মনোযোগের মিনিট নষ্ট করে। যদি কোডটি নন-ক্রিটিক্যাল পাথে থাকে, ওই মাইক্রো-অপ্টিমাইজেশনগুলো সাধারণত নেট লস। স্পষ্ট নামকরণ ও সরল ফ্লো জিতবে।\n\n### কখন “সরল” স্কেলে ধসে পড়ে\n\nঅন্যদিকে, সবচেয়ে সরল পদ্ধতিই লোডে ভেঙে পড়তে পারে: লুপের ভিতরে কুয়েরি করা, একই ভ্যালু বারবার হিসাব করা, বা প্রয়োজনের চেয়ে বেশি ডেটা ফেচ করা। 100 ইউজারের জন্য সুন্দর পড়া কোড 100,000-এ ব্যয়বহুল হতে পারে।\n\n### একটি বাস্তব সম্মানীয় রুল\n\nসঠিক এবং সবচেয়ে পড়ার উপযোগী সংস্করণ দিয়ে শুরু করুন। তারপর কেবল তখনই অপ্টিমাইজ করুন যখন আপনার কাছে প্রমাণ (লগ, প্রোফাইলিং, বাস্তব ল্যাটেন্সি মেট্রিক্স) থাকে যে কোডটি বটলনেক। এতে AI আউটপুট বুঝতে সহজ থাকে এবং আপনি যেখানে দরকার সেখানে পারফরম্যান্স অর্জন করতে পারবেন।\n\n## AI-কে সঠিক ধরণের লজিক জেনারেট করতে প্রম্পট করা\n\nAI সাধারণত আপনি যা বলেন সেটাই করে—আক্ষরিকভাবে। যদি আপনার প্রম্পট অস্পষ্ট হয় ("এটা দ্রুত করুন"), এটি অপ্রয়োজনীয় জটিলতা উদ্ভাবন করতে পারে, বা ভুল জিনিস অপ্টিমাইজ করতে পারে। আউটপুট কন্ট্রোল করার সেরা উপায় হল কী দেখতে ভালো লাগে এবং আপনি কী না করতে চান তা বর্ণনা করা।\n\n### গ্রহণযোগ্য মানদণ্ড (acceptance criteria) এবং নন-গোল দিয়ে শুরু করুন\n\n3–6টি কনক্রিট গ্রহণযোগ্য মানদণ্ড লিখুন যা দ্রুত পরীক্ষা করা যায়। তারপর “নন-গোল” যোগ করুন যাতে "সাহায্যকর" বিচ্যুতি বন্ধ করা যায়।\n\nউদাহরণ:\n\n- গ্রহণযোগ্য মানদণ্ড: “10k রেকর্ডে 200ms-এর নিচে ফলাফল দিতে হবে; ত্রুটি ইউজার-ফ্রেন্ডলি হতে হবে; ফাংশন ~40 লাইনের নিচে রাখুন।”\n- নন-গোল: “কোনো ক্যাশিং লেয়ার নয়; নতুন ডিপেন্ডেন্সি নেই; ডেটাবেস স্কিমা পরিবর্তন নেই।”\n\n### মডেল যা অনুমান করতে পারে না এমন কনস্ট্রেইন্ট নির্দিষ্ট করুন\n\nপারফরম্যান্স ও সরলতা প্রসঙ্গের উপর নির্ভর করে, তাই আপনি যে কনস্ট্রেইন্টগুলো জানেন সেগুলো যোগ করুন:\n\n- লেটেন্সি টার্গেট (p95, p99 যদি থাকে)\n- ডেটা সাইজ ও গ্রোথ অনুমান\n- কনকারেন্সি (একক ব্যবহারকারী বনাম বহু প্যারালাল রিকোয়েস্ট)\n- মেমরি সীমা (সার্ভারলেস ক্যাপ, মোবাইল ডিভাইস ইত্যাদি)\n\nপ্রায় সঠিক সংখ্যাই অনির্দিষ্ট সংখ্যার চাইতে ভাল।\n\n### একটি “সিম্পল ফার্স্ট ভার্সন” প্লাস একটি “অপ্টিমাইজড ভার্সন” চান\n\nস্পষ্টভাবে দুটি ভার্সন অনুরোধ করুন। প্রথমটি পড়ার উপযোগীতা ও সরল কন্ট্রোল ফ্লো অগ্রাধিক্য দেবে। দ্বিতীয়টি যত্নশীল অপ্টিমাইজেশন যুক্ত করতে পারে—কিন্তু কেবল ততক্ষণ পর্যন্ত তা বর্ণনাযোগ্য থাকে।\n\ntext\nWrite application logic for X.\nAcceptance criteria: ...\nNon-goals: ...\nConstraints: latency ..., data size ..., concurrency ..., memory ...\nDeliver:\n1) Simple version (most readable)\n2) Optimized version (explain the trade-offs)\nAlso: explain time/space complexity in plain English and note any edge cases.\n\n\n### ব্যাখ্যা ও কমপ্লেক্সিটি সহজ ভাষায় চাওয়া\n\nমডেলকে মূল ডিজাইন পছন্দগুলো ব্যাখ্যা করতে বলুন ("কেন এই ডেটা স্ট্রাকচার", "এই ব্রাঞ্চিং কেন") এবং জটিলতা অনুমান বর্ণনা করুন—জার্গন ছাড়া। এতে রিভিউ, টেস্টিং এবং সিদ্ধান্ত নেওয়া সহজ হয়।\n\n## প্যাটার্নগুলো যা AI-জেনারেটেড লজিককে পড়ার উপযোগী রাখে\n\nপঠনযোগ্য অ্যাপ্লিকেশন লজিক সাধারণত চতুর সিনট্যাক্সের ব্যাপার নয়। এটা পরবর্তী লোককে (প্রায়শই ভবিষ্যৎ আপনি) একটি পাসে বুঝতে দেয়ার বিষয়ে। AI ব্যবহার করে লজিক জেনারেট করার সময়, কিছু প্যাটার্ন ধারাবাহিকভাবে এমন আউটপুট দেয় যা novelty চলে গেলেও পরিষ্কার থাকে।\n\n### ফাংশনগুলো ছোট ও একক-উদ্দেশ্য রাখুন\n\nAI প্রায়ই validation, transformation, persistence ও logging এক সঙ্গে ব্যান্ডেল করে এক বড় ফাংশনে দেয়। এটাকে ছোট ইউনিটে টেনে আনুন: ইনপুট ভ্যালিডেশনের জন্য একটি ফাংশন, রেজাল্ট গণনার জন্য একটি ফাংশন, সেভ করার জন্য একটি ফাংশন।\n\nএকটি উপকারী রুল-অফ-থাম্ব: যদি আপনি একটি ফাংশনের কাজ সংক্ষেপে বলতে না পারেন “এবং” ছাড়া, তাহলে সম্ভবত এটি খুব বেশি কাজ করছে।\n\n### সরল কন্ট্রোল ফ্লো পছন্দ করুন\n\nপঠনযোগ্য লজিক ক্লিয়ার ব্রাঞ্চিংকে পছন্দ করে চতুর কম্প্রেশন নয়। যদি একটি কন্ডিশন গুরুত্বপূর্ণ হয়, সেটা স্পষ্ট if ব্লক হিসেবে লিখুন তোর nested ternary বা বুলিয়ান চেইনের বদলে।\n\nযখন আপনি AI আউটপুট দেখেন যেমন “সবকিছু এক এক্সপ্রেশনে করুন”, তখন “early returns” এবং “guard clauses” চাওয়া—এতে নেস্টিং কমে এবং হ্যাপি পাথ দেখা সহজ হয়।\n\n### এমনভাবে নামকরণ করুন যেন সহকর্মী তা রক্ষণাবেক্ষণ করবেন\n\nমেইনিংফুল নাম generic helper-এর চেয়ে ভালো। processData() বা handleThing()-এর বদলে এমন নাম ব্যবহার করুন যা উদ্দেশ্য এনকোড করে:\n\n- calculateInvoiceTotal()\n- isPaymentMethodSupported()\n- buildCustomerSummary()\n\nএছাড়াও ওভার-জেনেরিক ইউটিলিটির ক্ষেত্রে সতর্ক থাকুন (উদাহরণ: mapAndFilterAndSort()): এগুলো ব্যবসায়িক নিয়ম লুকিয়ে রাখতে পারে এবং ডিবাগিং কঠিন করে দেয়।\n\n### উদ্দেশ্য নিয়ে মন্তব্য করুন, যান্ত্রিকতা নিয়ে নয়\n\nAI প্রায়ই কোড পুনরায় বলার মতো verbose মন্তব্য তৈরি করে। মন্তব্য রাখুন শুধু যেখানে উদ্দেশ্য স্পষ্ট নয়: কেন একটি নিয়ম আছে, আপনি কোন এজ-কেস থেকে সুরক্ষা করছেন, বা কোন অনুমান সত্য থাকতে হবে।\n\nযদি কোড বুঝতে অনেক মন্তব্য লাগে, সেটাকে একটি সংকেত হিসেবে দেখুন—স্ট্রাকচার সরল করুন বা নাম উন্নত করুন; মন্তব্য বাড়ান নয়।\n\n## সরলতা রক্ষা করে এমন ডিজাইন পছন্দগুলি\n\nসরলতা সাধারণত কম কোড লেখার বিষয় নয়। এটি এমন কোড লেখার বিষয় যা একজন সহকর্মী পরবর্তী সপ্তাহে আত্মবিশ্বাসের সঙ্গে পরিবর্তন করতে পারে। AI এখানে সাহায্য করতে পারে—যদি আপনি এটাকে সমাধানের আকারটি সরল রাখতে বলুন।\n\n### সবচেয়ে সহজ উপযোগী ডেটা স্ট্রাকচার দিয়ে শুরু করুন\n\nAI প্রায়ই চতুর স্ট্রাকচারে ঝাঁপিয়ে পড়ে (ম্যাপ-অফ-ম্যাপ, কাস্টম ক্লাস, নেস্টেড জেনেরিক) কারণ এগুলো সাজানো দেখায়। প্রতিহত করুন। অধিকাংশ অ্যাপ্লিকেশন লজিকের জন্য সাধারণ অ্যারে/লিস্ট এবং সরল অবজেক্টগুলো বোঝার জন্য সহজ।\n\nযদি আপনি একটি ছোট সেট আইটেম ধরে রাখছেন, একটি লিস্ট সাথে পরিষ্কার filter/find প্রায়শই ইন্ডেক্স তৈরি করার চেয়ে বেশি পড়ার উপযোগী। কেবল তখনই ম্যাপ/ডিকশনারি লাও যখন লুকআপগুলি সত্যিই কেন্দ্রিয় ও বারবার হয়।\n\n### পুনরাবৃত্ত চাহিদা না হওয়া পর্যন্ত অ্যাবস্ট্রাকশন লিমিট করুন\n\nঅ্যাবস্ট্রাকশন পরিষ্কার মনে করায়, কিন্তু তাও অনেক হলে বাস্তব আচরণ লুকিয়ে দেয়। AI-কে কোড চাইলে “এক স্তরের ইনডিরেকশন” পছন্দ করুন: একটি ছোট ফাংশন, একটি পরিষ্কার মডিউল, এবং সরাসরি কল।\n\nএকটি সহায়ক রুল: একটি generic interface, factory, এবং plugin সিস্টেম তৈরি করবেন না শুধু একক ব্যবহারকেস সমাধান করতে। দ্বিতীয় বা তৃতীয় ভেরিয়েশন দেখলে তখন রিফ্যাক্টর করুন।\n\n### গভীর ইনহেরিটেন্স চেইনের বদলে কম্পোজিশন পছন্দ করুন\n\nইনহেরিটেন্স ট্রি জানাটা কঠিন করে: “এই আচরণ আসলে কোথা থেকে এসেছে?” কম্পোজিশন ডিপেনডেন্সিগুলো দৃশ্যমান রাখে। class A extends B extends C বদলে ছোট কম্পোনেন্টগুলো ব্যবহার করুন যেগুলোকে স্পষ্টভাবে combine করা যায়।\n\nAI প্রম্পটে বলতে পারেন: “স্টেবল শেয়ার্ড কন্ট্র্যাক্ট না থাকলে ইনহেরিটেন্স এড়ান; হেল্পার/সার্ভিস প্যারামিটার হিসেবে পাস করুন।”\n\n### আপনার টিম যে পরিচিত প্যাটার্ন ব্যবহার করে তা পছন্দ করুন\n\nAI এমন প্যাটার্ন সাজেস্ট করতে পারে যা টেকনিক্যালি ঠিক কিন্তু আপনার কোডবেসে সাংস্কৃতিকভাবে অচেনা। পরিচিতি একটি ফিচার। সলিউশন চাই এমনভাবে যা আপনার স্ট্যাক ও কনভেনশনের সাথে মেলে (নামকরণ, ফোল্ডার স্ট্রাকচার, এরর হ্যান্ডলিং), যাতে আউটপুট রিভিউ ও রক্ষণাবেক্ষণের জন্য প্রাকৃতিকভাবে ফিট করে।\n\n## পড়তে সুবিধা রেখে পারফরম্যান্স করা\n\nপারফরম্যান্স কাজ ভুল জিনিস অপ্টিমাইজ করলে বিপথগামী হয়। সেরা “দ্রুত” কোড হচ্ছে সঠিক অ্যালগরিদম প্রয়োগ করা।\n\n### টিউন করার আগে সঠিক অ্যালগরিদম বেছে নিন\n\nলুপ বা চতুর এক-লাইনার টুইক করার আগে নিশ্চিত করুন আপনি যুক্তিযুক্ত পদ্ধতি ব্যবহার করছেন: বারবার লিনিয়ার সার্চের পরিবর্তে হ্যাশ ম্যাপ, সদস্য-চেকের জন্য সেট, একাধিক স্ক্যানের বদলে সিঙ্গেল পাস। AI-কে সাহায্য চাইলে স্পষ্টভাবে বলুন কনস্ট্রেইন্ট: ইনপুট সাইজ, ডেটা সাজানো আছে কি না, এবং "দ্রুত যথেষ্ট" মানে কী।\n\nএকটি সহজ রুল: যদি কমপ্লেক্সিটি ভুল (যেমন বড় তালিকায় O(n²)), কোনো মাইক্রো-অপ্টিমাইজেশনই কাজ করবে না।\n\n### প্রথমে মাপুন (বাস্তব ইনপুট সাইজ দিয়ে)\n\nঅনুমান করবেন না। বেসিক প্রোফাইলিং, লাইটওয়েট বেঞ্চমার্ক এবং—সবচেয়ে গুরুত্বপূর্ণ—বাস্তবসম্মত ডেটা ভলিউম ব্যবহার করুন। AI-জেনারেটেড কোড দেখতে দক্ষ হতে পারে কিন্তু লুকানো ব্যয় হতে পারে (বারবার পার্সিং, অতিরিক্ত কুয়েরি)।\n\nআপনি যা মাপলেন ও কেন তা ডকুমেন্ট করুন। যেমন একটি ছোট মন্তব্য: “50k আইটেমের জন্য অপ্টিমাইজ করা; পূর্বের ভার্সন ~2s-এ টাইম আউট করত” ভবিষ্যতে কেও অনড়-মতো পরিবর্তন করা রোধ করে।\n\n### হট পাথে অপ্টিমাইজ করুন শুধুমাত্র\n\nঅধিকাংশ কোডকে নিরপেক্ষ ও পড়ার উপযোগী রাখুন। পারফরম্যান্স প্রচেষ্টা ফোকাস করুন যেখানে সময় আসলে যায়: টাইট লুপ, সিরিয়ালাইজেশন, DB কল, নেটওয়ার্ক বাউন্ডারি। অন্যথায়, স্পষ্টতা জিতুক এমনকি সেটা কয়েক মিলিসেকেন্ড ধীর করে।\n\n### ক্যাশিং, ব্যাচিং এবং ইনডেক্সিং সাবধানে ব্যবহার করুন\n\nএই কৌশলগুলো বড় বার্তা দিতে পারে, কিন্তু মানসিক ওভারহেড যোগ করে।\n\n- ক্যাশিং: ইনভ্যালিডেশন নিয়ম ও TTL কোড মন্তব্যে লিখুন।\n- ব্যাচিং: ব্যাচ সাইজ ও ব্যর্থতা হ্যান্ডলিং ব্যাখ্যা করুন।\n- ইন্ডেক্সিং: কোন কুয়েরি গুলো সুবিধা পাবে এবং লেখায় ইনডেক্সের খরচ কত হবে তা নোট করুন।\n\nযদি AI এগুলো সাজেস্ট করে, বলুন কেন, ট্রেড-অফ কী, এবং কখন অপ্টিমাইজেশন অপসারণ করা উচিত সে সম্পর্কে সংক্ষিপ্ত নোট দিতে।\n\n## AI-জেনারেটেড লজিকের জন্য টেস্টিং—সামঞ্জস্যতার সেফটি নেট\n\nAI দ্রুত “যুক্তিসঙ্গত” অ্যাপ্লিকেশন লজিক জেনারেট করতে পারে, কিন্তু এটি প্রোডাকশনে সূক্ষ্ম বাগের খরচ অনুভব করতে পারে না বা ভুল বোঝার কারণে হওয়া বিভ্রান্তি বুঝতে পারে না। টেস্টগুলো একটি বাফার—বিশেষ করে যখন আপনি পরে পারফরম্যান্স বাড়াতে বা একটি ব্যস্ত ফাংশন সরল করতে যাবেন।\n\n### কোডের সঙ্গেই টেস্ট চাইুন\n\nযখন আপনি ইমপ্লিমেন্টেশন চাইবেন, তখন টেস্টও চাইবেন। এতে স্পষ্ট অনুমান এবং ভাল-সংজ্ঞায়িত ইন্টারফেস আসে কারণ মডেলকে আচরণ প্রমাণ করতে হয়, কেবল বর্ণনা করতে নয়।\n\nপ্রায়োগিক বিভাজন:\n\n- ইউনিট টেস্ট বিশুদ্ধ বিজনেস রুলের জন্য (প্রাইসিং, যোগ্যতা, ভ্যালিডেশন)\n- ইন্টিগ্রেশন টেস্ট গ্লু লজিকের জন্য (DB কুয়েরি, কিউ, HTTP ক্লায়েন্ট)—প্রয়োজন হলে ফেইক বা টেস্ট কনটেইনার ব্যবহার করে\n\n### AI প্রায়ই মিস করা এজ কেসগুলো কভার করুন\n\nAI হ্যাপি-পাথ প্রথমে লিখে। আপনার টেস্ট প্ল্যানে এজ কেসগুলো স্পষ্ট করুন যাতে পরে স্মৃতি বা ট্রাইবাল নলেজ এর উপর নির্ভর করতে না হয়। সাধারণগুলো:

\n- খালি ইনপুট, অনুপস্থিত ফিল্ড, null / undefined\n- অনাকাঙ্ক্ষিত টাইপ বা ম্যালফর্মড ডেটা\n- টাইমআউট, রিটারাই, পার্শিয়াল ফেলিওর (বিশেষ করে নেটওয়ার্ক কলের চারপাশে)\n- আইডেম্পোটেন্সি (নিরাপদ পুনরায় চালানো) ও ডুপ্লিকেট ইভেন্ট \n### বিজনেস রুলের জন্য টেবিল-ড্রিভেন বা প্রপার্টি-ভিত্তিক টেস্ট ব্যবহার করুন\n\nবিজনেস লজিকে প্রায়ই অনেক ছোট ভ্যারিয়েশন থাকে ("ইউজার X হলে ও অর্ডার Y হলে Z করা হবে")। টেবিল-ড্রিভেন টেস্ট ইনপুট ও প্রত্যাশিত আউটপুটগুলো কমপ্যাক্টভাবে তালিকাভুক্ত করে এটি পড়তে সহজ রাখে।\n\nযদি রুলের ইনভারিয়ান্ট থাকে ("টোটাল নেগেটিভ হতে পারবে না", "ডিসকাউন্ট সর্বদা সাবটোটালের চেয়ে বেশি হবে না"), প্রপার্টি-ভিত্তিক টেস্ট ম্যানুয়ালি যা আপনার মাথায় আসে তার চেয়ে অনেক বেশি কেস এক্সপ্লোর করে।\n\n### টেস্টগুলি রিফ্যাক্টর ও অপ্টিমাইজেশনের সুরক্ষা দেয়\n\nএকবার আপনি ভাল কভারেজ পেলে, আপনি নিরাপদে করতে পারবেন: \n- নেস্টেড কন্ডিশনালগুলো স্পষ্ট কাঠামোতে বদলানো