কোন নির্দিষ্ট অনুশীলনগুলিকে "সফটওয়্যার ইঞ্জিনিয়ারিং" না বলে "সফটওয়্যার কারিগর" বলা যেতে পারে? [বন্ধ]


11

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

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

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

কোনও সফ্টওয়্যার কারিগর যে নির্দিষ্ট কাজগুলি করতে পারে যা কোনও সফ্টওয়্যার ইঞ্জিনিয়ার (সম্ভবত কোনও খারাপ) সম্ভবত না করতে পারেন?


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

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

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

নিজেকে দেওয়ার জন্য এটি কেবল সত্যই এক মজাদার শিরোনাম বলে মনে হচ্ছে।
মাইকেলসনোডেন

উত্তর:


13

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

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

কিছুটা আবেগ ঘাম না ভেঙে এই সমস্তগুলিকে coversেকে দেয়।


আমি মনে করি যে শেষটি বিশেষভাবে গুরুত্বপূর্ণ
লভিস

7

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

আমার এক অধ্যাপক হিসাবে একবার বলেছিলেন (প্যারাফ্রেসড): "একজন সফটওয়্যার ইঞ্জিনিয়ার হিসাবে, কেবল সফটওয়্যার সরবরাহ করা আপনার কাজ নয় software আপনার গ্রাহকদের খুশি করে এমন সফ্টওয়্যার সরবরাহ করা আপনার কাজ।"

কোনও সফ্টওয়্যার কারিগর যে নির্দিষ্ট কাজগুলি করতে পারে যা কোনও সফ্টওয়্যার ইঞ্জিনিয়ার (সম্ভবত কোনও খারাপ) সম্ভবত না করতে পারেন?

কিছুই নয় - প্রকৌশলী হলেন একজন কারিগর ... তবে আরও কিছু। ইঞ্জিনিয়ারিং কারুশিল্পের উপর ভিত্তি করে।

কারিগর এবং প্রকৌশলী হিসাবে আপনি কিছু দক্ষ ব্যক্তি, কিছু শিক্ষার এবং অভিজ্ঞতার সংমিশ্রণের মাধ্যমে। আপনি প্রতিষ্ঠিত পদ্ধতি অনুসরণ করুন। আপনিও বাস্তববাদী এবং বুঝতে পেরেছেন যে কী ভেঙে গেছে এবং আরও ভাল হওয়া দরকার।

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


2
এবং আপনার অভিজ্ঞতার ব্যাক আপ করার জন্য আপনার অবশ্যই একটি শিক্ষা রয়েছে - আপনি "ফর্মাল" না বলে খুশি।
বিশ্বাসঘাতক

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

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

1
আমি অসম্মতি, একজন প্রকৌশলী না অগত্যা কারিগর।
নিকোল

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

2

সফ্টওয়্যার কারুশিল্প আন্দোলনটি "traditionalতিহ্যবাহী" সফটওয়্যার ইঞ্জিনিয়ারিংয়ের ব্যর্থতা এবং অসন্তুষ্টিজনক ফলাফলের প্রতিক্রিয়া হিসাবে শুরু করা হয়েছিল যা আজ (কিছু বিকাশকারীদের গাফিলতির পাশাপাশি) আমাদের পেশার প্রতি স্টেকহোল্ডার এবং ব্যবহারকারীদের অবিশ্বাসের দিকে নিয়ে যায়।

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

ডাব্লু কারুশিল্প প্রযুক্তিগত অনুশীলন যেমন:

  • সলিড ডিজাইনের নীতিগুলি
  • নকশা নিদর্শন
  • টিডিডি ("ডাবল এন্ট্রি অ্যাকাউন্টিং" রূপক)
  • ...

এবং দল / সাংগঠনিক অনুশীলন:

  • পেয়ার প্রোগ্রামিং
  • মেন্টরিং
  • কোড কাটস
  • Dojos / কোড পশ্চাদপসরণ
  • ...

সুতরাং আমি বলব যে 2 এর মধ্যে পার্থক্যটি স্পষ্ট: সফ্টওয়্যার কারিগর 40+ বছরের অস্তিত্বের সময়ে সফটওয়্যার ইঞ্জিনিয়ারিংয়ের যে সমস্যাগুলির একটি বড় অংশকে সম্বোধন করার চেষ্টা করে যা আজ আমাদের শৃঙ্খলাটিকে অবিশ্বাস্য এবং ব্যর্থতার ইতিহাসে পঙ্গু দেখায়।


1
আমি একমত নই - সফ্টওয়্যার ইঞ্জিনিয়ারিং ব্যর্থ হওয়ার কারণ এটি ছিল যে ইঞ্জিনিয়ার নেই, কেবল কারিগররা ইঞ্জিনিয়ার হওয়ার ভান করে। নাসা কারিগরদের ব্যবহার করে চাঁদে মহাকাশযান পাঠায়নি!
gbjbaanb

