প্রতিশ্রুতিবদ্ধ ইতিহাসটি বিকাশকারীদের কাছে সমালোচনামূলক তথ্য জানাতে ব্যবহার করা উচিত?

Question

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

কিছু বিকাশকারী যুক্তি দিয়েছিলেন যে এটি একটি খারাপ অনুশীলন ছিল এবং এটি পরিবর্তে উত্স ফাইলে (যেমন // Don't upgrade SDK Version x.y.z, see ticket 1234) বা কোনও প্রকল্প স্তরের READMEফাইলের মধ্যে উল্লেখ করা উচিত ছিল । অন্যরা যুক্তি দেখিয়েছিলেন যে প্রতিশ্রুতিবদ্ধ ইতিহাসটি প্রকল্পের ডকুমেন্টেশনের অংশ তাই এটি এই জাতীয় তথ্যের জন্য একটি গ্রহণযোগ্য অবস্থান, যেহেতু আমাদের সকলেরই এটি যেভাবে পড়া উচিত।

প্রতিশ্রুতিবদ্ধ ইতিহাসটি কি অন্য বিকাশকারীদের কাছে সমালোচনামূলক তথ্য পৌঁছে দেওয়ার জন্য ব্যবহার করা উচিত বা এই জাতীয় তথ্য অন্য কোনও জায়গায় যেমন কোনও প্রকল্প READMEবা প্রাসঙ্গিক উত্স ফাইলটিতে মন্তব্য হিসাবে নকল করা উচিত ?

Comments

দেখে মনে হচ্ছে আপনার প্রকল্পে বেশ গুরুতর যোগাযোগের সমস্যা রয়েছে।

— tzerb

পুরো প্রতিশ্রুতিবদ্ধ ইতিহাসের জন্য আপনার কি নতুন ভাড়ার দরকার?

— স্টিভেন এভার্স

নতুন ভাড়ার কোড বেসের মধ্যে ঘূর্ণায়মান হওয়া এবং নির্দিষ্ট দিকনির্দেশ ছাড়াই নির্ভরতা পরিবর্তন করা উচিত।

— মিডনোটিয়ন

@ মিডনোটিয়ন তাই কোথাও কোনও নতুন ভাড়া থেকে মূল বিকাশকারী আপনি কি পুরো কমিটের ইতিহাসের মধ্য দিয়ে যেতে সময় নেন? আকর্ষনীয়।

— নাথান কুপার

এটি সমালোচনামূলক ইতিহাসকে কেবল প্রতিশ্রুতিবদ্ধ ইতিহাসে রাখাই ভাল ধারণা তৈরি করে না।

— 26 এর 26

Answer 1

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

যদি আপনার পণ্যটি কোনও এসডিকে ২.০ সংস্করণ ব্যবহার করছে এবং কেউ 3.0 এ আপগ্রেড করতে আগ্রহী, আমি মনে করি এটা যুক্তিযুক্ত মনে হয় না যে তারা আপনার উত্স নিয়ন্ত্রণ সিস্টেমে সময়মতো পিছন দিকে তাকা উচিত যাতে এটি কোনও ভাল ধারণা নয় find

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

Comments

আসলে, প্রতিশ্রুতিবদ্ধ ইতিহাস প্রকল্পের ইতিহাস । উইকি সম্পাদনাগুলির ইতিহাসে গুরুত্বপূর্ণ তথ্য থাকা বোকামির মতো, আসল পৃষ্ঠায় নয় not ইতিহাস (কোড বা উইকি যাই হোক না কেন) এর আগে যা ঘটেছিল তার রেফারেন্সের জন্য, এখন কী ঘটবে তা নয়।

— Ordous

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

— Klors

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

— ড্যান নীলি

@ ক্লার্স আমি একই জিনিসটি ভাবছিলাম, তবে আমার মতে, ইউনিট পরীক্ষাটি v3 এর উপর v2 ব্যবহার করার কারণটি প্রদর্শন করা উচিত, সেইভাবে যদি ইউনিট পরীক্ষাটি ভি 4 এর সাথে পাস হয়, আপনার কাছে ইউনিট পরীক্ষা নেই যার জন্য কোনও ভি -2 প্রয়োজন নেই have কারণ।

— ম্যাথু

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

— জুলে

Answer 2

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

<!-- Do not change the SDK version because it causes Foo crashes. For more detail see Issue #123 -->

সরাসরি আপনার <dependency>লাইনের উপরে ।

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

নির্ভরতা ঘোষণার সাথে এটিকে রাখার কারণ হ'ল কারণ যে কেউ সংস্করণটি পরিবর্তন করতে চায় তারা এটিকে এটি পরিবর্তন করতে চায় এবং কেন তাদের করা উচিত নয় তা বুঝতে পারে।

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

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

Comments

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

Answer 3

সমালোচনামূলক এবং অ-স্বজ্ঞাত তথ্যের টুকরোগুলি নথিভুক্ত করা উচিত যেখানে তথ্য বিবেচনা করার সময় লোকেরা তাকিয়ে থাকবে।

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

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

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

---

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

Comments

হ্যাঁ, মন্তব্যটি পরিবর্তনের "পথে" রাখা দরকার। সুতরাং সতর্কতাটি না দেখে অ্যাকশনটি করা প্রযুক্তিগতভাবে অসম্ভব। এটি অনেকটা সুরক্ষা নিয়ন্ত্রণের মতো।

— dss539

আপনার ইস্যু ট্র্যাকারে আপগ্রেড করার জন্য একটি গল্প / টিকিট তৈরি করার পরামর্শের জন্য +1, কেন এখনও এটি করা যায় না তার ব্যাখ্যা দিয়ে "অন হোল্ড" এ সেট করুন। ইস্যু যে ব্যক্তি অনুসরণ করে এক জায়গায় আপনি সত্যিই করতে যুক্তিসঙ্গতভাবে কিছু কাজ করার আগে দেখুন মানুষ প্রয়োজন।

— অ্যান্ড্রু স্পেন্সার

জেফ অ্যাটউডকে উদ্ধৃত করে +1 (যদিও তিনি "ব্যবহারকারী" সম্পর্কে কথা বলছেন): "পরের বার আপনি [এক্স] ডিজাইন করছেন, [ক্লায়েন্ট] মায়োপিয়া বিবেচনা করুন your আপনার [ক্লায়েন্ট] কীভাবে মায়োপিক হতে পারে তা অবাক করে দিতে পারেন। তাদের সামনে সরাসরি জিনিস রাখার বিষয়ে দীর্ঘ এবং কঠোর চিন্তা করুন, যেখানে সেগুলি কেবল দৃশ্যমান নয়, তবে অনিবার্য। অন্যথায় তারা সম্ভবত দেখা যায় না "" blog.codinghorror.com/treating-user-myopia

— হেল্টনবাইকার

Answer 4

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

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

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

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

Comments

এই এক সত্য উত্তর। ইউনিট পরীক্ষায় ব্যর্থতা ক্যাপচার করা খারাপ আপগ্রেড হওয়ার থেকে বাধা দেয়। সময়কাল।

— ডার্ক বেস্টার

Answer 5

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

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

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

Comments

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

— জেনসজি

Answer 6

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

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

Answer 7

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

বন্ধুরা, আমরা SDK v xyz ব্যবহার করতে পারি না কারণ এটি ফু বাফারটিকে উপচে ফেলেছে এবং বার পরিষেবাটি ক্র্যাশ হয়ে যাবে। এক্সআই সংস্করণ সহ আঁকড়ে থাকুন

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

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

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

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

Comments

আমি ইমেইল গ্রুপ ধারণা পছন্দ করি। অনেকগুলি জায়গাগুলি আমি পৃথক ঠিকানার উপর নির্ভর করে এবং জিনিসগুলি নতুন সদস্যদের কাছে দেওয়া হয় না।

— জেফো

কেউ যদি আপনার দলে নতুন আসে তবে কি হবে? তাদের এই ধরণের ছদ্ম-প্রাতিষ্ঠানিক জ্ঞান দেওয়ার জন্য দায়ী কে?

— এবিমাগিল

@ অ্যাবমাগিল: তথ্যটি একটি উইকিতে যায়। দলে নতুন যে বিকাশকারীরা সাধারণত সেখানে কিছু সূচনা পৃষ্ঠায় শুরু হয়। তারপরে তারা নির্দিষ্ট ব্যক্তিদের কাছে আসে (যারা নতুন দেবকে সাহায্য করার জন্য সময় সরবরাহ করেছে) যখন তাদের নির্দিষ্ট প্রশ্ন থাকে (এবং তারা সর্বদা থাকে)। আমাদের ক্ষেত্রে এটি সম্ভবত "অ্যাপ্লিকেশনএক্স জন্য বিকাশকারী সেটআপ গাইড" এ শেষ হবে NOTE: Do not use SDK vers. x.y.z because...তবে প্রাথমিক যোগাযোগটি একটি ইমেল হওয়া উচিত।

— হতাশ

-1 ইমেলগুলি ডকুমেন্টেশনের মতো ভাল কাজ করে না

— ব্লু রাজা - ড্যানি ফ্লুঘুফুট

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

— হতাশ

Answer 8

প্রতিশ্রুতিবদ্ধ মন্তব্যে এরকম কিছু দেওয়া উচিত ছিল, তবে অন্যান্য জায়গায় থাকার ফলে এটি উপকৃত হবে।

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

এই তৃতীয় পক্ষের এসডিকে সম্পর্কে কোনও ধরণের দস্তাবেজ থাকা দরকার।

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

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

Answer 9

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

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

যদি কোনও ব্যবহারকারী যদি না জানে যে তারা কী সন্ধান করছে তবে তথ্যটি দ্রুত কয়েকশ কমিট লগের নিচে চাপা দেওয়া হয় এবং তাদের সামনে তথ্যের গাদা ছাঁটাই করার কোনও সরঞ্জাম নেই।

Comments

এটি একটি উত্তর চেয়ে একটি মন্তব্য মত আরও পড়তে। দেখুন: কিভাবে উত্তর দিতে

— মশা

ভালো কথা, আমি এটি প্রসারিত করেছি। আশা করি এটি স্ট্যাকএক্সচেঞ্জের মানদণ্ডের আরও ভাল পূরণ করে।

— কর্ন

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

— শেঠ ব্যাটিন

Answer 10

আমি এই পরিস্থিতিটিকে দুটি মূল সমস্যা হিসাবে সম্ভবত তিনটি হিসাবে ব্যাখ্যা করি।

• একটি অযাচিত SDK আপগ্রেড এটিকে উত্স হিসাবে তৈরি করেছে, যেখানে এটি পণ্যটিকে নেতিবাচকভাবে প্রভাবিত করতে পারে।
• প্রশ্ন থেকে: যে অবদানকারী অবাঞ্ছিত আপগ্রেড করেছে তারা পূর্ববর্তী, আপগ্রেড না করার নির্দিষ্ট সিদ্ধান্ত সম্পর্কে জানত না।

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

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

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

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

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

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

Comments

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

— rjzii

কেন টানার অনুরোধ প্রত্যাখ্যান করা হত? এই সিদ্ধান্তের জন্য দায়বদ্ধ ব্যক্তি কীভাবে সংস্করণ সীমাবদ্ধতা আবিষ্কার করবেন (বা মনে রাখবেন)?

— বেন ভয়েগট 21

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

— ভাড়ার

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

— বেন ভয়েগট

Answer 11

আমি বলব প্রতিশ্রুতিবদ্ধ ইতিহাসে সেই ধরণের তথ্য যুক্ত করা ঠিক আছে তবে এটি এখনও সঠিকভাবে নথিভুক্ত করা দরকার। আমরা সম্প্রতি (অ্যাটলাসিয়ান দ্বারা) সঙ্গম ব্যবহার শুরু করেছি। এটি অনুসন্ধানযোগ্য, আপনি নির্দিষ্ট পৃষ্ঠাগুলি পছন্দসই ইত্যাদি হিসাবে সেট করতে পারেন etc.

কিছু অন্যান্য সরঞ্জাম Evernote বা গুগল ডক্সে একটি সর্বজনীন নোটবুক হতে পারে।

Answer 12

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

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

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

আমি প্রশংসা করি এই উত্তরটি খুব টিএফএস-কেন্দ্রিক, তবে সম্ভবত একই পরিস্থিতিতে আপনার সংস্করণ / সিআই সিস্টেমগুলির সংস্করণগুলি উপস্থিত রয়েছে যা আপনার পরিস্থিতিতে প্রয়োগ হয় (যদি টিএফএস না হয়)।