পর্যালোচনা চলাকালীন আমি কীভাবে অন্যের খারাপভাবে ডিজাইন করা কোডটিতে দক্ষতার সাথে উন্নতির পরামর্শ দিতে পারি?


130

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

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


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

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

5
প্রশ্নটি এটিকে শোনায় যেন পরীক্ষার কাজ শেষ হওয়ার পরে কোড পর্যালোচনাটি ঘটছে । যদি তা হয় তবে আপনি পরীক্ষার সময় নষ্ট করছেন (যে কোনও পরিবর্তন পুনরায় পরীক্ষা করা দরকার) বা কোড পর্যালোচনা (ইতিমধ্যে কাজ করে এমন কোডটি কেন পরিবর্তন করবেন?) এর ফলে পরিবর্তনগুলি করা খুব কঠিন করে তুলছেন?
ওয়াগানড্রয়েড

3
@ বাউকেটা - কেন কোড পর্যালোচনা করবেন এবং একাধিক লোকের সময় নষ্ট করবেন যখন আপনার যদি এখনও কাজ করে না তবে আপনার কোনও ধারণা নেই?
ডাঙ্ক

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

উত্তর:


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

  2. প্রকল্পের কোডের প্রতিটি লাইন একটি লাইন যা বজায় রাখতে হয়। কোডটি কাজটি করা এবং সহজেই বোঝার জন্য যতক্ষণ হওয়া দরকার তত দীর্ঘ হওয়া উচিত এবং আর নেই। আপনি যদি স্বচ্ছতা ছাড়াই কোডটি সংক্ষিপ্ত করতে পারেন তবে এটি ভাল। আপনি যদি স্বচ্ছতা বাড়ানোর সময় এটি করতে পারেন তবে এটি আরও ভাল।

  3. কোডটি কংক্রিটের মতো: কিছুক্ষণ বসে থাকার পরে এটি পরিবর্তন করা আরও কঠিন। আপনি যদি পারেন তবে আপনার পরিবর্তে তাড়াতাড়ি পরামর্শ দিন, যাতে পরিবর্তনের ব্যয় এবং ঝুঁকি দুটোই কমে যায়।

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

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

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

উপরের সমস্ত বিষয়গুলির সংক্ষিপ্তসার জন্য: আপনার প্রস্তাবিত পরিবর্তনগুলি মান যুক্ত করেছে তা নিশ্চিত করুন।


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

4
আপনার নিজের অনুপ্রেরণা বোঝা কেবল বিক্রয় নয়। আপনি কেন কিছু কৌশল পছন্দ করেন তা বুঝতে হবে এবং অন্যগুলিও নয়, তাই আপনার থাম্বের বিধিগুলি কখন কার্যকর এবং কখন তা নয় তা আপনি জানতে পারবেন। ভুল পরিস্থিতিতে সঠিক প্রযুক্তি প্রয়োগকারী অভিজ্ঞ প্রোগ্রামারদের কাছ থেকে অনেকগুলিই উত্থাপিত হয়।
জারজেন ফোগ 9

1
আপনার পয়েন্টগুলি দেখে মনে হচ্ছে গল্ফিং ঠিক আছে ... :-)
ফ্লোরিয়ান মার্জাইন

2
পুরো উত্তরটির জন্য +1 তবে বিশেষত "যদি কোডটি অগোছালো হয় তবে এর মধ্যে
বাগগুলিও

2
(6) নির্দেশ করার তাত্পর্যপূর্ণ, আকর্ষণীয়ভাবে মনে হচ্ছে ইন্টারফেসের মান বাস্তবায়নের মানের চেয়ে বেশি গুরুত্বপূর্ণ
ব্র্যাড থমাস

16

রিফ্যাক্টরিংয়ের মাধ্যমে মান যুক্ত করার জন্য একটি মিষ্টি স্পট রয়েছে। পরিবর্তনগুলি তিনটি জিনিস সম্পাদন করা প্রয়োজন:

  • কোডটি উন্নত করুন যা সম্ভবত পরিবর্তন হতে পারে
  • স্পষ্টতা বৃদ্ধি
  • সর্বনিম্ন প্রচেষ্টা ব্যয়

