আরএডি পরিবেশে মুক্তির মান উন্নত করার একটি সহজ উপায়


15

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

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

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

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

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

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

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

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

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


স্বয়ংক্রিয় ইউনিট টেস্টিং এবং সিআই মনে হচ্ছে আপনার প্রয়োজনীয় ধরণের জিনিস।
রায়নোস

উত্তর:


14

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

আমি এটিতে খুব সীমাবদ্ধ সাহিত্য দেখেছি, এটি আমরা অনুশীলন করি যা অবশ্যই সাহায্য করে:

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

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

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

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

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

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

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

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

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

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

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


1
যশ। এই উত্তরটি বেশিরভাগ অনলাইন টিউটোরিয়াল
উবারম্যানশ

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

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

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

"প্রক্রিয়াটি সঠিকভাবে অর্জন করা আরও ভাল, এবং তারপরে সরঞ্জামগুলির সাথে প্রক্রিয়াগুলির চেয়ে ম্যাচের পরিবর্তে ফিট করার জন্য সরঞ্জামগুলি সন্ধান করুন" + এর জন্য
উবারম্যানশ

4

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

আমাদের প্রক্রিয়াটির উন্নতির জন্য আমি একটি কানবান বোর্ড চালু করে শুরু করেছি । বোর্ডটি শুরু করা খুব সহজ ছিল এবং কেবল কয়েকটি কলাম ছিল (হোয়াইটবোর্ড, সূচক কার্ড এবং রঙিন চৌম্বক ব্যবহার করে সেটআপ):

ব্যাকলগ | করণীয় | সম্পন্ন

যাইহোক, এটি আমাদের প্রকৃত প্রক্রিয়াটি আয়নাতে দ্রুত বিকশিত হয়েছিল:

ব্যাকলগ | বিকাশ | দেব। পরীক্ষা | ইউএটি | হয়ে গেল | মুক্ত

বোর্ডের পাশাপাশি আমাদের একটি নিয়ম রয়েছে যে প্রতিটি টাস্ক / ফিচারটি অন্য বিকাশকারী (সেইসাথে বৈশিষ্ট্যটি কার্যকর করে এমন বিকাশকারী দ্বারা) পরীক্ষা করতে হবে। সুতরাং কোনও কার্ড 'সম্পন্ন' কলামে পৌঁছানোর সময় পর্যন্ত এটি কমপক্ষে 2 বিকাশকারী এবং ব্যবহারকারী স্বীকৃতি পরীক্ষা করে নেওয়া উচিত ছিল।

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

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

অন্যান্য লিঙ্কগুলি আমি দরকারী বলে মনে করেছি:

কানবান সফটওয়্যার বিকাশে প্রয়োগ করেছেন: অ্যাগিলি থেকে হেলান

সফটওয়্যার ইঞ্জিনিয়ারিংয়ের জন্য একটি কানবান সিস্টেম - ভিডিও

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


4

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

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

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

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

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

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


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

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

2

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

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

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

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


1

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

উদাহরণস্বরূপ, আপনার যদি এমন কোনও ক্লাস থাকে যেখানে কোনও পদ্ধতি কেবল 10 এবং 25 এর মধ্যে সংখ্যা গ্রহণ করতে পারে (এটিকে প্রাক শর্ত বলা হয়), আপনি পদ্ধতির শুরুতে একটি দৃsert় বিবৃতি যুক্ত করতে পারেন। যখন এই দাবিটি ব্যর্থ হয়, প্রোগ্রামটি তত্ক্ষণাত ক্রাশ হয়ে যাবে এবং আপনি সেই ব্যর্থতার কারণগুলির পদ্ধতিগুলি অনুসরণ করতে সক্ষম হবেন।

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

সি / সি ++ প্রোগ্রামগুলির জন্য, আমি দেখতে পেলাম যে মেমরি বরাদ্দ পরীক্ষা করার জন্য জোর যুক্ত করা প্রোগ্রামে মেমরি ফাঁসের সংখ্যা হ্রাস করতে খুব সহায়ক ছিল।


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

এটি অবিলম্বে পরিশোধ করা হবে কারণ আপনাকে নতুন বৈশিষ্ট্যগুলি / বাগ-ফিক্সগুলির জন্য প্রতিটি প্রকাশে দৃser়তা / শর্ত পরীক্ষা করা যুক্ত করতে হবে।
রুডলফ ওলা

দৃ the়পদগুলির সাথে একটি জিনিস রয়েছে - যদি এটির ভুল হয় তবে। তবে যদি আমরা পদ্ধতিটি কেবল 10 এবং 25 এর মধ্যে সংখ্যা গ্রহণ করতে পারি তবে বাস্তবে এটির পরিধি প্রসারিত করা ঠিক হবে [0; 50] এবং এটি কেবলমাত্র একটি নতুন প্রকাশ প্রকাশিত হওয়ার পরে এবং এটির জন্য উত্পাদনের পরে পাওয়া গেছে found দিন. যদি একটি কুইজিটনের অধীনে কোনও পদ্ধতিটি নিম্ন-স্তরের হয় এবং অনেক জায়গায় ব্যবহার করা হয় তবে আমরা করার মতো অনেক কিছুই নেই, তবে একটি স্থির করে পুনরায় প্রকাশ করতে। তবে আমরা যদি উচ্চ স্তরের
ট্রাই

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