যখন অন্য ব্যক্তি অতিরিক্ত জটিল সমাধান তৈরি করেন তখন আপনি একটি কোড পর্যালোচনাতে কী বলবেন? [বন্ধ]


37

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

এই পরিস্থিতিতে আমি জিজ্ঞাসা করি "কেন এটি এভাবে করা হয়েছিল?"

উত্তরটি অন্য ব্যক্তিটি সেভাবে করার মতো অনুভূত হয়।

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

উত্তর না হয়।

সুতরাং আমি পরামর্শ দিচ্ছি যে তিনি সমস্ত অপ্রয়োজনীয় জটিলতা মুছে ফেলুন। আমি সাধারণত যে উত্তরটি পাই তা হ'ল এটি ইতিমধ্যে শেষ হয়ে গেছে।

আমার মতামতটি এটি করা হয় নি, এটি বাগিচা, এটি ব্যবহারকারীরা যা চায় তা করে না, এবং রক্ষণাবেক্ষণ ব্যয়টি আমি প্রস্তাবিত সহজ পদ্ধতিতে করা হলে তার চেয়ে বেশি হবে।

সমতুল্য পরিস্থিতি হ'ল:
কলেজীগ 8 ঘন্টা রিফ্যাক্টরিং কোড হাতে ব্যয় করে যা স্বয়ংক্রিয়ভাবে 10 সেকেন্ডের মধ্যে পুনঃভাগে করা যেতে পারে। স্বাভাবিকভাবেই আমি রিফ্যাক্টরিংটি হাতে হাতে বিশ্বাস করি না কারণ এটি সন্দেহজনক মানের এবং পুরোপুরি পরীক্ষিত নয়।
আবার আমি যে প্রতিক্রিয়া পেয়েছি তা হ'ল "ইতিমধ্যে এটি সম্পন্ন হয়েছে।"

এই মনোভাবের জন্য উপযুক্ত প্রতিক্রিয়া কী?


22
এখানে কেবল একটি কথা আছে

47
"আপনি একটি অত্যধিক জটিল সমাধান তৈরি করেছেন"
দান্তে

2
কোন সমস্যা এই প্রশ্নের কেন্দ্রবিন্দু: প্রোগ্রামার মানসিকতা / মনোভাব, প্রকল্প পরিচালনা (বিশেষত সময় পরিচালন), বা দক্ষতা স্তর?
rwong

6
এটি সম্ভবত কর্মক্ষেত্রে অন্তর্ভুক্ত - এটি কোনও প্রোগ্রামিং প্রশ্ন নয়।
গ্র্যান্ডমাস্টারবি

উত্তর:


25

মানসিকতা / মনোভাব

  • উদাহরণ দ্বারা নেতৃত্ব
  • ব্যক্তিগতভাবে উপদেশ দিন (একের একটিকে কোড পর্যালোচনার বাইরে)
  • দলের সদস্যদের মধ্যে এটি রাখুন-সহজ-মানসিকতা উত্সাহিত করুন

দল ব্যবস্থাপনা

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

দক্ষতা স্তর

  • বিকাশকারী সরঞ্জামগুলির সর্বোত্তম ব্যবহার করার জন্য জোড়া-প্রোগ্রামিং সেশনের জন্য এক-এক প্রশিক্ষণ সেশনের জন্য কিছু সময় বরাদ্দ করুন (রিফ্যাক্টরিং, কোড-পর্যালোচনা)

প্রকল্প (ঝুঁকি) পরিচালনা

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

69

যখন অন্য ব্যক্তি অতিরিক্ত জটিল সমাধান তৈরি করেন তখন আপনি একটি কোড পর্যালোচনাতে কী বলবেন?

আপনি বলেছেন: "আপনি একটি অত্যধিক জটিল সমাধান তৈরি করেছেন" "

সুতরাং আমি পরামর্শ দিচ্ছি যে তিনি সমস্ত অপ্রয়োজনীয় জটিলতা মুছে ফেলুন। আমি সাধারণত যে উত্তরটি পাই তা হ'ল এটি ইতিমধ্যে সম্পন্ন হয়েছে।

যদি কোনও কিছু পরিবর্তন করতে খুব দেরি হয় তবে আপনি কেন একটি কোড পর্যালোচনা করছেন?