বিবেচ্য বিষয়:

  1. আমরা জানি যে ক্লিন কোডটি লিখতে এবং বজায় রাখতে কম ব্যয়বহুল এবং এতে কাজ করতে আরও মজাদার। আপনার কাজটি আপনার সংস্থার লোকদের কাছে সেই ধারণা বিক্রি করা। অহঙ্কারী গ্রুচের মতো নয় (যেমন আমার মতো নয়) বিক্রয়কর্মীর মতো ভাবেন Think
  2. আপনি জিততে পারবেন না, আপনি কেবল কম শিথিল করতে পারেন।
  3. শুধু সৌন্দর্য নয় - আসল মান যুক্ত করার দিকে মনোনিবেশ করুন। আমি আমার কোডটি দেখতে দেখতে পছন্দ করি তবে মাঝে মাঝে সেই ব্যয়বহুল বিষয়গুলি আরও মেনে নিতে হয়।
  4. মিষ্টি স্পট সন্ধানের একটি ভাল উপায় বয় স্কাউট নীতি অনুসরণ করা - আপনি যখন কোনও কোডের ক্ষেত্রে কাজ করেন তখন সর্বদা এটি খুঁজে পাওয়ার চেয়ে ভাল আকারে রেখে যান।
  5. একটি ছোট উন্নতি কোনও উন্নতির চেয়ে ভাল।
  6. স্বয়ংক্রিয় সরঞ্জামগুলির ভাল ব্যবহার করুন। উদাহরণস্বরূপ, যে সরঞ্জামগুলি কেবলমাত্র কিছুটা ফর্ম্যাটিং পরিষ্কার করে তা বিশ্বকে আলাদা করতে পারে ।
  7. ঘটনাক্রমে কোডের স্বচ্ছতা উন্নত করে এমন অন্যান্য ধারণা বিক্রি করুন। উদাহরণস্বরূপ, ইউনিট টেস্টিং বড় পদ্ধতিগুলিকে ছোট ছোটগুলিতে দ্রবীভূত করতে উত্সাহ দেয়।

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

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

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

14

যদি গুরুতর ত্রুটিযুক্ত কোডগুলি ছাড়াই কোড কাজ করে এবং একটি বড় সময়সীমা (যেমনগুলি পিএন্ডএল বা কর্পোরেট পিআর হিসাবে কার্যকর) আসন্ন হয় তবে বড় পরিবর্তনগুলির প্রয়োজন এমন উন্নতিগুলির পরামর্শ দিতে খুব দেরী হয়। এমনকি কোডের উন্নতিগুলি প্রকল্প স্থাপনার ঝুঁকি তৈরি করতে পারে। উন্নয়নের জন্য সময়টি আগে প্রকল্পে ছিল, যখন কোড বেসের ভবিষ্যতে দৃust়তায় বিনিয়োগ করার জন্য আরও সময় ছিল।


যদি আপনি সেখানে শেষ হয়ে থাকেন তবে সেই প্রক্রিয়াগুলি যে পয়েন্টে পৌঁছেছে সম্ভবত আপনাকে ব্যর্থ করেছে।
টিম আবেল

9

কোড পর্যালোচনা 3 উদ্দেশ্যে পরিবেশন করে:

  1. বাগের জন্য অনুসন্ধান করা হচ্ছে

  2. কোডটি কোথায় উন্নত করা যায় তা পরীক্ষা করা হচ্ছে

  3. কোড লিখেছে যার জন্য শিক্ষণ সরঞ্জাম।

মূল্যায়ন ডিজাইন / কোড মানের অবশ্যই # 2 এবং # 3 প্রায়।

