পর্যালোচনার জন্য অপেক্ষা করার সময় আমার কী করা উচিত?


32

আমার প্রশ্ন জিজ্ঞাসা করার আগে, আমি পরিস্থিতি ব্যাখ্যা করতে হবে।

আমি জুনিয়র সফটওয়্যার ইঞ্জিনিয়ার হিসাবে একটি সংস্থার হয়ে কাজ করছি। আমি যখন আমার বিকাশ শেষ করে প্রতিশ্রুতিবদ্ধ হতে চাই তখন একজন সিনিয়র সর্বদা আমাকে থামিয়ে দেয়।

তিনি সর্বদা চান যে আমি এটির পর্যালোচনা করার জন্য অপেক্ষা করব। এটি ঠিক আছে, কারণ সাধারণত তিনি কিছু বাগ খুঁজে পান এবং কিছু অনুকূলিতকরণ করেন ations

তবে সময়সীমার আগে আমাকে অবশ্যই আমার কোডটি করাতে হবে। আমি শেষ হয়ে গেলে, আমি তাকে কল করে বলি এটি শেষ হয়ে গেছে। সে সাধারণত দেরিতে আসে। সুতরাং আমার কোড খুব দেরী।

আমার প্রশ্ন, আমি কি করব? আমার কি তাকে পর্যালোচনার জন্য অপেক্ষা করা উচিত?

সম্পাদনা: প্রশ্ন যোগ করুন। আমি আরও একটি ইস্যু সম্পর্কে কৌতূহলী।

কোডিং করার সময় আমি মুক্ত হতে চাই। আমি কীভাবে উন্নয়নের স্বাধীনতার জন্য আস্থা অর্জন করতে পারি?

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


10
এটি সম্পর্কে তাঁর সাথে কথা বলুন।
ফ্লোরিয়ান মার্জাইন

18
এটি সম্পন্ন হয়েছে এবং আপনি তার পর্যালোচনার জন্য অপেক্ষা করছেন বলে ইমেল করুন। আপনি যদি কোনও সময়সীমা কেন মিস করেন তা যদি কেউ জিজ্ঞাসা করে তবে আপনি সর্বদা সেই ইমেলের দিকে ফিরে উল্লেখ করতে পারেন।
dreza


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

3
ধৈর্য ধরুন, আপনার কোডের দ্বিতীয় জোড়া চোখ (উদাহরণস্বরূপ একজন সিনিয়র) পাওয়া কতটা উপকারী তা আপনার কোনও ধারণা নেই।
জেফো

উত্তর:


70

সুতরাং আমার কোড খুব দেরী।

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

এবং আপনার সম্পাদনা:

কোডিং করার সময় আমি মুক্ত হতে চাই। আমি কীভাবে উন্নয়নের স্বাধীনতার জন্য আস্থা অর্জন করতে পারি?

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


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

আপনি এটি সম্পর্কে সঠিক। তবে সিনিয়রদের কোনও দায় নেই। কোডটি পর্যালোচনা করার জন্য তাঁর পক্ষে কোনও কাজ নেই। তবে তিনি সবসময় তা করেন।
yfklon

27
@blank: ঠিক আমার বিন্দু যে - জ্যেষ্ঠ আপনি বলে যদি অপেক্ষা করতে তিনি সময় লাগে দায়িত্ব। যিনি সময়সীমা নির্ধারণ করেন তাকে স্বচ্ছ করুন Make
ডক ব্রাউন

27

একটি ভাল দলে, আপনার ইস্যু ট্র্যাকারে আপনাকে নির্ধারিত বিকাশের কাজের সারি থাকা উচিত ।

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

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

কোডিং করার সময় আমি মুক্ত হতে চাই। আমি কীভাবে উন্নয়নের স্বাধীনতার জন্য আস্থা অর্জন করতে পারি?

এটির জন্য, আপনাকে কোড পর্যালোচনার উদ্দেশ্যটি বুঝতে হবে প্রথমে। আপনি বিশ্বাসের কথা উল্লেখ করেছেন - এটি একটি ভাল "আনুমানিক", তবে সম্পূর্ণ সঠিক নয়।

  • উদাহরণস্বরূপ, আমার সাম্প্রতিক প্রকল্পগুলির একটিতে আমার এবং আমার সহকর্মীর একটি মিনি টিম কাজ করেছে development আমরা একে অপরকে সম্পূর্ণরূপে বিশ্বস্ত ও সম্মান করি - তবে এটি সত্ত্বেও আমরা 100% কোড পর্যালোচনা করি। আমরা এটি করছিলাম কারণ এটি আমাদের কিছু ত্রুটিগুলি দ্রুত খুঁজে পেতে এবং তা ঠিক করার অনুমতি দেয় এবং এটিও খুব গুরুত্বপূর্ণ কারণ পর্যালোচনাগুলিতে বেশি সময় লাগে না এবং আমাদের কাজ আটকে দেয় না।

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

