সফ্টওয়্যার পুনরায় ব্যবহারের পুনরাবৃত্তি প্রক্রিয়া পুনরায় ব্যবহার করে


25

সমস্যা হিসাবে কোড পুনরায় ব্যবহার

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

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


অন্যান্য অনুশাসনের সাথে কিছু তুলনা

নির্মাণ

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

মাস্টার নির্মাতারা বিশেষজ্ঞরা তাদের অঞ্চলে দশক, শত, বা হাজারো জিনিস ডিজাইন এবং / বা বিল্ডিংয়ের জন্য স্বীকৃত are উদাহরণস্বরূপ, বিশ্বখ্যাত স্থপতি এবং ডিজাইনার ফ্র্যাঙ্ক লয়েড রাইটdesigned more than 1,000 structures and completed 532 works । এর বিপরীতে আন্ডার হেজলসবার্গের সাথে যিনি পাঁচটি ভাষায় "সবেমাত্র" ডিজাইন করেছেন (টার্বো পাস্কাল; ডেল্ফি; জে ++; সি #; টাইপস্ক্রিপ্ট)। বিভিন্ন উপায়ে এটি একটি অন্যায্য তুলনা কারণ ডোমেনগুলি পৃথক। তবে একটি বিস্তৃত স্তরে, দুটি অত্যন্ত বুদ্ধিমান লোকের পরিমাণ নির্ধারণযোগ্য উত্পাদন সম্পূর্ণ ভিন্ন।

কারাতে

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

কাঠের

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


সুতরাং, সফ্টওয়্যার পুনরায় ব্যবহার কি সফ্টওয়্যার বিকাশকারীদের আরও দক্ষ হতে বাধা দেয়?

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

আমার প্রশ্ন: সফ্টওয়্যারটির পুনঃব্যবহারের ক্ষমতাটি কি কোনও প্রকল্পের পুনরাবৃত্তি থেকে আসা প্রয়োজনীয় প্রক্রিয়া উন্নতি এবং দক্ষতা রোধ করে?


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

2
ভাল সফ্টওয়্যার প্রকল্পগুলি "শিফট" QA তে পুনরাবৃত্তিযোগ্যতা of আমি যখন 1,5 বছর দীর্ঘ প্রকল্পে পরীক্ষক ছিলাম তখন আমরা সাপ্তাহিক "চেকপয়েন্ট" রিলিজে পরীক্ষার চক্র পরিচালনা করি, প্রকল্পের মাধ্যমে প্রায় 70 গুণ। এটি ছিল ... বেশ পুনরাবৃত্তিযোগ্য, মৃদুভাবে বলতে (এক সপ্তাহে খুব বেশি কিছু পরিবর্তন হয় না)। রাতের বিল্ডগুলি পরীক্ষা করা স্বাভাবিকভাবেই, আরও বেশি পুনরাবৃত্তিযোগ্য - প্রকল্পের মাধ্যমে প্রায় 500 বার হয়েছে (কিছু বিনোদনমূলক শোস্টোপার বাগগুলি কোনও পার্থক্য করতে খুব বিরল ছিল)। একই দলের সঙ্গে সব - এখন, আমাকে একটা নির্মাণ কোম্পানি যে 500 সেতু গড়ে তুলেছে বলতে
মশা

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

1
@ GlenH7 সেটিকে প্রসারিত উত্তর , বেশিরভাগ সেতু :) ছবি অন্তর্ভুক্ত করা
মশা

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

উত্তর:


10

সফ্টওয়্যার পুনরায় ব্যবহার করার ক্ষমতা প্রক্রিয়া উন্নতি রোধ করে না।

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

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

তারা উন্নতি প্রক্রিয়া করার চাবিকাঠিটি হ'ল আপনার ক্রিয়াকলাপ এবং প্রক্রিয়াগুলির এক ধরণের যৌক্তিক ভাঙ্গন থাকা, সেগুলি কীভাবে পরিমাপ করা যায় (অগ্রাধিকারযোগ্য ধারাবাহিকভাবে) এবং কীভাবে প্রক্রিয়াটিকে কিছুটা প্রান্তে পরিবর্তন করা যায় সেই পদ্ধতিগুলি কীভাবে বোঝা যায় তা নির্ধারণ করুন। এটি প্রকল্পটির পুনরাবৃত্তি সম্পর্কে নয়, আপনি কীভাবে প্রক্রিয়াটি পুনরাবৃত্তি করবেন তার ধারাবাহিকতা সম্পর্কে।


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

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