যতক্ষণ না # 2:

  • প্রস্তাবিত পরিবর্তনগুলি থেকে ফিক্সগুলি ব্যয় করার সুবিধা কী কী তা এটিকে খুব পরিষ্কার করে দিন। যে কোনও ব্যবসায়ের সিদ্ধান্ত হিসাবে, এটি ব্যয় / উপকার বিশ্লেষণ সম্পর্কে হওয়া উচিত।

    উদাহরণস্বরূপ "ডিজাইনের এক্স এক্স পদ্ধতির সাহায্যে জেড পরিবর্তন করার সময় বাগ ওয়াইয়ের সম্ভাবনা উল্লেখযোগ্যভাবে হ্রাস পাবে এবং আমরা জানি যে এই কোডের টুকরোটি প্রতি 2 সপ্তাহে জেড টাইপের পরিবর্তনের মধ্য দিয়ে যায় bu বাগ ওয়াই থেকে উত্পাদনের ব্যয় হ্যান্ডল করার ব্যয় + বাগ খুঁজে পাওয়া যায় finding + ফিক্সিংয়ের পরবর্তী সেটটি সরবরাহ না করা থেকে ফিক্সিং এবং সুযোগ মুক্তকরণ হ'ল $Aএখন কোড সাফ করার ব্যয় এবং সুযোগ ব্যয় (যেমন দেরীতে বা কম বৈশিষ্ট্য সহ শিপিংয়ের মূল্য) $Bএখন Now মূল্যায়ন করুন - বা বরং আপনার দলের নেতা / পরিচালক থাকতে পারে - $Aবনাম মূল্যায়ন করুন $Bএবং সিদ্ধান্ত নিন।

    • এটি কার্যকরভাবে পরিচালনা করতে স্মার্ট দলকে সাহায্য করবে। উদাহরণস্বরূপ তারা সম্পূর্ণ তথ্য ব্যবহার করে যুক্তিসঙ্গত সিদ্ধান্ত নেবে

    • এটি (বিশেষত যদি আপনি এটি ভালভাবে বলে থাকেন) আপনার মর্যাদা বাড়িয়ে তুলবে - যেমন আপনি আরও ভাল ডিজাইনের সুবিধা দেখতে যথেষ্ট বুদ্ধিমান এবং ব্যবসায়ের বিবেচনার বিষয়টি বিবেচনা না করে ধর্মীয়ভাবে এটির দাবি না করার পক্ষে যথেষ্ট স্মার্ট।

    • এবং, বাগ জেড হওয়ার সম্ভাব্য ইভেন্টে, আপনি পরবর্তী পরামর্শের সেটটিতে আরও অনেক বেশি লাভ পান।

