কোড পর্যালোচনা তারা সত্যিকারের চটপটে কাজ করে?


13

সুতরাং আমি একটি বৃহত্তর কর্পোরেশনের জন্য কাজ শুরু করেছিলাম, যাদের নামে 3 টি অক্ষর রয়েছে তাদের মধ্যে একটি, এবং তারা চটপটে পরিণত হওয়ার চেষ্টা করছে, তবে প্রচুর প্রক্রিয়া রয়েছে, যা আমি চতুর মনে করি না।

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

যাইহোক, আমার যুক্তি হ'ল কোড পর্যালোচনাগুলি পুনরাবৃত্তি বা চৌকস বিকাশে সময় নষ্ট যেখানে ইউএক্স / ইউআই চরম / তীব্র (মনে হয় অ্যাপল / স্টিভ জবসের পারফেকশন)। তারা আমাকে গুলি চালানোর আগে এখানে কেউ বুঝতে সাহায্য করতে পারে?

এখানে আমার বিকাশ প্রক্রিয়া এবং আমার শেষ প্রারম্ভের একটি ... খুব চটজলদি।

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

আমরা যখন 8 সপ্তাহের পুনরাবৃত্তি চক্রের শেষের দিকে পৌঁছায় QA পরীক্ষা শুরু করে, তখন এটি আলফা ব্যবহারকারীদের এবং শেষ পর্যন্ত বিটা ব্যবহারকারীদের কাছে যায়। তবে আলফা এবং বিটা বিকাশকারীরা নতুন বৈশিষ্ট্যগুলি এবং পুরানো বৈশিষ্ট্যগুলি দিয়ে চলেছেন যা ইউএক্সের উন্নতি করতে প্রতিদিন বা ঘন্টা সময়ে ইউআইতে পরিবর্তন হয়। সুতরাং এই বৈশিষ্ট্যটি যা এই রিলিজটি বিকাশ করা হয়েছিল, এটি উন্নত করতে এবং নিখুঁত করতে বা কয়েকটি ছোট বৈশিষ্ট্য যুক্ত করতে (যেমন উপাদানটিকে কিছুটা স্মার্ট বা স্মার্ট করে তুলতে) গত চার সপ্তাহে আরও 3 বার পরিবর্তিত হতে পারে। কখনও কখনও পরিবর্তনগুলি পর্যাপ্ত হতে পারে যার অর্থ কোনও সিআরইউডি অপারেশন পরিবর্তন বা পরিবর্তিত হয় না, তবে সমস্ত ইউআই কেবল পরিবর্তন করে।

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

এই প্রক্রিয়াটি নিয়ে আমাদের কাছে কখনও মানের মানের সমস্যা ছিল না এবং হ্যাঁ যদি কোনও বিকাশকারী সমস্ত জ্ঞান ছেড়ে দেয় তবে আমরা সর্বদা স্মার্ট বিকাশকারীদের এটি খুঁজে নিতে ও টেকওভারের জন্য খুঁজে পাই।

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

আশা করি এই পোস্টটি আড়ম্বরপূর্ণ হিসাবে আসে না, তবে আমি কেবল দেখতে পাচ্ছি না যে কোড পর্যালোচনাগুলি কীভাবে অপব্যয় হয় না। পর্যালোচনা করা কোডটিতে আমাদের সমস্ত কোডের 2% এর মধ্যে বাগ রয়েছে। প্রতিটি রিলিজ আমরা কোড পর্যালোচনা মাধ্যমে 3 বাগ খুঁজে পেতে পারে। সুতরাং এটি 3 টি 5 টি বাগ খুঁজে পেতে প্রতি বিকাশকারী প্রতি 4 ঘন্টা কোড রিভিউর (4 x 40 = 160 ঘন্টা) অবধি সমাপ্ত হয়? সম্ভাবনা 50% যে 3 থেকে 5 বাগ যেভাবেই কিউএ দ্বারা নেওয়া হত। ডেভেলপারের জন্য ৪০ ঘন্টা ব্যয় করা কী ভাল হবে না কোনও নতুন বৈশিষ্ট্য যুক্ত করা বা বিদ্যমানগুলি উন্নত করা?


@ ডিডএমজি: ব্যবহারকারীর অভিজ্ঞতা
স্টিভেন এ। লো

