Skip to main content

Featured post

Kafka with Spring boot

Kafka server setup is already mentioned in another post.  The goal of this post is to provide spring boot implementation for custom object produce and consume by kafka broker.

Code Smell বা বাজে কোড



Code Smell বা বাজে কোড বোঝার কিছু প্যাটার্ন আছে যা দেখে বোঝা যায়। এখানে এই সম্পর্কে কিছু ধারনা দেয়া হল। code smell সাধারনত ২ ভাগে বিভক্ত।
Code smells within classes:
একটা ক্লাসের মধ্যে সাধারনত মেথড গুলোয় কি ধরনের কোড স্মেল হয়ে থাকে এখানে তাই বর্ননা করা হয়েছে। নাম গুলি ইংরেজিতেই রাখা আছে যাতে সরাসরি ইংরেজি নাম দিয়ে গুগল করলেই সব ধরনের রিসোর্স পাওয়া যায়।
Comments:
বোঝার মত কমেন্ট আর না বোঝার মত কমেন্টের মধ্যে একটা সুন্দর পার্থক্য আছে। যদি কমেন্ট এমন হয় যে মেথড বা স্টেটমেন্ট ‘কেন’ বাদ দিয়ে ‘কি’ ব্যাখ্যা করে, তাহলেই বুঝতে হবে, কমেন্ট রিমুভ করতে হবে। আর যদি পারা যায় তবে এমনভাবে রিফ্যাক্টর করতে হবে যাতে কমেন্ট না লাগে। কমেন্ট কখনো এক্সিকিউট করে না, এবং এটাই আমরা ভুলে যাই।
কমেন্ট মেশিনের জন্য না, মানুষের বোঝার জন্য লেখা হয়।


Long method:
যদি সবকিছুই ঠিক থাকে, তবে বড় মেথডের চেয়ে ছোট মেথড সহজে পড়া যায়, সহজে বোঝা যায় এবং কোনো সমস্যা হলে সহজে সমাধান করা যায়। সবসময় চেষ্টা করতে হবে যাতে বড় মেথডকে যতটা সম্ভব ছোট করে লেখা যায়।

Long parameter list:
একটা মেথডে যত বেশি প্যারামিটার থাকে মেথডটা ঠিক ততটাই জটিল হয়। একটা মেথডে ঠিক কতটা প্যারামিটার থাকবে তার সংখ্যা নির্দিষ্ট হওয়া উচিত। নয়তো কখনো মেথডের জন্য যদি নতুন প্যারামিটার লাগে, বারবার একটা করে বাড়ানো অনেক ঝামেলা। যদি অনেক প্যারামিটার থাকে, তখন সবচেয়ে ভাল হয় সবগুলাকে নিয়ে একটা অবজেক্ট তৈরি করা এবং অবজেক্ট পাস করা।

Duplicate code:
ডুপ্লিকেট কোড, একই কোড বা কোড কপি সফটওয়্যার ডেভেলপমেন্টে নিষিদ্ধ একটা বস্তু। যখন যেভাবে পারা যায় একই কোড রিমুভ করা উচিত। যদি পারা যায় একই কোড কোন মেথডে নিয়ে, মেথড কল দিয়ে কাজ করা। খুব সামান্য বা কাছাকাছি হলেও সেম কোড এড়ানো ভাল। সফটওয়্যার ডেভেলপমেন্টে একটা কথা প্রচলিত আছে,
Don’t Repeat yourself

Conditional complexity:
অনেক সময় দেখা যায় কন্ডিশনাল ব্লকগুলো অনেক বড় হয়ে যায়, বা অনেক বড় হবে বোঝা যায়। তখন অবজেক্ট অরিয়েন্টেড প্রিন্সিপাল দিয়া অন্য ভাবে কিভাবে করা যায় দেখতে হবে। কারন লম্বা কন্ডিশনাল ব্লক অনেক সময় বিপদজনক হয়ে দাঁড়ায়।

Combinatorial explosion:
যদি এমন হয় যে একটা ক্লাসে বা মেথডে বিভিন্ন ভ্যারিয়েশনে ডেটা বা বিহ্যাভিয়ারাল পার্থক্যের জন্য প্রায় একই ধরনের কাজ করা হয়ে থাকে কিন্তু আলাদা আলাদা ভাবে কোড করতে হয়। এসব ক্ষেত্রে যে কোন জেনেরিক পদ্ধতি বের করতে হবে যাতে বিভিন্ন কম্বিনেশনের ডেটা বা বিহয়াভিয়ারের জন্যও মেথড বা স্টেটমেন্ট সেম থাকে।

Large Class:
বড় ক্লাস আর বড় মেথড একই ধরনে সমস্যা তৈরি করে। বড় ক্লাসের চেয়ে ছোট ক্লাস বুঝতে সহজ, পড়ে তারাতারি বোঝা যায় আর কোন সমস্যা হলে তারাতারি সমস্যা বোঝা যায়। এটা দেখতে হবে যে একটা ক্লাস কি অনেক কাজ করে কি না। যদি করে তবে তাকে ছোট ছোট ক্লাসে ভাগ করে ফেলতে হবে।

