পরিচালনা করার অংশগুলিতে অবিচ্ছিন্ন কোডটি ভাঙ্গার সর্বোত্তম উপায়?


13

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

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

আমি জানি যদি আমি আমার সমস্যাগুলি ছোট ছোট করে ফেলতে পারি তবে আমি সহজেই সম্পাদন করতে সক্ষম হব। একটি কৌশল যা মাথায় আসে তা হ'ল পরীক্ষা-চালিত বিকাশ। আমি আর কী করতে পারেন?


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

2
পড়ুন refactoring (জালিয়া) এবং নকশা নিদর্শন (GoF) । এই প্রশ্নটি সত্যিই জিজ্ঞাসা করছে "আমি কোড কীভাবে গঠন করব?" এবং যদি আপনি এটি জিজ্ঞাসা করেন, আপনি ভ্রমণের জন্য দীর্ঘ রাস্তা পেয়েছেন ; এমনকি অর্ধেক এমনকি আপনাকে দিতে একটি একা প্রশ্নোত্তর থ্রেডের উপর নির্ভর করবেন না।
অ্যারোনআট

উত্তর:


13

কোড সম্পর্কে চিন্তাভাবনা বন্ধ করুন

স্তর, বৈশিষ্ট্য, মডিউল, পরিষেবাদি এবং অন্যান্য উচ্চ-স্তরের বিমূর্ততা সম্পর্কে চিন্তাভাবনা শুরু করুন

আপনি অভিভূত হচ্ছেন কারণ আপনি খুব কম স্তরে চিন্তা করছেন


9

জটিলটিকে সহজ করে তোলা সহজ ; অন্যদিকে ভাবুন এটি অপেক্ষা করুন।

প্রত্যেকেই এর সাথে লড়াই করে, এমন কোনও সরল সমাধান নেই যার চূড়ান্ত কার্যকারিতা রয়েছে।

যেহেতু আপনি আপনার প্রশ্নগুলিতে এটি তালিকাভুক্ত করেননি, আমার পরামর্শটি হ'ল:

এর মাধ্যমে ক্রিয়ামূলক সংহতিতে ফোকাস করুন :

একক দায়িত্বের নীতিতে বলা হয়েছে যে প্রতিটি বস্তুর একটি একক দায়িত্ব থাকা উচিত এবং সেই দায়িত্ব পুরোপুরি শ্রেণীর দ্বারা আবশ্যক। এর সমস্ত পরিষেবা সংকীর্ণভাবে সেই দায়িত্বের সাথে সামঞ্জস্য করা উচিত।

আপনি যদি প্রথম পৃষ্ঠার ফলাফলগুলির মধ্যে এটি গুগল করেন তবে আপনি দুটি দুর্দান্ত সংস্থান পাবেন:

  • রবার্ট সি মার্টিনের " একক দায়িত্বের নীতি " (ফেব্রুয়ারি / 2002): এই নীতিটি বিভিন্ন শ্রেণিতে বিভিন্ন কারণে পরিবর্তিত জিনিসগুলি রাখার প্রয়োজনীয়তার বিষয়ে আলোচনা করে।
  • জেফ অ্যাটউড (মার / 2007) লিখেছেন " কোঁকড়ানো আইন: এক জিনিস ": একক দায়িত্বের নীতিটি বলে যে একটি শ্রেণীর পরিবর্তনের কারণ থাকতে পারে এবং তার একটি মাত্র কারণ থাকতে হবে।

কম্পিউটার বিজ্ঞানে সংহততা কী?

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

সংহতি হ্রাস হয় যদি : - একটি ক্লাসে এম্বেড করা ক্রিয়াকলাপগুলি, এর পদ্ধতিগুলির মাধ্যমে অ্যাক্সেস করা হয়, খুব সামান্য থাকে। - পদ্ধতিগুলি প্রায়শই মোটা দানাদার বা সম্পর্কিত সম্পর্কিত ডেটা ব্যবহার করে অনেকগুলি বিচিত্র ক্রিয়াকলাপ চালায়।

