আমি কীভাবে ডিজাইন করা বন্ধ করব এবং আমার নেতৃত্বের পরামর্শ অনুসারে এই প্রকল্পটির আর্কিটেকচার শুরু করব? [বন্ধ]


42

আমি একজন জুনিয়র বিকাশকারী (years 3 বছর 'এক্সপ্রেস) এবং আমার চাকরিতে আমরা একটি নতুন সিস্টেমের আর্কিটেকচার প্রক্রিয়াধীন। আমার সীসা বিকাশকারী হবেন মূল স্থপতি, তবে তিনি নিজে আমাকে (সমান্তরালভাবে) সিস্টেমটি আর্কিটেকচার করার চেষ্টা করার জন্য আমাকে চ্যালেঞ্জ জানিয়েছেন।

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

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

আমি কীভাবে সফ্টওয়্যার ডিজাইনার মোড থেকে বেরিয়ে আর্কিটেক্টের মতো ভাবতে শুরু করব?


এখানে আমি "ডিজাইন" এর কয়েকটি উদাহরণ দিয়েছি যা এগুলি আমার নেতৃত্বের দ্বারা স্থাপত্যের সাথে প্রাসঙ্গিক হিসাবে দেখা যায়নি:

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

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


প্রকল্প সম্পর্কে আরও কিছু সুনির্দিষ্ট বিবরণ এখানে :

  • আমরা যে প্রকল্পটি নির্মাণ করছি সেটি হ'ল একটি ওয়েব অ্যাপ্লিকেশন।
  • আমি কোডের প্রায় 10-100 হাজার লাইনের অনুমান করছি।
  • আমরা একটি শুরু। আমাদের ইঞ্জিনিয়ারিং টিম প্রায় 3-5 জন।
  • আমাদের অ্যাপ্লিকেশনটির সাথে আমি যে নিকটতম জিনিসটির সাথে তুলনা করতে পারি তা হ'ল একটি লাইটওয়েট সিএমএস। এটিতে একই রকম জটিলতা রয়েছে এবং মূলত উপাদান লোডিং এবং আনলোড, লেআউট পরিচালনা এবং প্লাগ-ইন শৈলী মডিউলগুলির সাথে কাজ করে।
  • অ্যাপ্লিকেশনটি আজাক্স-ওয়াই। ব্যবহারকারীর ক্লায়েন্টটি ডাউনলোড করার পরে সার্ভার থেকে এটি যেমন প্রয়োজন তেমন অনুরোধ করে।
  • আমরা এমভিসি প্যাটার্নটি ব্যবহার করব।
  • অ্যাপ্লিকেশনটির প্রমাণীকরণ থাকবে।
  • আমরা পুরানো ব্রাউজার সমর্থন (হাব!) সম্পর্কে খুব বেশি উদ্বিগ্ন নই, তাই আমরা সর্বাধিক যে সর্বশেষ এবং সর্বাধিক যে সর্বাধিক তা পাওয়া যায় এবং তা বেরিয়ে আসবে le (HTML5, CSS3, WebGL ?, মিডিয়া উত্স এক্সটেনশান এবং আরও অনেক কিছু!)

প্রকল্পের কয়েকটি লক্ষ্য এখানে রয়েছে :

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


78
স্থপতি কোনও টুপি পরে না, বরং একটি বিমূর্ত মাথা সুরক্ষা ব্যবস্থা কল্পনা করে।
জন রেয়নর

3
আপনি যে ধরণের জিনিস নিয়ে এসেছিলেন তা কি ভাগ করে নিতে পারেন? আমি আর্কিটেকচারকে বাস্তবায়ন অজ্ঞাব্য হিসাবে বর্ণনা করতে দ্বিধা বোধ করছি ... শয়তান সর্বদা বিশদে থাকে। এটি বলেছিল, আপনি বিশদটি বড় ছবিটিকে অস্পষ্ট করতে চান না। বেশি তথ্য না থাকলে কেসের বিষয়টি বলা মুশকিল।
টেলাস্টিন

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

3
@ ড্যারিল: আমি অবশ্যই এটি শেখার উপযুক্ত বলে মনে করি, যদিও আমি আপনার স্থপতিদের সাথে মিলিয়ে জানতে পারি যে তিনি আসলে কোন চিত্রটি ব্যবহার করছেন (কিছু ইউএমএল প্রশ্নবিদ্ধ মূল্যবান)।
রবার্ট হার্ভে

উত্তর:


26

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

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

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

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

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

আপনার পরিস্থিতির জন্য আর্কিটেকচারের অন্যান্য উদাহরণ:

  1. ভার্চুয়াল মেশিনে পুরো জিনিসটি রাখা, একটি ক্লাউড সরবরাহকারী বা ঘরে বসে এবং স্টেটলেস মেশিনের দৃষ্টান্ত স্থাপন করা, যাতে যে কোনও মেশিন ব্যর্থ হয় কোনও ভার্চুয়াল মেশিনের নতুন উদাহরণ দিয়ে প্রতিস্থাপন করা যায় কোনও রাজ্যে অনুলিপি না করে বা কোনও তথ্য না হারিয়ে losing
  2. বিশৃঙ্খলা সিমিয়ানদের সাথে শুরু থেকেই লাইভ উত্পাদন ব্যর্থতার পরীক্ষায় বিল্ডিং ।

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


আমি যে ধরণের প্রকল্পের সাথে কাজ করছি তার আশেপাশে আমি আরও কিছু নির্দিষ্টতা যুক্ত করেছি। (পিএস উত্তরের জন্য ধন্যবাদ! আমি প্রসেসিং করছি সেখানে প্রচুর সহায়ক বিশদ রয়েছে))
ড্যারিল

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

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