1
@ কেভিঙ্কলাইন সিএমএমআই সাফল্য পেয়েছে বা সফল হয়েছে তা বিবেচ্য নয়। মহাকাশ / প্রতিরক্ষা শিল্পে বসে আমি আমার সংস্থার সিএমএমআই এবং আমরা যে সংস্থাগুলির সাথে কাজ করি সেগুলি দেখতে পাই, আমরা সাব-কন্ট্রাক্টর এবং আমরা সাবকন্ট্র্যাক্ট করি। তবে, আমার বক্তব্যটি হল প্রক্রিয়াটির উন্নতি করার জন্য আপনাকে আপনার প্রক্রিয়াগুলি সনাক্ত করতে হবে। সিএমএমআই হ'ল এটি করার একক সরঞ্জাম। সেখানে অন্যরা আছেন এবং আপনি নিজের সংজ্ঞা দিতে পারেন। আপনার প্রক্রিয়াগুলি একবার হয়ে গেলে আপনি এগুলি সংজ্ঞায়িত করতে, তাদের পরিমাপ করতে এবং তাদের উন্নতি করতে পারেন।
টমাস Owens

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

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

5

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

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

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


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

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

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

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

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

2

সফটওয়্যার হল তাই যেখানে আমরা সেরা আমাদের সময় ব্যয় অর্থনীতি প্রায়ই ভিন্ন, অন্যান্য অধিকাংশ নিয়মানুবর্তিতা চেয়ে ভিন্ন।

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

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

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

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

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

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


2

সফ্টওয়্যারটির পুনঃব্যবহারের ক্ষমতাটি কোনও প্রকল্পের পুনরাবৃত্তি থেকে আসা প্রয়োজনীয় প্রক্রিয়া উন্নতি এবং দক্ষতা রোধ করে?

আমি গত 17 বছর ধরে একই বৃহত প্রকল্পে একটি সিস্টেম এবং সফটওয়্যার ইঞ্জিনিয়ার হিসাবে বিমানের শিল্পে ঘটনাক্রমে (আপনার প্রথম লিঙ্কে এয়ারবাস এ 380 রেফারেন্সের কথা চিন্তা করে) কাজ করেছি, যদিও আমার দায়িত্ব সামরিক বিমান খাতে রয়েছে। এর মতো গল্পগুলি মূলত খাঁটি কল্পকাহিনী, এবং যখন আপনি অন্তর্দৃষ্টি অন্তর্দৃষ্টি পান তখন দেখার জন্য সত্যই মজাদার।

তবে আপনার সংক্ষিপ্ত এবং সংক্ষিপ্ত প্রশ্নের জন্য: আমার অভিজ্ঞতা থেকে, আমি হ্যাঁ এবং না উভয়ই বলব।

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

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

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

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

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

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

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

আহ - ডাং, আবার সাইড ট্র্যাক ... আমার অজুহাত হ'ল আমি 32 ঘন্টা ঘুমাইনি, তাই আমার ফোকাস করার ক্ষমতাটি একটু ... আমি কী বলছিলাম?

কেউ যদি এখনও পড়তে থাকে তবে আমার উপসংহারটি হ'ল:

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

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


সিস্টেমের অভ্যন্তরীণ কাজগুলি না জেনে বেশিরভাগ ডাব্লু বিকাশকারীরা কি এটি পুনরায় ব্যবহারের শক্তিশালী সূচক হিসাবে জানতে পারবেন না? সরকারী প্রকল্পের গল্পগুলি কীভাবে এই ভয়ঙ্কর শব্দটি বেরিয়ে আসে তা আমি মজাদার বলে মনে করি তবে যদি আপনার সরকারী কাজ সম্পর্কে কোনও জ্ঞান থাকে তবে আপনি বুঝতে পারবেন যে লেখক কতটা নির্লজ্জ। 00 1500 হাতুড়ি ইত্যাদি ... যখন আপনি বুঝতে পারবেন যে সরকারী প্রক্রিয়াগুলি কেনার আগে 10 জনকে পর্যালোচনা করে প্রতিযোগিতামূলক উদ্ধৃতি গ্রহণ করতে হবে বা এটি অ্যাকাউন্টিং বালতিগুলির মধ্যে তহবিল সরানো হয়নি।
ডাঙ্ক