আপনি মূলত বলছেন যে কোড পর্যালোচনা কেবল দুর্দান্ত, সর্বদা যুক্তিসঙ্গত এবং যুক্তিযুক্ত চরিত্রগুলির সাথে কাজ করে। আসল পৃথিবী অন্যরকম দেখাচ্ছে ...
ফিলিপ

3
কখনও কখনও আপনার পছন্দসই কাজগুলি করতে হয়, যেমন কোনও ব্যক্তি যিনি পুরো দিনের কাজকে জটিল কোড লেখার জন্য বলেছিলেন যে "এটি কোনও ভাল নয়, এটিকে আবার ঘুরিয়ে দিন এবং আবার শুরু করুন" বা lines লাইনগুলি সহ কিছু। এটি সফল হয় তবে আপনি কৃতজ্ঞ হন।
joshin4colours

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

30
+ ∞ "যদি কোনওভাবেই কিছু বদলাতে দেরি হয় তবে আপনি কোড পর্যালোচনা করছেন কেন?"
এমএসকিফিশার

16

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

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


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

+1 সরল সত্যের জন্য কোডটিতে (সুস্পষ্ট) বাগ রয়েছে এবং সুতরাং এটি পরীক্ষা করা হয়নি।
রামহাউন্ড

8

সুতরাং আমি পরামর্শ দিচ্ছি যে তিনি সমস্ত অপ্রয়োজনীয় জটিলতা মুছে ফেলুন। আমি সাধারণত যে উত্তরটি পাই তা হ'ল এটি ইতিমধ্যে শেষ হয়ে গেছে।

এটি একটি গ্রহণযোগ্য উত্তর নয়:

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

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

এবং ...

... সমাধানটি পুরোপুরি কার্যকর ছিল না ...

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

এখন, মনে হচ্ছে আপনার এ বিষয়ে "শক্তভাবে পিছনে চাপ দেওয়ার" শক্তি (বা সম্ভবত আত্মবিশ্বাস) নেই। তবে তা সত্ত্বেও, আপত্তিজনক কোডার আরও ভাল কাজ করবে ... এই আশায় এই সম্পর্কে (এটি ব্যক্তিগতকৃত না করে) কিছুটা আওয়াজ করা মূল্যবান।

এই মনোভাবের জন্য উপযুক্ত প্রতিক্রিয়া কী?

শেষ পর্যন্ত, এটিকে পরিচালনার নজরে আনুন ... যদি না আপনি নিজেরাই এটি ঠিক করার ক্ষমতা না রাখেন। (অবশ্যই, এটি আপনাকে জনপ্রিয় করে তুলবে না))


7

আপনি ঠিক বলেছেন, তারা ভুল ছিল:

  • ভাঙ্গা YAGNI নীতি
  • ভাঙ্গা KISS নীতি
  • কোডটি কি পুরোপুরি পরীক্ষিত? যদি না হয়, তবে এটি করা হয় না

এই মনোভাবের জন্য উপযুক্ত প্রতিক্রিয়া কী?

সঠিক কোড পর্যালোচনা করুন। যদি তারা কোনও কারণ ছাড়াই প্রস্তাবিত পরিবর্তনগুলি প্রয়োগ করতে অস্বীকার করে তবে আপনার একটি কোডের পর্যালোচনাগুলির সময় নষ্ট করা বন্ধ করুন। সমস্যাটি তাদের বসের কাছে বাড়িয়ে দিতে পারেন


5

আমাদের টিম একটি পদক্ষেপ নিয়েছিল, যা এই জাতীয় পরিস্থিতিতে পরিস্থিতিটি নাটকীয়ভাবে উন্নত করেছিল, তা ছিল অনেক ছোট পরিবর্তন থেকে স্থানান্তরিত করা ।

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

সুবিধাটি হ'ল, সমস্যাগুলি সনাক্ত করা হয় এবং তাড়াতাড়ি সমাধান করা যেতে পারে, ভুল পথে বড় পরিমাণে কাজ করার আগে।