আপনার উদাহরণ ব্যবহার করে, আপনি "ব্লক রিভিউসমূহ" আশা করতে পারেন যতদিন আপনার সমালোচক দ্বারা বিনিয়োগকৃত প্রচেষ্টা হিসেবে সমর্থনযোগ্য বাগ এবং যে ভাল আপনার কোড সংগঠনের পূর্বে সংশোধন করা উন্নতি খোঁজার দ্বারা।

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

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


1
আপনার মতামতগুলি সাংগঠনিক সমস্যার জন্য কোনও প্রযুক্তিগত সমাধানের পরামর্শ দিচ্ছে। আমার অভিজ্ঞতার সাথে, যে খুব কমই কাজ করে।
ডক ব্রাউন

5
@ ডকব্রাউন আমার মনে হয় না যে এই উত্তরগুলি কোনও প্রযুক্তিগত সমাধানের দিকেই জোর দেয়। সমাধানটির মূলটি হ'ল "আপনার দেওয়া কার্যগুলির একটি সারি আপনার থাকা উচিত"। যে কোন সাংগঠনিক সমস্যার কোনো সাংগঠনিক সমাধান। সেই সারিটি কোনও ইস্যু ট্র্যাকার, ইমেল, স্প্রেডশিট, একটি হোয়াইটবোর্ডে বা নোট পোস্টের স্ট্যাকে রক্ষণাবেক্ষণ করা কিনা তা কেবল একটি বিশদ।
কারসন 63000

@ কারসন 63000 ঠিক তাই আমি আরও যুক্ত করব যে ইস্যু ট্র্যাকারে কাজ থাকা যাতে ম্যানেজার / সিনিয়রদের কাছে নতুন টাস্ক জিজ্ঞাসা করার দরকার পড়ে না তবে এটি একটি সাংগঠনিক বিশদও (এবং আমার অভিজ্ঞতায় একেবারেই ছোটখাটো নয় )
gnat

1
@ জাগান: ভাল, আপনি আরও "স্পষ্টর উদাহরণস্বরূপ" কোনও ইস্যু ট্র্যাকারটিতে লিখতে পারেন that তবে আমি নিশ্চিত নই যে আপনি যে প্রশ্নের উত্তর দিচ্ছেন (শিরোনাম থেকে একটি) নীচের পাঠ্যটিতে লিখিত ওপিএস প্রশ্নের মূল পয়েন্ট কিনা (যা ভিন্ন একটি) if
ডক ব্রাউন 6

@ ডকব্রাউন আমি ইচ্ছাকৃতভাবে এটি করিনি, কারণ আমি বিশ্বাস করি যে "উদাহরণস্বরূপ" হিসাবে বর্ণনা করা খুব গুরুত্বপূর্ণ সাংগঠনিক বিশদ (জুনিয়র সতীর্থরা যখন বর্তমান প্রেরণগুলি সম্পন্ন করার সাথে সাথে পরবর্তী কাজ জিজ্ঞাসা করতে আমার কাছে আসছেন তাদের খুব ভাবনা আমার মেরুদণ্ডকে সরিয়ে দেয়) )
gnat

9

আপনার সমস্যাটি ঠিক কী তার উপর নির্ভর করে এখানে একাধিক সম্ভাব্য উত্তর রয়েছে।

  • যদি আপনার প্রধান উদ্বেগটি হয় "আমি ডেডলাইন মিস করছি", না। আপনারা দু'জন যৌথভাবে সময়সীমা মিস করছেন। আপনি কি (আত্মবিশ্বাসের সাথে) বলতে পারেন যে "আমি এক ঘন্টার মধ্যে শেষ করব, আমরা কি তাহলে কোড পর্যালোচনা করতে পারি"? যথেষ্ট হতে পারে। আপনি সময়সীমার আগের দিন কোডটি শেষ করতে পারবেন? এটি একটি প্রচুর বাফার হওয়া উচিত। "দয়া করে পর্যালোচনা করুন" এবং সময়সীমাটির মধ্যে প্রচুর পরিমাণে বাফার দিয়ে আপনি কি আপনার কোডটি সম্পূর্ণ করছেন? যদি দ্বিতীয়টি হয় তবে এটি যৌথ ত্রুটিও নয় not

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


