সফ্টওয়্যার আর্কিটেক্ট হিসাবে আপনার টেবিলে কী আনা উচিত? [বন্ধ]


20

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

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

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

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

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

আশা করি কিছু পটভূমি ভাগ করে নেওয়ার উপায় হিসাবে আমি এখানে কিছু এসএ গল্প বলেছি যে আমার প্রশ্নের উত্তরগুলিও এই বিষয়গুলিতে কিছুটা আলোকপাত করতে পারে:

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

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

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

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

  1. একটি এসএ টেবিলে কি আনা উচিত?
  2. কীভাবে তারা তাদের সিদ্ধান্ত গ্রহণে ভারসাম্য বজায় রাখতে পারে?
  3. একজনকে কি এসএ চাকরীর (পূর্বের সংজ্ঞায়িত) সাথে মানসিকতার সাথে যোগাযোগ করা উচিত যে তাদের অবশ্যই কিছু স্থল বিধি প্রয়োগ করতে হবে?
  4. আর কিছু বিবেচনা করবেন?

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


যদি এসএ এফএক্সকপ ব্যবহার করে তবে পঙ্গু হবে কেন? এফএক্সকপের সাথে এমনকি বৃহত্তম অ্যাপ্লিকেশনগুলির পর্যালোচনা করতে কয়েক মিনিটের বেশি সময় নেওয়া উচিত নয়।
রবার্ট হার্ভে

দ্বিতীয় বুলেটটি কেবল এসএ-এর মতো ভুল বলে মনে হচ্ছে, যদিও এটি সম্ভবত একটি খারাপ bad তিনি যদি সেগুলি যথেষ্ট করেন তবে সংস্থাটি একটি নতুন এসএ খুঁজে পাবে।
রবার্ট হার্ভে

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

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

একটি এসএ টেবিলে কি আনা উচিত? এক গ্লাস হুইস্কি, একটি বন্দুক এবং দুটি গুলি।
অ্যাডাম ক্রসল্যান্ড

উত্তর:


23

একটি সিস্টেম আর্কিটেক্টের উচিত:

  1. উচ্চ-স্তরের আর্কিটেকচার নির্দিষ্ট করুন
  2. কোড পর্যালোচনায় অংশ নিন
  3. ব্যবহৃত প্রযুক্তি অনুমোদন করুন
  4. বিকাশকারীদের তাদের কোডিং প্রচেষ্টায় সহায়তা করুন
  5. বিকাশ তফসিল বজায় রাখা এবং নিরীক্ষণ
  6. ইউএএমএল ডায়াগ্রাম, গ্যান্ট চার্ট এবং এর মতো এসএ শিল্পকর্মগুলি উত্পাদন করুন।

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

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

সমস্ত মানুষের মতো, এসএও ভুল করতে পারে এবং করতে পারে। ভালগুলি সেই ভুলগুলি থেকে শিখতে পারে এবং আরও ভাল এসএ এর হয়।


৫. প্রজেক্ট ম্যানেজারের জন্য হওয়া উচিত, না?
BЈовић

8

আমি কখনও কোনও আর্কিটেক্টে প্রবেশ করি নি, যিনি দরকারী ছিলেন, মূলত কারণ তারা ব্যবহারিক ছিলেন না।

আমার জন্য আমি সবচেয়ে বড় সমস্যাগুলি হ'ল:

  • প্রক্রিয়া স্বার্থে প্রক্রিয়া অন্ধ অনুসরণ
  • সমস্যাটি জানার আগে প্রযুক্তির অন্ধ পক্ষপাত করুন
  • একটি ভাল ন্যায়সঙ্গত ছাড়াই বিধি তৈরি এবং প্রয়োগ করা
  • rewrite from scratch মানসতা

আমি কাজ করেছি সেরা "স্থপতি" টেবিলে নিয়ে এসেছি:

  • যে সমস্যাগুলি সমস্যা এবং সম্ভাব্য সমাধানগুলি সম্পর্কে আরও ভাল বোঝার দিকে পরিচালিত করে।
  • নকশার বিকল্পগুলি / প্রযুক্তি এবং তাদের ট্রেড অফস।
  • উভয় নিন্দা এবং ডিজাইন এবং প্রযুক্তির অনুমোদনের জন্য সুস্পষ্ট এবং যৌক্তিক ব্যাখ্যা।

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


-1 আপনি স্পষ্টত কখনও ভাল স্থপতি সঙ্গে কাজ করেন নি। আমি যে আর্কিটেক্টদের সাথে কাজ করি তারা প্রথম চারটি পয়েন্টের কোনওটাই করে না।
স্টিফেন

7

1 একটি এসএ টেবিলে কি আনা উচিত?

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

2 তারা কীভাবে তাদের সিদ্ধান্ত গ্রহণের ভারসাম্য বজায় রাখতে পারে?

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