আমি বলব যে এক দিনে 10 বার কিছুটা বেশি। আপনি যদি সত্যিই এটি ধাক্কা দিতে চান, 3 বা 4 টি চেকিন ঠিকঠাক হবে, এর অর্থ প্রতি 2 ঘন্টা গড়ে 8 ঘন্টা একটি সাধারণ সময় দেওয়ার জন্য একটি চেকিন। তবে 10 টি চেকিনগুলি দেখে মনে হচ্ছে যে রিভিউটির ভিত্তিতে আসলে কোনও কিছু পর্যালোচনা করা, ফিরে রিপোর্ট করা বা পরিবর্তনগুলি প্রয়োগ করার সময় নেই।
রামহাউন্ড

@ র‌্যামাউন্ড হ্যাঁ, 10 টি চেকইন একটি চরম ঘটনা, 3 থেকে 4 বার অনেক বেশি সাধারণ। এবং এর
অভ্যস্ত

2

আপনার সমস্যার মূল কারণের দিকে মনোনিবেশ করা উচিত:

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

(কোড পর্যালোচনায় এটি পরিবর্তন করতে ইতিমধ্যে খুব দেরি হয়ে গেছে)


2

কোড লিখিত হওয়ার পরে কাজ করে এমন কিছুই আমি জানি না।

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

ঠিকাদারদের সাথে কাজ করার মতো আরও একটি পদ্ধতি রয়েছে - স্থির-মূল্য চুক্তি। সমাধানটি যত সহজ, তত বেশি প্রোগ্রামার রাখে to


1

আপনি বিশ্বের ঠিক করতে পারবেন না।

এমনকি আপনি আপনার প্রকল্পের সমস্ত কোডও ঠিক করতে পারবেন না। আপনি সম্ভবত আপনার প্রকল্পের বিকাশের অনুশীলনগুলি ঠিক করতে পারবেন না, অন্তত এই মাসে নয়।

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

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

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


0

প্রকল্পে একটি স্ট্যান্ডার্ড নীতি থাকতে হবে যা সরবরাহযোগ্য মানের পরীক্ষার পদ্ধতি এবং ব্যবহৃত সরঞ্জামগুলি নিয়ন্ত্রণ করে।

এই প্রকল্পে ব্যবহারের জন্য লোকেরা তাদের কী করা উচিত এবং কোন সরঞ্জামগুলি গ্রহণযোগ্য তা জেনে রাখা উচিত।

আপনি যদি এখনও এটি না করে থাকেন, আপনার চিন্তাগুলি সংগঠিত করুন এবং এটি করুন।

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


0

আপনার দোকানে কিছু নকশা পদ্ধতি প্রয়োগ করা দরকার।

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

0

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

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

"এটি খুব জটিল" বললে আপনি কোথাও পাবেন না।


0

এটি দুর্ভাগ্যজনক, তবে কোড রিভিউগুলি বর্তমান সময়ের চেয়ে ভবিষ্যতের জন্য অনেক বেশি সময়। বিশেষত একটি এন্টারপ্রাইজ / কর্পোরেট পরিবেশে শিপড কোড সর্বদা আনশিপযুক্ত কোডের চেয়ে বেশি মূল্যবান।

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


0

অতি জটিল বলতে কী বোঝায়? আপনি একটি দ্ব্যর্থক বিবৃতি দেন তারপরে আপনি প্রতিক্রিয়াতে একটি দ্ব্যর্থক / অসন্তুষ্ট উত্তর পাবেন। একজন ব্যক্তির পক্ষে অতিরিক্ত জটিল যা অন্যজনের পক্ষে উপযুক্ত।

একটি পর্যালোচনার উদ্দেশ্য নির্দিষ্ট সমস্যা এবং ত্রুটিগুলি চিহ্নিত করা, আপনি এটি পছন্দ করেন না তা বলা নয়, যা "অতি-জটিল" বিবৃতিটি বোঝায়।

যদি আপনি কোনও সমস্যা দেখেন (অত্যধিক জটিল) তবে আরও কিছু কংক্রিটের মতো বলুন:

  • X তম অংশে Y পরিবর্তন করে কোড কী সরল করবে বা বুঝতে সহজ হবে না?
  • আপনি এখানে দশম অংশে কী করছেন তা আমি বুঝতে পারি না, আমি মনে করি আপনি যা করার চেষ্টা করছেন এটি এটি is এটি করার একটি পরিষ্কার উপায় উপস্থাপন করুন।
  • আপনি এই পরীক্ষা কিভাবে? আপনি এটি পরীক্ষা করেছেন? যদি এটি অত্যধিক জটিল হয় তবে এটি সাধারণত ফাঁকা ঘাটতির দিকে পরিচালিত করে। পরীক্ষার জন্য জিজ্ঞাসা করা তখন ঘন ঘন ব্যক্তিটিকে তাদের কোডটি স্ব-সরল করে তুলবে যখন তারা আসল কোডটি কীভাবে পরীক্ষা করতে হবে তা বুঝতে পারেনি।
  • এখানে একটি ত্রুটি আছে বলে মনে হচ্ছে, এতে কোড পরিবর্তন করা সমস্যার সমাধান করবে।

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


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

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