যতক্ষণ না # 3:

  • "স্পষ্টতই" বাগ / ইস্যুগুলি "থেকে" সমাধান করতে হবে "এটি একটি সর্বোত্তম অনুশীলন এবং সত্যই ঠিক করা উচিত যদি আমরা সংস্থানগুলি বাঁচাতে পারি - সংযুক্ত প্রো / কন বিশ্লেষণ" নকশার উন্নতিগুলি দেখুন (উপরে # 2 এর জন্য বর্ণিত স্টাফ সংযুক্ত করুন) বনাম " এগুলি সাধারণ নির্দেশিকা যা আমার মনে হয় আপনি আপনার কোড দৃust়তার উন্নতি করতে সহায়তা করবেন যাতে আপনি কোডটি "easilyচ্ছিক পরিবর্তনগুলি আরও সহজেই বজায় রাখতে পারেন। দয়া করে শব্দটি নোট করুন - এটি "আপনার কোডটি আমি যা চাই তা তৈরি করার বিষয়ে নয়" - এটি "যদি আপনি এটি করেন তবে আপনি a, b, c" উপকার পাবেন। সুর ​​এবং পদ্ধতির বিষয়টি গুরুত্বপূর্ণ।

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

1
@ কালেব - ভাল পয়েন্ট আমি খুব বেশি পয়েন্ট বানাতে চাইনি, সুতরাং এটি একটি রূপরেখা থেকে সম্পাদিত হয়ে গেছে তবে এটি এখনও একটি বৈধ পয়েন্ট।
ডিভি কে

# 4 ক্রস প্রশিক্ষণ বিকাশকারীদের নতুন বৈশিষ্ট্যগুলিতে
জুয়ান মেন্ডেস

1
# 5 - কোড পর্যালোচনার মূল উদ্দেশ্যটি হ'ল নকশা নথিটি
কার্যকরভাবে

8

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

অতিরিক্ত কাজ করার আগে তাদের মানটি দেখতে হবে।


5
দিগন্ত সর্বদা দিগন্তে থাকে না?
ফ্রিএএসআইনবিয়ার

8

আমি সবসময় আমার মন্তব্যটি "আমি চাই" দিয়ে শুরু করি, যা ইঙ্গিত দেয় যে খালি আমার অনেক মতামতের মধ্যে একটি।

আমি সবসময় একটি কারণ অন্তর্ভুক্ত।

" পঠনযোগ্যতার কারণে আমি এই ব্লকটি একটি পদ্ধতিতে বের করব " "

আমি সব বিষয়ে মন্তব্য; বড় ও ছোট. কখনও কখনও আমি পরিবর্তনের উপর শতাধিক মন্তব্য করি, সেক্ষেত্রে আমিও জোড়-প্রোগ্রামিংয়ের পরামর্শ দিই এবং নিজেকে উইং-ম্যান হিসাবে প্রস্তাব করি।

আমি কারণে একটি সাধারণ ভাষা প্রতিষ্ঠার চেষ্টা করছি; পঠনযোগ্যতা, ডিআরওয়াই, এসআরপি, ইত্যাদি

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

তবে কিছু লোক যেভাবেই শুনবে না। তারপরে আমি টান র‌্যাঙ্ক দিয়েই চলেছি আমি ডিজাইনের লিড। কোড মানের আমার দায়িত্ব। এই পরিবর্তনটি আমার বর্তমান সময়ে তার বর্তমান অবস্থায় দেখা যাবে না।

দয়া করে মনে রাখবেন যে আমি যে কোনও মন্তব্য করতে চাইলে আমি তার চেয়ে বেশি প্রস্তুত থাকতে চাই; প্রযুক্তিগত কারণে, সময়সীমা, প্রোটোটাইপ ইত্যাদির জন্য আমার কাছে এখনও কোডিং সম্পর্কে শিখার অনেক কিছুই রয়েছে এবং সর্বদা কারণ শুনব to

ওহ, এবং আমি সম্প্রতি আমার টিমের প্রথম একজনের কাছে মধ্যাহ্নভোজটি কিনে দেওয়ার প্রস্তাব দিয়েছিলাম, যিনি একটি অ-তুচ্ছ পরিবর্তন জমা দিয়েছেন যার বিষয়ে আমার কোনও মন্তব্য নেই। (আরে, আপনারও মজা করতে হবে: :-)


5

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

এই কোডটি সম্পন্ন হয়েছে। একটি নির্দিষ্ট সময়ে, পুনরায় ডিজাইনগুলি ন্যায়সঙ্গত করতে খুব ব্যয়বহুল হয়ে যায়। কোডটি যদি ইতিমধ্যে সামান্য থেকে কোনও বাগ সহ কার্যকর হয় তবে এটি একটি অসম্ভব বিক্রি হবে। ভবিষ্যতে এটি পরিষ্কার করার জন্য কয়েকটি উপায়ের পরামর্শ দিন on যদি / ভবিষ্যতে কোডটি বিভক্ত হয়, তখন পুনরায় ডিজাইনের মানটি পুনরায় মূল্যায়ন করুন। এটি কখনও ভেঙে না যেতে পারে, যা দুর্দান্ত হবে। যে কোনও উপায়ে আপনি সেই মুহূর্তে পৌঁছে গেছেন যে জুয়া খেলতে এটি অনুভূত হয় যে এটি ভাঙবে না, যেহেতু এখন বা পরে ব্যয় একই হবে: টানা-আউট, ভয়ানক নতুন ডিজাইন।

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

দুটি বিকল্পের মধ্যে পছন্দ (রিফ্যাক্টর বা কোনও রিফ্যাক্টর) দেওয়া না হওয়া সম্পর্কে, স্মার্ট বিক্রির মতো কোন শব্দগুলির বিষয়ে চিন্তা করুন:

আরে বস, আমরা সময়সূচীতে ছিলাম এবং সবকিছু কাজ করছিলাম, তবে এখন আমরা প্রচুর পরিমাণে পুনর্নির্মাণ করতে যাচ্ছি যাতে আমরা ভবিষ্যতে এক্স বৈশিষ্ট্যটি যুক্ত করতে পারি।

অথবা

আরে বস, আমরা মুক্তি দিতে প্রস্তুত। আমাদের যদি কখনও এক্স বৈশিষ্ট্য যুক্ত করতে হয় তবে এটি আমাদের আরও কয়েক দিন সময় নিতে পারে।

আপনি যদি একজনকে বলে থাকেন তবে আপনার বস সম্ভবত বলবেন:

এক্স ফিচার সম্পর্কে কে কিছু বলেছেন?

মূল কথাটি হ'ল কখনও কখনও প্রযুক্তিগত debtণ কিছুটা বোঝায় যে আপনি যদি কিছুটা ত্রুটিগুলি সস্তা করার সময় ফিরে (সংক্ষিপ্ত পুনরাবৃত্তি) ফিরিয়ে দিতে সক্ষম না হন। আপনি একটি সম্পন্ন বৈশিষ্ট্য এবং শেষ সময়সীমার কাছাকাছি আসার সাথে সাথে মানের কোড ডিজাইন থাকার আয় হ্রাস পাচ্ছে।



কীভাবে: "আরে বস, আপনি যে বৈশিষ্ট্যটি X চান তা জানেন, ভাল, আমরা এটিতে কাজ শুরু করার কয়েক দিন আগে আমাদের প্রয়োজন" " সে তাও পছন্দ করবে। YAGNI অগোছালো কোড তৈরি করার বা কোডকে অগোছালো ছেড়ে দেওয়ার বাহানা নয়। সামান্য প্রযুক্তিগত debtণ একটি বড় সমস্যা নয়, তবে debtsণ অবশ্যই শোধ করতে হবে, আপনি যত তাড়াতাড়ি এটি শোধ করবেন, এটি সস্তা হবে।
থারসাল

5

[এই উত্তরটি মূলত উত্থাপিত প্রশ্নের চেয়ে কিছুটা বিস্তৃত, যেহেতু কোড রিভিউগুলিতে এটি এতগুলি অন্যান্য প্রশ্নের পুনর্নির্দেশ is

আমি দরকারী বলে মনে করি এমন কিছু নীতি এখানে দেওয়া হল:

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

আপনার নিজের ভুল শেয়ার করুন। আমি আমার বিপর্যয়কর প্রথম কোড পর্যালোচনা (প্রাপ্ত) এর গল্পটি ছাত্র এবং জুনিয়র সহকর্মীদের সাথে ভাগ করি। আমি ছাত্রদেরও জানাতে পারি যে আমি তাদের বাগটি এত তাড়াতাড়ি ধরলাম কারণ আমি নিজের আগে এটি তৈরি করেছি। একটি কোড পর্যালোচনাতে, এটি এ হিসাবে প্রকাশিত হতে পারে: "আমি মনে করি আপনি এখানে সূচক ভেরিয়েবলগুলি ভুল পেয়েছিলেন always [হ্যাঁ, এটি একটি সত্য গল্প]

ইতিবাচক মন্তব্য করতে ভুলবেন না। একটি সংক্ষিপ্ত "সুন্দর!" বা "ঝরঝরে কৌশল!" একটি জুনিয়র বা অনিরাপদ প্রোগ্রামার এর দিন করতে পারেন।

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

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

এখানে চিত্র বর্ণনা লিখুন WTFs / মিনিট


4

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

আমি ভাবছি যদি এটি আরও ভাল হত ...

অথবা

এটি কি কোনও অর্থ দেয় ...

কারণগুলি যদি মোটামুটি সুস্পষ্ট হয় তবে আমি সেগুলি উল্লেখ করি না। এটি অন্যান্য ব্যক্তিকে পরামর্শ হিসাবে কিছু বৌদ্ধিক মালিকানা ধরে নেওয়ার সুযোগ দেয়:

"হ্যাঁ, এটি একটি ভাল ধারণা, কারণ < এখানে আপনার স্পষ্ট কারণ " "

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

আমি অবাক হই ... এখানে কোনও উপায় নেই <<ভাগ করে দেওয়া মান বিবৃতি>

এটি কেবল সত্যিকারের স্পর্শকাতর লোকদের সাথেই কাজ করার জন্য - আমার বেশিরভাগ সমবয়সীদের সাথে, আমি কেবল এটিই পেতে পারি!


1
এটি বিরল যে আমি বলব "আমি ভাবছি যদি এটি ভাল হত ..."। আমি কেবল এটিই বলতাম যে আমি নিশ্চিত না হলে - যে ক্ষেত্রে লেখক এটি ভাবতে নির্দ্বিধায় ছিলেন কিনা এটি ভাল বা না এবং পরিবর্তন করতে বা মুক্ত কিনা তা মুক্ত। আমি সাধারণত "আমি এক্স করব" বলি। (কখনও কখনও আমি বলব "আমি এক্স করতাম তবে আপনার পদ্ধতির চেয়ে ভাল")। যার অর্থ আমি মনে করি এক্স আরও ভাল তবে আপনি একমত হতে পারেন না। অথবা আমি বলব "এটি কাজ করে না" বা "এটি বিপজ্জনক" এবং আপনি এটি আরও ভাল পরিবর্তন করতে পারেন। কখনও কখনও আমাকে বলা হয় "এটি কাজ করে না", এবং সাধারণত আমি কোডটি দেখি, আমি "ওহ ছি ছি" বলি, এবং তারপরে আমি এটি ঠিক করি।
gnasher729

3

কোড পর্যালোচনা সবসময় উন্নতি করার লক্ষ্য নয়।

প্রকল্পের শেষের নিকটবর্তী পর্যালোচনাটি এখানে যেমন মনে হয় ঠিক তেমনই যাতে বাগগুলি কখন আসবে তা কোথায় শুরু করা যায় তা (বা পরে পুনরায় ব্যবহারের জন্য উপলভ্য আরও ভাল নকশাকৃত প্রকল্পের জন্য) সবাই জানতে পারে knows পর্যালোচনার ফলাফল যাই হোক না কেন, কিছু পরিবর্তনের সময় নেই।

প্রকৃতপক্ষে পরিবর্তনগুলি করার জন্য আপনাকে প্রকল্পের কোড এবং ডিজাইনের অনেক আগে আলোচনা করা দরকার - কোডটি সম্ভাব্য পদ্ধতির বিষয়ে আলোচনা হিসাবে উপস্থিত থাকলেই পরিবর্তন করা অনেক সহজ easier


3

আপনার প্রশ্নটি "খারাপভাবে ডিজাইন করা কোড পর্যালোচনা কীভাবে করবেন?":

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

যদি কোডটি "কার্যকরীভাবে পর্যাপ্ত" হয় এবং / অথবা "স্পেক পূরণ করে" এবং / অথবা "প্রয়োজনীয়তা পূরণ করে":

আপনি যদি এই বিকাশকারীর সমবয়সী হন তবে আপনার কাছে এমন কোনও সরাসরি শক্তি নেই যা আপনাকে পরিবর্তন করতে "তাকে" বলতে দেয়।

আপনার কাছে কয়েকটি বিকল্প বাকি রয়েছে:

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

আমি দেখতে পাই কোন রুপোর বুলেট নেই। আপনাকে তিনটিই ব্যবহার করতে হবে এবং আপনার তিনটি ব্যবহারেই আপনাকে সৃজনশীল হতে হবে।


আমি আশা করি আমি # 3 শিখতে পারলাম, আমি খারাপ কোড নিয়ে এতটাই হতাশ হয়েছি যে এটি বুঝতে চেষ্টা করতে আমার খুব কষ্ট হয়েছে ... এটিতে নিয়মিত কাজ করা ....
জুয়ান মেন্ডেস

ডিজাইন ত্রুটিযুক্ত? কি ডিজাইন?
gnasher729

1

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

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

একবার আপনি উপাদানগুলির মধ্যে বাধা পেয়ে গেলে, বড় সমস্যাগুলির সম্ভাব্য উপাদানগুলিতে ফোকাস করুন।

সময়সীমা বা সিস্টেম "নিখুঁত" না হওয়া পর্যন্ত পুনরাবৃত্তি করুন।


1

কারও কোডের সরাসরি প্রত্যক্ষ সমালোচনা পরিবর্তে কোড পর্যালোচনা চলাকালীন আমাদের মন্তব্যে অভিনব হওয়া ভাল better

আমি অনুসরণ একটি উপায়

  1. আমরা যদি এভাবে এটি করি তবে এটি সর্বোত্তম হবে।
  2. এভাবে লিখলে তা দ্রুত চালিত হবে।
  3. আপনি যদি "এই" "এটি" এবং "এটি" করেন তবে আপনার কোডটি অনেক বেশি পঠনযোগ্য হবে

আপনার সময়সীমা সামনে আসার পরেও এই জাতীয় মন্তব্য গুরুত্ব সহকারে নেওয়া হবে। এবং সম্ভবত পরবর্তী উন্নয়ন চক্র কার্যকর করা হবে।


0

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

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


0

কোড পর্যালোচনার গুণমান বাড়ান।

পর্যালোচনাধীন কোডের গুণমান ছাড়াও কোড পুনর্বিবেচনার মান হিসাবে কিছু আছে:

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

বেশিরভাগ প্রশ্নবিদ্ধ অহং গ্রুমিংয়ের চেয়ে ভাল মানের কোড পর্যালোচনা গ্রহণ করা অনেক সহজ।


0

প্রশ্নটিতে দুটি উল্লেখযোগ্য বিষয় রয়েছে, কৌশলে অংশ এবং শেষ সময়সীমাটি অংশ অবতীর্ণ হওয়া । এগুলি স্বতন্ত্র সমস্যা - প্রথমটি যোগাযোগ এবং দল-গতিবিদ্যার প্রশ্ন, দ্বিতীয়টি পরিকল্পনা এবং অগ্রাধিকারের প্রশ্ন।

কৌশলে । আমি ধরে নিয়েছি আপনি পর্যালোচনাগুলির বিরুদ্ধে ব্রাশ করা ইওস এবং নেতিবাচক পুশব্যাক এড়াতে চান। কিছু পরামর্শ:

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

দ্বিতীয় অংশটি অগ্রাধিকার । উন্নতির জন্য আপনার কাছে অনেক পরামর্শ রয়েছে, তবে সময়সীমাটি যেহেতু নিকটে আসছে সেখানে কয়েকটি প্রয়োগের জন্য কেবল সময় রয়েছে।

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

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

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

যে অঞ্চলগুলি ইউনিট-পরীক্ষাগুলির আওতায় আসে তাদের ঝুঁকি কম থাকে। আপনি পরে সর্বদা এটি ঠিক করতে পারেন। যে অঞ্চলগুলি নয়, তবে যেগুলি ইউনিট-পরীক্ষিত হতে পারে সেগুলি অঞ্চলগুলির তুলনায় কম ঝুঁকিযুক্ত যা ইউনিট-পরীক্ষিত হতে পারে না

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

তবে দয়া করে প্রথমে এই দৃশ্যের অবসান এড়াতে চেষ্টা করুন!

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.