কম সংহতি (বা "দুর্বল সংহতি") এর অসুবিধাগুলি: - মডিউলগুলি বুঝতে অসুবিধা বৃদ্ধি পেয়েছে। - একটি সিস্টেম বজায় রাখতে অসুবিধা বৃদ্ধি পেয়েছে কারণ ডোমেনে যুক্তিসঙ্গত পরিবর্তনগুলি একাধিক মডিউলকে প্রভাবিত করে এবং একটি মডিউলে পরিবর্তনের জন্য সম্পর্কিত মডিউলগুলির পরিবর্তন প্রয়োজন। - মডিউলটিকে পুনরায় ব্যবহার করতে অসুবিধা বৃদ্ধি পেয়েছে কারণ বেশিরভাগ অ্যাপ্লিকেশনগুলিকে মডিউল দ্বারা সরবরাহিত এলোমেলো সংক্রমণের প্রয়োজন হবে না।

তোমার যদি কোনো প্রশ্ন থাকে তবে আমাকে জানাও.


1

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


1

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


0

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

মূল কথাটি হ'ল বেশিরভাগ প্রোগ্রামাররা মাঝারি স্তরের উপরে উঠতে লড়াই করবে, কিছু লোক ঠিক আছে বলে পরিচালনা করবে (যা আমি নিজেকে এবং সম্ভবত ৫০% পেশাদার প্রোগ্রামারকে আইবি শিল্পে রাখব), এবং খুব ছোট সংখ্যালঘু দুর্দান্ত হবে। আমার বলা উচিত যে আমার দীর্ঘ ক্যারিয়ারে আমি কখনই এই চমকপ্রদ ব্যক্তির সাথে দেখা করতে পারি নি :-)


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

1
একটি গাভী এর +1 @The মুখ: একমত, এবং তাই করে পিটার Norvig , গবেষণা Google এর পরিচালক, যিনি একটি "চমৎকার" প্রোগ্রামার: শেখান দশ বছর নিজেকে প্রোগ্রামিং
সাঙ্ঘাতিক ভুল

1
@ ব্লন্ডার্স - একটি ভাল নিবন্ধ। এটি নোংরা ছোট্ট গোপন বিষয় যা বিপণনের পুরুষরা আমাদের বলতে চান না (অবশ্যই সেগা বাদে)। অনুশীলন, অনুশীলন, অনুশীলন। এটা তোলে কল্পনানুসারে খুব জাপানি জন্য কাজ করে alljapaneseallthetime.com/blog

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

0

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

বিশেষীকৃত ক্লাসগুলি মন্দ নয়, এগুলি সাউন্ড সফ্টওয়্যার ডিজাইনের প্রাকৃতিক পরিণতি।

অনেক প্রোগ্রামার, আমার মতে, এটি বুঝতে ব্যর্থ হয়েছে এবং এমন কোনও বই নেই যা আমি জানি যা এটি একেবারে পরিষ্কার করে দেয়।

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

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

প্যাটার্নের বুদ্ধিমান ব্যবহার আপনাকে যে পরিমাণ বিশদ পরিচালনা করতে হবে তা হ্রাস করবে।

আপনার খুব প্রয়োজনের জন্য ডিজাইন করা একটি ভাল ডিজাইনের প্যাটার্ন লাইব্রেরি অমূল্য প্রমাণিত হবে। আসুন বিষয়গুলিকে প্রসঙ্গে রাখার জন্য খুব সহজ উদাহরণটি দেখুন:

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

আশা করি এটি আপনার বোধগম্য হবে!

অ্যান্ড্রিয়া


উপায় দ্বারা, শুধু এটা স্পষ্ট করতে: আমি বন্য ক্লাস, gremlins মত ক্রমবর্ধমান বরং শুধু একটি খোশগল্প আরো ব্যবহারিক অর্থে :) প্রচার করছি না
অ্যান্ড্রিয়া Raimondi

0

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

কিছু সহজ পদক্ষেপ যা আমাকে সাহায্য করেছে

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

আমি সেই বিষয়টিকেই সমর্থন করছি। আমি যা মনে করি তা হ'ল বিমূর্ততা এবং বিশেষীকরণের মধ্যে একটি ভারসাম্য থাকতে হবে: অত্যধিক স্পেশালাইজেশন অত্যধিক বিমূর্ততা হিসাবে খারাপ।
আন্দ্রেয়া রায়মন্ডি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.