3 কোনও এসএ চাকরীর সাথে যোগাযোগ করা উচিত (পূর্বে সংজ্ঞায়িত) সেই মানসিকতার সাথে যে তাদের অবশ্যই কিছু স্থল বিধি প্রয়োগ করতে হবে?

  • হ্যাঁ, সংস্করণ নিয়ন্ত্রণ এবং বিল্ড সিস্টেমের মতো জিনিসগুলি খুব রঞ্জক গুরুত্বপূর্ণ এবং বিকাশকারীদের এগুলি ব্যবহার করা দরকার। তবে এগুলিকে সমাধানের অংশ বানানো সেরা উপায়।

আরও অনেক কিছুই আছে, আমার মনে হয় এই উত্তরটির জন্য কিছু সত্যিকারের উত্তম উত্তর আসবে।


আপনার পয়েন্টের জন্য +1। তারা যা প্রয়োজন তা পুরোপুরি চিত্রিত করে এবং ভাল, ছোট, ভাল সংহত দলগুলিতে চলে।
টালোনেক্স

3

1. একটি এসএ টেবিলে নিয়ে আসা উচিত?

"তাদের কি 'আইন বিসর্জন' দেওয়ার মানসিকতার সাথে আসা উচিত ... নাকি তাদের প্রাথমিক দিকনির্দেশ এবং কৌশল নির্দিষ্ট করা উচিত, তারপরে জাহাজের দিকনির্দেশনা সংশোধন করার জন্য প্রয়োজনীয় পদক্ষেপে ফিরে যেতে হবে?"

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

যতদূর প্রযুক্তি: আপনি যা পেয়েছেন তা নিয়ে কাজ করুন, যদি সংস্থাটি স্টারটিম ব্যবহার করে তবে আপনি এটিই ব্যবহার করেন। নিজেকে কোনও নির্দিষ্ট পণ্য / প্রযুক্তি / প্রক্রিয়াতে বিয়ে করা আপনার পক্ষে কিছু করতে যাচ্ছে না।

২. কীভাবে তারা তাদের সিদ্ধান্ত গ্রহণে ভারসাম্য বজায় রাখতে পারে?

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

৩.একটা কি এসএ চাকরীর কাছে যেতে হবে (পূর্বে সংজ্ঞায়িত) যে মানসিকতার সাথে তাদের অবশ্যই কিছু স্থির নিয়ম প্রয়োগ করতে হবে?

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

4. অন্য কিছু বিবেচনা?

  • আপনার দ্বিতীয় উদাহরণের রেফারেন্সে: দেখে মনে হচ্ছে যে প্রকল্প টিম একটি ইন-হাউস সাবসিস্টেমের উপর দৃ tight়ভাবে যুগল নির্ভরতা তৈরি করেছে। আলতোভাবে জোড়াযুক্ত মুখোমুখি কেবল তৃতীয় পক্ষের কোডের জন্য নয়। এই সাবসিস্টেমটির জন্য একটি বিমূর্ততা তৈরি করা যদি অভ্যন্তরীণ সমাধান ব্যর্থ হয় তবে লাইব্রেরিটি ব্যবহার করতে আরও সহজ স্থানান্তরকে অনুমতি দেওয়া যেতে পারে। এটি একা একটি সফ্টওয়্যার আর্কিটেক্টের জন্য একটি যৌক্তিক সমাধান, তবে টিম এক্সপ্রেশন উদ্বেগগুলির সাথে প্রজেক্ট ম্যানেজারের ফর্ম হওয়ার কারণে এটি দ্বিগুণ হওয়া উচিত একটি স্পষ্ট সমাধান।
  • আপনার তৃতীয় উদাহরণের রেফারেন্সে: সফ্টওয়্যার তৈরির জন্য একটি পরিচিত স্থাপত্য বা প্রক্রিয়া থাকা কোনও খারাপ ধারণা নয় (যদিও স্বীকার করেই আপনি 'সমস্ত প্রকল্প' বলেছিলেন)। এটি কী কাজ করে তার সাথে লেগে থাকে। যা বলেছিল, এমন সুযোগের দরকার আছে যেখানে নতুন কৌশলগুলি অতিরিক্ত মূল্য নিয়ে আসে কিনা তা দেখার চেষ্টা করা যেতে পারে। কেবলমাত্র ঘরে বসে থাকা সফ্টওয়্যার বা ছোট-স্কোপ প্রকল্পগুলি যেখানে এই প্রযুক্তিগুলির চেষ্টা করা যেতে পারে সেগুলি আদর্শ জায়গা। তবে মনে রাখবেন যে, প্রযুক্তিগুলি গ্রহণের জন্য গবেষক এবং দৃinc়প্রত্যয়ী বিক্ষোভ / যুক্তি সরবরাহ করার জন্য বিকাশকারীরাও দায়বদ্ধ। এবং এসএর সাথে প্রতিযোগী প্রতিটি ওআরএম এবং তার শক্তি এবং দুর্বলতাগুলি অন্যদের তুলনায় জানার আশা করা যায় না।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.