যদিও এখানে প্রায় সমস্ত উত্তর সহায়ক হয়েছে, আপনার সম্ভবত সম্ভবত সবচেয়ে সহায়ক হয়েছে এবং সম্প্রদায়টিকেও এটি সবচেয়ে দরকারী বলে মনে হচ্ছে।
ড্যারিল

16

আমি যেখানে কাজ করি এই দুটি ধারণার মধ্যে পার্থক্যটি সত্যই গুরুত্বপূর্ণ।

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

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

আমি কী কাজ করেছি তার কিছু উদাহরণ:

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

সেখানে কোনও কোড নেই। যে কোনও ভাষায় লেখা যেতে পারে। বাস্তবায়ন এই বিবরণ দ্বারা নির্ধারিত হয় না।

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

আবার, এখানে কিছুই বাস্তবায়ন নির্দেশ করে না, যদিও কিছু বাস্তবায়ন অন্যদের তুলনায় স্পষ্টভাবে বেশি কার্যকর।

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


2
আপনার প্রাকৃতিক ভাষার পার্থক্যটি আকর্ষণীয় এবং আমার লক্ষ্যটির জন্য খুব সহায়ক। ধন্যবাদ!
ড্যারিল

14

সম্ভবত এটি সাহায্য করবে। তারা নিজেরাই কত বড় সমস্যা সমাধান করতে পারে এই প্রশ্ন হিসাবে আমি একজন ইঞ্জিনিয়ারের সিনিয়রটি সর্বদা দেখেছি।

মোটামুটিভাবে, ধারণাটি জানাতে:

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

  • মিড-লেভেল দেব এমন কোনও ব্যক্তি যিনি কোনও অ্যাপ্লিকেশনের কিছু অংশের বিবরণ নিতে পারেন এবং এটিকে সেই অ্যাপ্লিকেশনের প্রেক্ষাপটে কাজ করতে পারেন।

  • কোনও সিনিয়র দেব কোনও দোকানটির প্রযুক্তিগত সীমাবদ্ধতার মধ্যে স্ক্র্যাচ থেকে মাঝারি আকারের অ্যাপ্লিকেশন তৈরি করতে পারেন।

  • আরও সিনিয়র দেব এটি করতে পারেন এবং প্রযুক্তিগুলি কীভাবে ব্যবহার করতে হবে এটি ভালভাবে চালিত করতে পারে সে সম্পর্কে প্রযুক্তিগত পছন্দগুলি তৈরি করতে পারে।

... তবে এগুলি কঠোর এবং দ্রুত নিয়ম নয়। এবং কিছু লোক "সিনিয়র" আইএমএইচও হিসাবে গেট থেকে বেরিয়ে আসে, এমনকি তাদের যদি কিছু আলাদা শিরোনাম সহ কিছুটা সময় ব্যয় করতে হয়।

স্থপতি যা জিজ্ঞাসা করছেন তা হ'ল সমস্যাটির চেয়ে আরও সাধারণভাবে দেখার। সিস্টেমটি কাজ করতে আপনাকে যদি বেশ কয়েকটি অ্যাপ্লিকেশন একসাথে রাখতে হত:

  • আপনার কি অ্যাপ্লিকেশন এবং পরিষেবাগুলির প্রয়োজন হবে?
  • কোন টুকরা গ্রাহকদের সাথে ইন্টারেক্ট করে এবং কোনটি একে অপরের সাথে যোগাযোগ করে?
  • তারা কীভাবে যোগাযোগ করবে?
  • তারা কোথায় তথ্য সংরক্ষণ করবে?
  • ব্যর্থতার ঝুঁকি কোথায়?
  • আপনি কিভাবে নির্ভরযোগ্যতা প্রদান করবেন?
  • কীভাবে সুরক্ষা দেবেন?

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

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

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

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

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


2

"ডিজাইন" এবং "আর্কিটেকচার" এর মধ্যে সঠিক পার্থক্যটি কিছুটা বিষয়ভিত্তিক এবং কিছুটা ওভারল্যাপ রয়েছে। তবে, আমি এটি বুঝতে পারছি বলেই এই পার্থক্য:

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

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

ডিজাইনে প্রোটোটাইপিং, কোড ইন্টারফেস, কোড কঙ্কাল ইত্যাদি স্কেচিং অন্তর্ভুক্ত এটি অ্যাবস্ট্রাক্ট আর্কিটেকচার এবং নিম্ন স্তরের "কোড বানর" কাজের মধ্যে বসে।

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

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

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


2

আমি যদি এখানে কিছু যুক্ত করতে পারি তবে এটি হ'ল কোড মনে করবেন না । মোটেই

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

আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে, আমার মতে আরও স্থাপত্য প্রশ্নগুলি এর লাইনের সাথে থাকবে:

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

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


1

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

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

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

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

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

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

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


0

বিকাশকারী হিসাবে আপনি সম্ভবত সমাধান সরবরাহ করতে অভ্যস্ত are এটি ভাবনার একটি খুব ভাল উপায়, তবে আর্কিটেকচার সম্পর্কে চিন্তাভাবনার ক্ষেত্রে এটি আপনাকে বাধা দিতে পারে।

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

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

এবং যেহেতু এটি একটি শেখার অভিজ্ঞতা, তারা নির্বোধ হলেও প্রশ্ন জিজ্ঞাসা করতে ভয় পাবেন না।


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