0

কখনও কখনও "চতুর" নীতিগুলির কয়েকটিতে মনোনিবেশ করা গোষ্ঠী হিসাবে এটি মূল্যবান - তারা এমন একটি গোষ্ঠী বা ব্যক্তিকে সহায়তা করতে পারে যাকে মনে হয় সামান্য দূরে বলে মনে হচ্ছে।

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

  • সম্ভবত সবচেয়ে সহজ কাজ যা কাজ করতে পারে?
  • আপনার এটি দরকার নেই (আপনি কি এমন সমস্যা সমাধান করছেন যা অনুমানের মধ্যে ছিল না)
  • কোডিংয়ের আগে পরীক্ষা লিখুন (আপনাকে আপনার কোডটি ফোকাস করতে সহায়তা করে)
  • নিজেকে পুনরাবৃত্তি করবেন না

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


0

বর্ধন, আপনার যদি কোনও প্রযুক্তিগত মনের পরিচালক থাকে। এটি এমন একটি অভ্যাসের মতো মনে হচ্ছে যা ভেঙে দেওয়া দরকার।

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

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


0

একটি শব্দ: চটপটে

এটি অবশ্যই সবকিছু সমাধান করে না। তবে আপনার পুনরাবৃত্তিতে (উদাহরণস্বরূপ 1-2 সপ্তাহের মধ্যে) রাজত্ব করে, কাজ প্রগতিতে সীমাবদ্ধ করে এবং স্প্রিন্ট পরিকল্পনা / পর্যালোচনাকে কাজে লাগিয়ে আপনার জলপ্রপাতের মতো ভুলগুলি এড়ানো উচিত। আসলে কী করা হচ্ছে - আপনার এটির জন্য আরও ভাল দৃশ্যমানতা দরকার it's

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

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


-1

অতীতে আমি যা বলেছি তা হল "এই কোডটি জটিল এবং এটি করার চেষ্টা করছে বলে আমি আত্মবিশ্বাসী নই, এটি হয় সহজতর করা বা আরও স্পষ্টভাবে লেখার পক্ষে কি সম্ভব?"


-2

আপনি তাদের কোড মুছে ফেলার / ঘুরিয়ে দেওয়ার পরে কোডার করবেন: "ওফস, আপনার কোড চলে গেছে Please দয়া করে এটি পুনরায় লিখুন already আপনি এটি ইতিমধ্যে একবার লিখে ফেলেছেন যাতে কেবল অনুমানের দ্বারা প্রয়োজনীয় কোডটি সরবরাহ করতে আপনার বিশ মিনিটেরও কম সময় প্রয়োজন হবে।

"আমার পরবর্তী পর্যালোচনা 20 মিনিটের মধ্যে।

"শুভ দিন."

কোন যুক্তি গ্রহণ করবেন না!

সম্পন্ন, আইএমএইচও

ক্রিস


আমি আনন্দিত যে আমার বস সেভাবে কাজ করে না।

@ জন: আমার ছয় বছরের বাচ্চাদের মতো লোকেরা যখন "ইতিমধ্যে এটি শেষ হয়ে গেছে" হিসাবে যেমন পেশাদারিভাবে প্রতিক্রিয়া জানায় তখন আপনাকে তাদের বাচ্চাদের মতো আচরণ করতে হবে।
cneeds

2
বলতে পারি না আমি রাজি। আপনি যদি তাদের "বাচ্চাদের মতো ব্যবহার করেন" তবে আপনার লোকদের কাছ থেকে কী ফলাফল পাওয়ার প্রত্যাশা করবেন? অন্যান্য পদ্ধতি আছে যা আইএমএইচও আরও গঠনমূলক।

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

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