আমার টিম কীভাবে রিফ্যাক্টরিংয়ের পরে ঘন ঘন ত্রুটিগুলি এড়াতে পারে?

Question

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

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

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

কীভাবে এই সমস্যাগুলি থেকে মুক্তি পাবেন? আপনি কী ধরনের 'ঘোষণা কৌশল' আমাকে সুপারিশ করতে পারেন?

Comments

এর সুস্পষ্ট উত্তর টিডিডি ।

— মউভিচিয়েল

আপনি কীভাবে এসেছেন যে "কী বৈশিষ্ট্যগুলির ওভার রাইটিংটি ঘটে না" এবং তারপরে আপনার সমস্যাটি হ'ল এটি কি ঘটে? আপনি কি "দলে" এবং "মূল বৈশিষ্ট্যগুলি" এর মধ্যে আপনার দলে পার্থক্য করেন এবং আপনি কীভাবে এটি করেন? কেবল পরিস্থিতিটি বোঝার চেষ্টা করছি ...

— লগ্ক

@ এমউভিসিএল এটি এবং গতিশীল টাইপিং ব্যবহার করবেন না , তবে সেই বিশেষ পরামর্শটি এই ক্ষেত্রে কিছুটা দেরি করে।

— ডোভাল

ওসিএএমএল এর মতো দৃ strongly়ভাবে টাইপ করা ভাষা ব্যবহার করুন।

— গাইস

@ ব্লগ হতে পারে আমি পরিষ্কার নই, দুঃখিত। আমরা ফিল্টার লাইব্রেরি নিজেই একটি মূল বৈশিষ্ট্য ওভাররাইট না, কিন্তু আমাদের গ্রাহক প্রকল্পে আমরা ক্লাসে নতুন ফিল্টার যুক্ত। একটি সাধারণ দৃশ্য হতে পারে, ফিল্টার লাইব্রেরির পরিবর্তনগুলি গ্রাহক প্রকল্পের যুক্ত হওয়া ফিল্টারগুলিকে ধ্বংস করে।

— এসডিডি 64

Answer 1

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

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

আপনার আর্কিটেকচার অনুযায়ী দল বিভক্ত করা প্রায় খারাপ অভ্যাস। যেমন একটি মূল দল এবং একটি নন-কোর দল। পরিবর্তে, আমি কার্যকরী ডোমেনে দল তৈরি করব তবে ক্রস-উপাদান component

Comments

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

— মার্সেল

আমি " সফটওয়্যার বিকাশের ডায়নামিক্স " তে মনে করি , ভিজ্যুয়াল সি ++ এর পিছনে ব্যবস্থাপক স্বতঃস্ফূর্ত বৈশিষ্ট্য দল থাকার পরামর্শ দেন; আমি "দ্য মিথিক্যাল ম্যান-মাস" পড়িনি, @ মার্সেল, কিন্তু আফাইক এটি শিল্পের খারাপ অভ্যাসগুলি তালিকাভুক্ত করেছে ...

— লগ্ক

মার্সেল, এটি সত্য যে জিনিসগুলি সাধারণত যেভাবে যায় বা যায় সেভাবেই, তবে আরও বেশি সংখ্যক দলগুলি এটি আলাদা করে করছে, উদাহরণস্বরূপ বৈশিষ্ট্য দলগুলি। ক্রস উপাদানগুলির বৈশিষ্ট্যগুলিতে কাজ করার সময় উপাদান ভিত্তিক দল থাকার ফলে যোগাযোগের অভাব হয়। এর পরে এটি প্রায়শই স্থিতিশীল আলোচনার ফলস্বরূপ কোনও ভাল আর্কিটেকচারের উদ্দেশ্য ভিত্তিতে নয়, তবে লোকেরা অন্যান্য দল / উপাদানগুলির প্রতি দায়বদ্ধতার দিকে ঠেলে দেওয়ার চেষ্টা করে। সুতরাং, আপনি এই প্রশ্নের লেখক দ্বারা বর্ণিত পরিস্থিতিটি পাবেন। Mountaingoatsoftware.com/blog/the-benefits-of-feचर- teams এও দেখুন ।