আমি জানি না যে কোনও সফ্টওয়্যার ইঞ্জিনিয়ার যিনি বিমানের "সবচেয়ে জটিল" কম্পিউটার সিস্টেমে কাজ করেন 32 ঘন্টা ধরে ঘুমোয়নি। =)
রাবারডাক

2

অন্য প্রোগ্রামারদের প্রশ্নের গৃহীত উত্তরে যেমন উল্লেখ করা হয়েছে , নির্মাণের সাথে উপমাগুলি যত্ন সহকারে নেওয়া উচিত:

এর জন্য একটি প্রস্তাবিত পাঠ্য হ'ল সফটওয়্যার কনস্ট্রাকশন অ্যানালজি হ'ল ভাঙা

সফ্টওয়্যারটি প্রায়শই নির্মাণের সাথে তুলনা করা হয়। দুর্ভাগ্যক্রমে এই সাদৃশ্য ত্রুটিযুক্ত এবং নির্মাণ শিল্পের কাছ থেকে প্রাপ্ত শিক্ষা সন্দেহ হয় ...

আমি যা পর্যবেক্ষণ করেছি তা হল, ভাল সফ্টওয়্যার প্রকল্পগুলি গুণমানের আশ্বাসে পুনরাবৃত্তিযোগ্যতা "শিফট" করে।

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

এখন, এই "সন্দেহভাজন" উপমা অনুসারে, আমাকে এমন একটি নির্মাণ সংস্থা বলুন যে 500 টি সেতু তৈরি করেছে - সমস্ত একই দল সহ।

  • এটি অনুসরণ করে, আমাকে এমন একটি সংস্থা বলুন যা তাদের প্রতিটি নতুন সেতুতে বেশিরভাগ ক্ষেত্রে একই রকম ইট এবং লোহা ব্যবহার করে আসছে (এখানে, আমি এই সত্যটি উল্লেখ করি যে আমরা প্রকাশিত পরীক্ষাগুলিতে বেশিরভাগ দিন একই সপ্তাহে কোডের বিট ছিল, সপ্তাহে সপ্তাহ - "অনেক কিছুই পরিবর্তন হয় না")।
    http://upload.wikimedia.org/wikipedia/commons/thumb/0/0c/GoldenGateBridge-001.jpg/220px-GoldenGateBridge-001.jpg http://upload.wikimedia.org/wikipedia/commons/thumb/5/52/Ponte25Abril1.jpg/220px-Ponte25Abril1.jpg

মাস্টার নির্মাতারা বিশেষজ্ঞরা তাদের অঞ্চলে দশক, শত, বা হাজারো জিনিস ডিজাইন এবং / বা তৈরির জন্য স্বীকৃত are

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

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

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

  • উদাহরণস্বরূপ, আমার অতীতের আরও একটি প্রকল্প (আবার, দর্শনীয় কিছুই নয়, নিয়মিত একটি), এবার দেবের ভূমিকায়, 5 বছরেরও বেশি সময় ধরে চলছে (8 টি বড় রিলিজ, বেশ কয়েক ডজন নাবালিক)। একই ধরণের সাপ্তাহিক চেকপয়েন্টগুলি ছিল (এর 5x52~=250মধ্যে), একই রকম রাতের প্রকাশ ( 5x365~=1800তাদের মধ্যে) এবং একইভাবে একই দেব / কিউএ দলগুলি এতে কাজ করে। দিনে দিনে, সপ্তাহে সপ্তাহে, মাসে মাসে, বেশিরভাগ পুনরাবৃত্ত উপাদান (দুই রাত্রি বিল্ডের মধ্যে খুব বেশি পরিবর্তন হয় না) - প্রতিশ্রুতি অনুসারে, হাজার বার (1800) এর পরিসীমাতে।

উইন্ডোজ বা জাভা বা অটোক্যাডের মতো দীর্ঘজীবী প্রকল্পগুলি 10, 20, 30 বছর পর্যন্ত প্রসারিত হতে পারে, যা সহজেই প্রায় "হাজার হাজার" রাত্রে তৈরি করে এবং রাতের পরীক্ষাগুলি যেমনটি হয় তার পুনরাবৃত্তি করে।