5

আমার প্রশ্ন, আমি কি করব? আমার কি তাকে পর্যালোচনার জন্য অপেক্ষা করা উচিত?

না, আপনি কেবল অলস বসে থাকবেন না। না কিছু সবসময় আছে। জ্নাত যেমন পরামর্শ দিয়েছেন , ততক্ষণে কাজের সারি থাকা উচিত। বা, বিকাশের একটি চৌকস উপায়ে, বর্তমান পুনরাবৃত্তির জন্য আপনাকে অর্পিত কার্যগুলির তালিকা। আপনি যদি অলস বসে থাকেন তবে আপনার সংস্থা বা আপনার দলের সংস্থায় কিছু ভুল আছে।

আরেকটি বিষয় হ'ল: আপনার সিনিয়র সুপারভাইজার কি সত্যই আপনার প্রতিটি কোডের কোড পরীক্ষা করে দেখছেন? যদি হ্যাঁ, আপনি জোড় প্রোগ্রামিংও করতে পারেন।


কোডিং করার সময় আমি মুক্ত হতে চাই। আমি কীভাবে উন্নয়নের স্বাধীনতার জন্য আস্থা অর্জন করতে পারি?

কিছু নিয়মাবলী রয়েছে যার জন্য প্রবীণদের জুনিয়রের কাজ পরীক্ষা করা দরকার (আমি মনে করি মেডিকেল আইসো 62304 এর জন্য এটি প্রয়োজন)। যদি তা হয় তবে আপনি কিছু করতে পারবেন না।

আপনি যা পরিবর্তন করতে পারেন তা হ'ল আধ্যাত্মিকভাবে সমস্ত কিছু পরীক্ষা না করে সিনিয়রকে জিজ্ঞাসা করা। আপনি কোড পর্যালোচনা প্রক্রিয়া সেট করতে পারেন এবং গুরুত্বপূর্ণ জিনিসগুলি পরীক্ষা করতে পারেন।


3

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

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


2

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

পেয়ার প্রোগ্রামিংয়ের উইকিপিডিয়া পৃষ্ঠা

আপনার পক্ষে সর্বাধিক সুস্পষ্ট সুবিধা হ'ল পর্যালোচনাটি প্রক্রিয়াটির অনেক আগে ঘটেছিল তাই আপনাকে আর সিনিয়র বিকাশকারীর জন্য অপেক্ষা করতে হবে না।

পাশাপাশি এটি আপনি কোডটি লেখার সাথে সাথে সিনিয়র বিকাশকারীদের চিন্তার প্রক্রিয়া এবং কৌশলগুলি দেখতে সক্ষম হবেন এবং এ থেকে শিখতে পারবেন।

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

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


2

নিজেই একটি সম্পূর্ণ উত্তর নয়, উপরের দুর্দান্ত উত্তরের জন্য কেবল একটি সংযোজন ...

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

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

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

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

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


1

আমি মনে করি ম্যানুয়াল কোড রিভিউ সম্পাদন করা ... ভাল ... টাইপ 80 এর। ঠিক আছে, 90 এর দশক হতে পারে।

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

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

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

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


আটলসিয়ান ক্রুসিবল জেটব্রেইনস টিমসিটি
রিটভেল্ড
ক্রুজ কন্ট্রোল

আপনি যদি সিআই সার্ভার পেতে চলেছেন তবে আপনার ইউনিট পরীক্ষা ফ্রেমওয়ার্কগুলি সম্পর্কেও গুরুত্ব সহকারে চিন্তা করা উচিত। আপনি যদি কোনও সি # দেব হন তবে শুরু করতে নুনিটের মতো কিছু দেখুন ।


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

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

আমার ধারণা, যে উত্তরটি হ্রাস করেছে সে প্রথম লাইনে পড়ে নি। আমি মনে করি প্রথম লাইনটি কিছুটা বিভ্রান্তিকর।
ভাইটালিক

এলএল, ভাল, ২০১০ এর ... এটি এডিএইচডি-ইসমের যুগ ...!
কোড

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

-1

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

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