— তোহনেমিস্টার

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

— ডক ব্রাউন

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

— এসডিডি 64

Answer 2

আমরা মূলটির সবচেয়ে খারাপ অংশটি অনোধিত (যেমন এটি হওয়া উচিত ...)।

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

Comments

এটি এবং শিশুর পদক্ষেপগুলিতে রিফ্যাক্টরিং এবং খুব ঘন ঘন প্রতিশ্রুতিবদ্ধ।

— স্টিফান বিলিয়েট

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

— জন হান্না

আমি আপনাকে একটি "+1" দিয়েছি তবে আমি মনে করি এটি সমাধানের জন্য "স্বয়ংক্রিয় পরীক্ষাগুলি" একমাত্র পন্থা নয়। আরও ভাল ম্যানুয়াল, তবে পদ্ধতিগত কিউএ, হতে পারে একটি পৃথক কিউএ দলও মানসম্পন্ন সমস্যাগুলি সমাধান করতে পারে (এবং এটি উভয় - স্বয়ংক্রিয় এবং ম্যানুয়াল পরীক্ষাগুলি বোধগম্য হয় )।

— ডক ব্রাউন

একটি ভাল পয়েন্ট, তবে যদি কোর এবং গ্রাহক প্রকল্পগুলি পৃথক মডিউল হয় (এবং তদুপরি রুবির মতো গতিশীল ভাষায়), তবে কোরটি একটি পরীক্ষা এবং এর সাথে সম্পর্কিত বাস্তবায়ন উভয়ই পরিবর্তন করতে পারে এবং নিজস্ব পরীক্ষা ব্যর্থ না করে একটি নির্ভরশীল মডিউলটি ভেঙে ফেলতে পারে।

— লগ্যাক

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

— jb510

Answer 3

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

Comments

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

— বব টাও

Answer 4

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

তোমরা অবশ্যই ঋণ ক্ষমা করে আপনার মূল আচরণকে বরফে পরিণত করা যদি ¹ এবং আপনি একটি ব্যক্তিগত হস্তনির্মিত বস্তু ব্যবস্থাপনা সিস্টেমের মধ্যে যে মুক্তি করা ² , যেকোনো গ্রাহক প্রকল্পের কোর সংস্করণ উপর নির্ভরতার ডিক্লেয়ার করতে পারেন এক্স , এবং পরবর্তী রিলিজ দ্বারা ভাঙ্গা হবে না এক্স + 1 ।

"ঘোষণার নীতি" এরপরে প্রতিটি রিলিজের সাথে একটি ফাইল ফাইল রাখা বা প্রতিটি নতুন কোর রিলিজের সমস্ত বৈশিষ্ট্য ঘোষণার জন্য একটি টিম মিটিং করা কেবল হ্রাস করে।

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

সম্পাদনা : আপনি যদি সিমেন্টিক ভার্সন সিস্টেমে কনভেনশনগুলি অনুসরণ করেন তবে কোরের এপিআই-তে কোনও বেমানান পরিবর্তন অবশ্যই একটি বড় সংস্করণ পরিবর্তনের দ্বারা চিহ্নিত করা উচিত । এটি হ'ল আপনি যখন বিদ্যমান বিদ্যমান মূল আচরণটি পরিবর্তন করেন বা কোনও কিছু সরিয়ে ফেলেন, কেবল নতুন কিছু যুক্ত করবেন না। এই সম্মেলনের সাথে, বিকাশকারীরা জানেন যে সংস্করণ '1.1' থেকে '1.2' এ আপডেট করা নিরাপদ তবে '1.X' থেকে '2.0' এ যাওয়া ঝুঁকিপূর্ণ এবং সতর্কতার সাথে পর্যালোচনা করতে হবে।

^{1: আমি মনে করি এটিকে একটি মণি বলা হয়, রুবি 2 এর জগতে
: জাভাতে নেক্সাসের সমতুল্য বা পাইথনের পিপিপি}