4
@ ইউজার ২৫70০২: আপনি যে প্রক্রিয়াটি বর্ণনা করেছেন তা ফুপলের মতো শোনাচ্ছে না, এটি RUP / সর্পিলের মতো শোনাচ্ছে। বিশেষত "আমাদের বিকাশের সপ্তাহগুলিতে বেশ কয়েকবার আমরা স্টেকহোল্ডারদের সাথে আবারও সেলসেশন করি তা দেখার জন্য যে তারা এখনও বৈশিষ্ট্য / ফাংশন / ইউএক্স / ইউআই সম্মত হয় কিনা তা এখনও উপযুক্ত এবং টার্গেটে রয়েছে" " চঞ্চলবিরোধী; আরইউপি / সর্পিল পদ্ধতির সাথে সম্পর্কিত চলন্ত-লক্ষ্য সমস্যাগুলি এড়াতে পুনরাবৃত্তির সময় বৈশিষ্ট্যগুলি হিমশীতল হয়। আপনার নামমাত্র প্রশ্নের হিসাবে, আমি এখানে কোড পর্যালোচনার খুব বেশি মূল্য দেখতে পাচ্ছি না এবং কেবল যদি আপনি নিশ্চিত হন যে QA দ্বারা বাগগুলি পাওয়া যেত।
স্টিভেন এ। লো

1
8 সপ্তাহের পুনরাবৃত্তিগুলি চটজলদি নয় এবং অবশ্যই "চরম চতুর" নয়।
মার্টিন উইকম্যান

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

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

উত্তর:


13

কোড রিভিউগুলি আপনার জন্য কিছু জিনিস করতে পারে এবং কিছু জিনিস তারা করতে পারে না are কোড পর্যালোচনার পক্ষে যুক্তি :

  • সমষ্টিগত মালিকানা
  • বাগগুলি (কিউসি) সন্ধান করুন
  • ধারাবাহিক শৈলী প্রয়োগ করুন (কিউএ)
  • মেন্টরিং

অনেক চতুর প্রক্রিয়াগুলি বিভিন্ন উপায়ে মোকাবেলা করে:

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

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


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

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

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

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

11

কোড পর্যালোচনাগুলি কি কেবল বাগ সন্ধানের জন্য? আপনি সত্য বলে মনে করেন এবং আমি তা করি না।

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


4

জোড় প্রোগ্রামিং হ'ল কোড পর্যালোচনার এক্সপি উত্তর। মূলত, কোডের প্রতিটি লাইন পর্যালোচনা করা হয় যেমন এটি লেখা হয়। এটি কোড পর্যালোচনা চূড়ান্তভাবে নেওয়া হয়।


7
আমি এই নিয়ে দৃ strongly়ভাবে তর্ক করব। অবশ্যই, এটি দুটি ব্যক্তি দ্বারা পর্যালোচনা করা হচ্ছে, কিন্তু সেই ব্যক্তিরা সাধারণত কোডটি লেখা হচ্ছে একই পাতায় are একটি কোড পর্যালোচনা হ'ল এমন কোনও ব্যক্তি যা আপনার কোডটি দেখেন এবং "দোহ! সেই মামলাটি পরিচালনা করার বিষয়ে ভুলে গেছেন" ধরণের প্রকারের সমস্যাগুলি খুঁজে পান - এক্সপি সত্যই এতে সহায়তা করে না।
বিলি ওনিল

4

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

কোডটি বাগ-মুক্ত কিনা তা আপনি জানতে পারবেন না কারণ এটি কোনও রেকর্ডকৃত পরীক্ষার সাথে পাস করে না। "পরীক্ষা কেবল বাগের উপস্থিতি প্রমাণ করতে পারে, অনুপস্থিতি নয় not" (Dijkstra?)

কোড পর্যালোচনা কোড শৈলীর একই রাখে এবং এমন জায়গা সন্ধান করতে সক্ষম যেখানে কোডটি ভাল নয় তবে আপাতত কাজ করে work এটি রাস্তার নিচে রক্ষণাবেক্ষণ ব্যয় সাশ্রয় করে।

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


2

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

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

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


1

আমি সম্মত হতে চাই যে সম্মিলিত কোডের মালিকানা এবং টিডিডি এবং সিআইয়ের সাথে জুটিবদ্ধ হ'ল আনুষ্ঠানিক কোড পর্যালোচনা সেশনের Agile প্রতিষেধক।

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

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

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

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


0

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

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

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

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

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

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

পরিবর্তনগুলি (বাগ ফিক্স সহ) বাস্তবায়নের জন্য ব্যয় সাধারণত প্রতিটি পর্যায়ে যায় তার জন্য যায়। বিকাশে ত্রুটিগুলি খুঁজে বের করার জন্য এটিগুলি পরীক্ষার পরে ঠিক করার চেয়ে সস্তা।

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