@gbjbaanb আমি মনে করি এটি সম্পূর্ণ বিপরীত - আমাদের প্রকৌশলী ছিল, এবং এ কারণেই তারা অন্যান্য শিল্প থেকে একটি traditionalতিহ্যবাহী ইঞ্জিনিয়ারিং মডেল এবং মানসিকতার সফ্টওয়্যারটিতে পরীক্ষা করার চেষ্টা করেছিল, তবে এটি কার্যকর হয়নি।
guillaume31

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

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

সফ্টওয়্যার প্রসঙ্গে দয়া করে "ইঞ্জিনিয়ারের মানসিকতা" সংজ্ঞায়িত করুন।
guillaume31

1

Http://manifesto.softwarecraftsmanship.org/ দ্বারা যাচ্ছি আমি নিম্নলিখিতটি প্রকাশ করব।

একজন কারিগর একজন "ইঞ্জিনিয়ার" সম্পর্কে প্রচলিত ধারণা থেকে আলাদা কারণ কারণ is

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

4
সত্যি বলতে, এই বুলেট পয়েন্টগুলির সমস্তই একজন ভাল ইঞ্জিনিয়ারকে বর্ণনা করে। বিশেষত 1, 2, এবং 4
থমাস Owens

@ থমাস ওভেনস এবং খারাপ ইঞ্জিনিয়ারের কী হবে? তিনিও কি কারিগর? বা ভাল বনাম খারাপ কারিগর?
ইওফোরিক

@ ইউফোরিক আমি মনে করি না আপনি ভাল কারিগর না হয়ে আপনি একজন ভাল ইঞ্জিনিয়ার হতে পারবেন। এটি একটি মঞ্চযুক্ত মত। "ভাল ইঞ্জিনিয়ার" অর্জনের আগে আপনাকে অবশ্যই "ভাল কারিগর" অর্জন করতে হবে। তবে আপনি একজন ভাল কারিগর হতে পারেন এবং একজন ভাল ইঞ্জিনিয়ার হতে পারবেন না।
টমাস Owens

1

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

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

একজন প্রোগ্রামার একটি বগি প্রোগ্রাম করে বা অযোগ্যতার কারণে কোনও প্রকল্প ব্যর্থ করে দেয় এবং প্রোগ্রামিং চালিয়ে যেতে সে নির্দ্বিধায়।

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


0

প্যাটার্নগুলি রিফ্যাক্টরিং।

এটি হ'ল এমন কিছু তৈরি করুন যা 90% সফ্টওয়্যার প্রয়োজনীয়তাকে সন্তুষ্ট করে, তারপরে পুরো প্রকল্পটিকে কিছু পরিষ্কার, মার্জিত ডিজাইনে রূপান্তরিত করে।

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

সফ্টওয়্যার ইঞ্জিনিয়ারিং পরিবর্তে আপনাকে এই মুহুর্তে সফ্টওয়্যারটি স্থিতিশীল করার পরামর্শ দেবে ।

তদ্ব্যতীত, কোনও প্রকল্প যদি প্রথম থেকেই সেই মার্জিত নকশা দিয়ে শুরু না করে, তবে সফ্টওয়্যার ইঞ্জিনিয়ারিং অনুসারে , এটি একটি খারাপ সম্পাদিত প্রকল্প হিসাবে বিবেচিত হবে (প্রকল্পের ফলাফল নির্বিশেষে),

স্পাইক সমাধান।

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

অবচয় , যে কারণেই হোক।

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

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

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


-1

আমি বলব যে কোডের 100% কভার করে ইউনিট পরীক্ষা করা ভাল হবে। যেহেতু অতিরিক্ত জিনিসগুলি দূরে সরাতে দেয়।

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

স্পষ্টতই আপনি এটিকে অনেক দূরে নিতে পারেন। কেউ বলছেন না যে একটি ছোট চকচকে নুড়ি একটি ভাল ভাস্কর্য: এস


3
আমরা এখানে কত চকচকে কথা বলছি? :-)
ক্রিস

1
বেশিরভাগ সময় আমি এটির সাথে একমত হই - তবে আমি নিশ্চিত না যে কঠোরভাবে 100% সর্বদা সার্থক - যেমন গিটার / সেটার যেখানে তাদের কোনও যুক্তি নেই। এছাড়াও উত্পন্ন কোডটি ইউনিট পরীক্ষা ছাড়াই সাধারণত ভাল বামে থাকে (যদিও ইন্টিগ্রেশন টেস্টগুলি উপযুক্ত হতে পারে)
FinnNk

@ ফিনন্ক - আমি সম্মত আমি সম্প্রতি ডটকভার ব্যবহার করেছি এবং এটি বলে যে কোনও গেটর / সেটার যদি এটি অন্য পরীক্ষায় ব্যবহৃত হয় তবে এটি আচ্ছাদিত। সুতরাং, আমি প্রকৃতপক্ষে প্রতিটি প্রাপ্তি এবং সেটটারের জন্য একটি পরীক্ষার পদ্ধতি বোঝাতে চাইনি
অ্যান্টনি স্কট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.