QA তে পুনরাবৃত্তিযোগ্যতার শিফট ধারণার ক্রমাগত সংহতকরণের সাথে আরও বিশিষ্ট হয়ে ওঠে ...

অনুশীলন ... সমস্ত বিকাশকারী কাজের কপিগুলিকে দিনের সাথে একাধিকবার একটি শেয়ারড মাইনলাইন দিয়ে মার্জ করার ... সিআইকে পর্যায়ক্রমিক একীকরণের অনুশীলনের তীব্রতা হিসাবে দেখা যেতে পারে ..

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

Repeatability? এটি ঠিক আছে, এটি যতটা ভাবতে পারে।

ঘন ঘন / অবিচ্ছিন্ন QA দিয়ে, ভুল বিষয়গুলি দ্রুত বিকাশকারীদের কাছে ফিরে আসে যারা ব্যর্থ পরীক্ষাগুলি সফলভাবে পাস না হওয়া পর্যন্ত এটি সঠিকভাবে করার চেষ্টা পুনরাবৃত্তি করতে বাধ্য হয়। এক অর্থে, পুনরাবৃত্তি করার চক্রটি কোড ক্যাটার সাথে সাদৃশ্য না হওয়া অবধি ,

প্রোগ্রামিংয়ের একটি অনুশীলন যা একটি প্রোগ্রামারকে অনুশীলন এবং পুনরাবৃত্তির মাধ্যমে তাদের দক্ষতাগুলিকে বাড়িয়ে তুলতে সহায়তা করে ...


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

@ গ্লেনএইচ 7 হ্যাঁ পুনরাবৃত্তির প্রভাব সত্যই গভীর এবং এটি পরীক্ষার স্যুটগুলির চেয়ে অনেক বেশি এগিয়ে গেছে। জ্ঞান যেখানেই পুনরাবৃত্তি ঘটে সেখানেই জ্ঞান জমে আছে - আপনি জানেন যে সমস্ত কিছু 20 ... 30 ... 50 এর পরে সর্বোত্তম স্থির হয়ে যায়। চেকপয়েন্ট / রাতের প্রস্তুতি, বাগ জমা দেওয়া (এবং পুরো "বাগ লাইফ" মোটেও), দেব / কিউএ / এমজিএমটি / সিসাদমিনস যোগাযোগ, ডকুমেন্টিং স্টাফ ইত্যাদি ইত্যাদি আমি কেবল পুনরাবৃত্তির দিকে মনোনিবেশ করেছিলাম, কারণ প্রাকৃতিকভাবে অনুসরণ করা জ্ঞান আহরণের বিষয়ে ডাইভিং করতাম একটি আছে firehose প্রভাব আমার পয়েন্ট উপস্থাপনা উপর
মশা

-1

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

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

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

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

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


1
আমি মনে করি আপনি কিছু সম্ভাব্য বৈধ পয়েন্টগুলি স্পর্শ করেছেন, তবে আমি প্রশ্নের উত্তর দেওয়ার জন্য সেগুলি একসাথে বেঁধে দেখছি না। এবং আমি পুনরায় ব্যবহারের জন্য আপনার 99: 1 অনুপাতের সাথে একমত নই। আমি মনে করি যে পুনঃব্যবহারটি কতটুকু পর্যালোচনা করে। এমনকি সফ্টওয়্যার দেবের মধ্যেও, পুনরায় ব্যবহারের হারগুলি সেই উচ্চতার কাছাকাছি আর নেই।

-2

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

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


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

আপনার ইতিহাসের দিকে নজর দেওয়া দরকার, সিডিসি 6600 ক্রোনোস ওএসের জন্য মেইনফ্রেম সিস্টেমগুলিতে প্রতি বছর বা তেমন কোনও নতুন প্রযুক্তি প্রকাশিত হয়নি। এটি 15 বছর ধরে মূলত স্থির ছিল। এখন জিনিসগুলি আরও দ্রুত স্থানান্তরিত হয় এবং 15 বছরেরও বেশি সময় ধরে জ্ঞানের গভীরতা অর্জনের সময় নেই। 15 বছর অভিজ্ঞতার সাথে কোনও ফ্ল্যাশ প্রোগ্রামার নেই কেবল উদাহরণস্বরূপ Flash আমার পোস্টটি পুনরায় পড়ার পরে, আমি আমার মূল পোস্টের পাশে দাঁড়িয়ে আছি।
এডওয়ার্ড
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.