Comments

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

— ডক ব্রাউন

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

— ল্যাক করুন

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

— এসডিডি 64

@ এসডিডি :৪: আমি যা বলছি ঠিক তা-ই অবিলম্বে কোনও সাধারণ মূলকে পরিবর্তনগুলি সংহত না করা দীর্ঘমেয়াদেও কোনও সমাধান নয়। আপনার যা দরকার তা হ'ল আপনার মূলের জন্য আরও ভাল টেস্টিংয়ের কৌশল - পাশাপাশি স্বয়ংক্রিয় এবং ম্যানুয়াল পরীক্ষাগুলিও।

— ডক ব্রাউন

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

— লগ্যাক

Answer 5

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

টিডিডির ক্ষেত্রেও তাই। এটি কীভাবে এটি সমাধান করতে পারে তা আমি দেখতে পাচ্ছি না।

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

Comments

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

— এসডিডি 64

সমস্ত দলের পক্ষ থেকে অবদান রয়েছে, প্রতিটি দলের জন্য পৃথক পরীক্ষার স্যুট নয়, মূলত একটি অংশের জন্য একটি ইউনিট টেস্ট স্যুট রাখার ধারণা ।

— ডক ব্রাউন

@ এসডিডি 64৪: আপনি "আপনার প্রয়োজন নেই (এখনও)" (যা খুব ভাল জিনিস) দিয়ে "আপনার কোডটি পরিষ্কার করার দরকার নেই (এখনও)" - যা চূড়ান্তভাবে খারাপ অভ্যাস , এবং IMHO একেবারে বিপরীত।

— ডক ব্রাউন

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

— লগ্ক

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

— এসডিডি 64

Answer 6

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

Answer 7

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

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

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

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

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

Comments

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

— এসডিডি 64

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

— এসডিডি 64

Answer 8

আমরা সবাই জানি যে ইউনিট পরীক্ষাগুলি যাওয়ার উপায়। তবে আমরা এটাও জানি যে বাস্তবের ভিত্তিতে এগুলি একটি মূলের জন্য বিপরীতমুখী করা কঠিন।

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

আসল ছদ্ম কোড:

def someFunction
   do original stuff
   return result
end

অস্থায়ী স্থানের পরীক্ষার কোড:

def someFunctionNew
   new do stuff
   return result
end

def someFunctionOld
   do original stuff
   return result
end

def someFunction
   oldResult = someFunctionOld
   newResult = someFunctionNew
   check oldResult = newResult
   return newResult
end

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

Answer 9

"বেশিরভাগ ক্ষেত্রেই টিমগুলির উপরে পরিবর্তনগুলি ঘোষণা করা হয় না, তাই বাগগুলি প্রায় সর্বদা অপ্রত্যাশিত হয়"

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

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

Answer 10

প্রাথমিকভাবে, আপনার একটি যোগাযোগ সমস্যা রয়েছে (সম্ভবত এটি একটি দল গঠনের সমস্যার সাথেও যুক্ত ), তাই আমি মনে করি আপনার মামলার সমাধানটি উন্নয়নের কৌশলগুলির পরিবর্তে ... ভাল, যোগাযোগের দিকে নিবদ্ধ করা উচিত।

আমি বিবেচনা করি যে গ্রাহক প্রকল্প শুরু করার সময় মূল মডিউলটি হিমায়িত করা বা কাঁটাচামচ করা সম্ভব নয় (অন্যথায় তবে আপনাকে কেবল আপনার মডিউলটি আপডেট করার লক্ষ্য নিয়ে গ্রাহক-সম্পর্কিত কিছু প্রকল্প নয় এমন সংস্থাগুলি আপনার সংস্থার সময়সূচীতে একীভূত করতে হবে)।

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

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

আপনি এখানে যোগাযোগ প্রক্রিয়া হিসাবে সিআই সম্পর্কে আরও সন্ধান করতে পারেন ।

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