Type embedded in name:
অনেকেই মেথডের নামের সাথে ভ্যারিয়েবলের টাইপের নাম এড করে দেই। যেটা একে তো অপ্রয়োজনীয় তারপরে আবার ভ্যারিয়েবলের টাইপ পরিবর্তন করলে মেথডের নামও পরিবর্তন করতে হয়।

Uncommunicative name:
মেথডের নাম কি মেথডের কাজ কি তা রিপ্রেজেন্ট করে?
মেথডের নাম দেখে কি অন্য যে কোন ডেভেলপার বুঝতে পারে মেথডটি কি কাজ করে?
যদি না পারে তবে নাম পরিবর্তন করা জরুরি। নাম যত বড়ই হোক না কেন তা যেন তার কাজের সাথে সম্পৃক্ত হয়।

Inconsistent name:
কোড করার সময় ক্লাস বা মেথড যেটাই হোক না কেন একই ধাঁচে কোড করতে হবে। তাতে কোড পড়ে বোঝা যায়। যদি একটা কোডের শুরু হয় Open() দিয়ে তা যেন Close() দিয়ে শেষ হয়, শেষ করার জন্য যেন Terminate() বা Quit() ব্যাবহার না করা হয়। এতে কোডের ধারা বজায় থাকে।

Dead code:
যে সকল কোড সিস্টেমে ব্যাবহার করা হয় নাই বা হবেও না, ঐ কোড ফেলে দেয়া ভাল। পরে কি হবে তা ভেবে এখনই কোডের বস্তা তৈরি করার দরকার নাই।

Speculative generality:
কোড সবসময় আজকের প্রব্লেমের সলভ করার কথা চিন্তা করে লিখতে হবে। শুধুমাত্র তখনি ভবিষ্যতের কথা চিন্তা করতে হবে যখন আমরা জানব যে পরে কি করতে হবে। অযথা পরের কথা চিন্তা করে কোড করলে কোড অনেক জটিল হয়ে যাবে। আর এমনতো না পরে কোড করতে হলে তা করা যাবে না। সফটওয়্যার ডেভেলপমেন্টে একটা কথা আছে
You ain’t gonna need it
Oddball solution:
এক ধরনের প্রব্লেম সলভের জন্য যদি একই সিস্টেমে অনেক ভাবে কোড করা থাকে, তবে যে কোন পরিবর্তনের জন্য সব যায়গায় পরিবর্তন করতে হবে। আর বিভিন্ন ক্ষেত্রে তার আউটপুট আসবে বিভিন্ন। তাই একটা সিস্টেমে সবসময় এক ধরনের প্রব্লেমের সল্যুশন সবসময় একটাই হওয়া উচিত।

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

Switch statement:
যদি একটা অবজেক্টে বা মেথডে অনেক switch-case বা if…else if…else if…else এর লম্বা চেইন থাকে, অনেক সময় দেখা যায় সবগুলো কন্ডিশনাল ব্লকে প্রায় একই রকম কাজ করা হয়, যা অবজেক্ট অরিয়েন্টেড প্রিন্সিপালকে ব্যাহত করে। এই কন্ডিশনাল ব্লকে দেখা যায় কোড ডুপ্লিকেশন ব্যাবহার করা হয়, যা অনেক সহজেই পলিমরফিজম দিয়েই করা সম্ভব।

Comments

Post a Comment

Popular posts from this blog

Code Smell বা বাজে কোড

Code Smell বা বাজে কোড বোঝার কিছু প্যাটার্ন আছে যা দেখে বোঝা যায়। এখানে এই সম্পর্কে কিছু ধারনা দেয়া হল। code smell সাধারনত ২ ভাগে বিভক্ত। Code smells within classesCode smells between classesCode smells between classes দুই বা ততোধিক ক্লাসের মধ্যে সাধারনত কি ধরনের কোড স্মেল হয়ে থাকে এখানে তাই বর্ননা করা হয়েছে। নাম গুলি ইংরেজিতেই রাখা আছে যাতে সরাসরি ইংরেজি নাম দিয়ে গুগল করলেই সব ধরনের রিসোর্স পাওয়া যায়। Alternative classes with different interfaces: দুইটা মানুষের ভিতরে সবকিছুই এক, শুধু চেহারা ছাড়া মানে যদি দুইটা ক্লাসের ভেতরের স্ট্রাকচার একই হয় কিন্তু বাহিরের আউটলুক ভিন্ন হয় বা যদি ইন্টারফেস আলাদা হয়, সেক্ষেত্রে দুইটা ক্লাসই একটা ইন্টারফেস শেয়ার করতে পারে।

Java Heap Dump

Overview A heap dump is a snapshot of all the objects that are in memory in the JVM at a certain moment. They are very useful to troubleshoot memory-leak problems and optimize memory usage in Java applications.
Heap dumps are usually stored in binary format hprof files.