কোনও কোড লেখার আগে আপনি কীভাবে কোনও অ্যাপ্লিকেশনটির আর্কিটেকচার পরিকল্পনা করেন? [বন্ধ]


84

যে বিষয়টির সাথে আমি লড়াই করছি তা কোনও কোড লেখার আগে একটি অ্যাপ্লিকেশনটির আর্কিটেকচার পরিকল্পনা করে।

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

আমি এটি করার এক উপায় ইউএমএলকে সংগ্রহ করি তবে এটির সাথে আমার কোনও অভিজ্ঞতা নেই তাই এটি একধরনের উদাসীন বলে মনে হয়।

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

আমি আপনার ইনপুট প্রশংসা করি।

উত্তর:


32

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


30
নিশ্চিত করুন যে আপনি হোয়াইটবোর্ডে সুপার-সুরক্ষিত "না কাটা" করুন। :)
মুসিজেনেসিস

4
প্রাথমিক ডিজাইনের জন্য আপনি সত্যিই হোয়াইটবোর্ড এবং কাগজকে বীট করতে পারবেন না। এটি সহজ, নমনীয় এবং উদ্বেগজনক।
বুজি বয়

4
আপনি ব্যবহারের পরে হোয়াইটবোর্ডটি কেবল স্তরিত করতে পারেন ...: পি
প্যাট্রিক

41

আমি নিম্নলিখিত বিবেচনা:

  1. সিস্টেমটি কী করার কথা রয়েছে, এটি হ'ল সিস্টেমটি কী সমস্যাটি সমাধান করার চেষ্টা করছে
  2. গ্রাহক কে এবং তাদের ইচ্ছা কি
  3. সিস্টেমের সাথে কী একীকরণ করতে হবে
  4. কোন উত্তরাধিকারের দিক বিবেচনা করা প্রয়োজন আছে?
  5. ব্যবহারকারী ইন্টারঅ্যাকশন কি
  6. ইত্যাদি ...

তারপরে আমি সিস্টেমটিকে একটি ব্ল্যাক বক্স হিসাবে দেখা শুরু করি এবং:

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

তারপরে এটি আপনাকে বিভিন্ন অভ্যন্তরীণ ব্ল্যাক বাক্স সমন্বিত সিস্টেমটির একটি দর্শন দিতে শুরু করবে, যার প্রতিটি একই পদ্ধতিতে আরও ভেঙে যেতে পারে।

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

  • বর্গ চিত্র, এবং
  • ক্রম ডায়াগ্রাম।

আপনার আচরণের চিত্রগুলিও প্রয়োজন হতে পারে যদি আচরণে বর্ণনার দরকার হয় এমন কোনও সমান্তরালতা থাকে।

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

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


18

আপনার অবশ্যই স্টিভ ম্যাককনেলের কোড সম্পূর্ণ হওয়া উচিত - এবং বিশেষত "নির্মাণের নকশা" শীর্ষক তাঁর দেওয়া অধ্যায়ে

আপনি এটি তার ওয়েবসাইট থেকে ডাউনলোড করতে পারেন:

http://cc2e.com/File.ashx?cid=336


এটি খুব ভাল পড়া - অনেক ভাল তথ্য, পরামর্শ এবং ধারণা। খুব দীর্ঘ হয় না।
বুজি বয়

বইটি কিনুন এবং অধ্যায়টি 6 পড়ুন যা পৃথক শ্রেণীর নকশার বিষয়। তারপরে অন্যান্য সমস্ত অধ্যায়গুলিও পড়ুন - এটি খাঁটি সোনার।
মার্কজে

ওহ হ্যাঁ, চতুর্থ অধ্যায়টি অ্যাপ্লিকেশন আর্কিটেকচার সম্পর্কে
মার্ক জে

এই শিল্পে গুরুতর কিছু করার ভান করা প্রত্যেকেরই অবশ্যই সেই বইটি অবশ্যই পড়া উচিত, তারা যে ভূমিকা পালন করবে তা নির্বিশেষে।
চেপেক

9

যদি আপনি .NET- র জন্য বিকাশ করছেন, মাইক্রোসফ্ট সবেমাত্র (একটি বিনামূল্যে ই-বুক হিসাবে!) অ্যাপ্লিকেশন আর্কিটেকচার গাইড 2.0 বি 1 প্রকাশ করেছে । এটি কোনও কোড লেখার আগে আপনার আর্কিটেকচারের পরিকল্পনা সম্পর্কে প্রচুর পরিমাণে ভাল তথ্য সরবরাহ করে।

আপনি যদি মরিয়া হয়ে থাকেন তবে আমি আশা করি আপনি এটি নেট-ভিত্তিক আর্কিটেকচারের জন্য বড় অংশ ব্যবহার করতে পারেন।


এখন আরও একটি সাম্প্রতিক সংস্করণ উপলব্ধ। এটিকে ডাউনলোড করতে হোমপৃষ্ঠায় যান apparchguide.codeplex.com
মার্কজে

8

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

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

এই সময়ের মধ্যে আমার সাধারণত আর্কিটেকচার সম্পর্কে বেশ ভাল ধারণা থাকে। যদি এটি জটিল হয় বা অস্বাভাবিক বিট থাকে - আমার স্বাভাবিক অনুশীলনের থেকে পৃথক জিনিস - বা আমি অন্য কারও সাথে কাজ করছি (আদর্শ নয়), আমি জিনিসগুলি ডায়াগ্রাম করব (আবার হোয়াইটবোর্ডে)। জটিল ইন্টারঅ্যাকশনগুলির ক্ষেত্রেও এটি একই - আমি এই বিভাগটি শেষ না হওয়া পর্যন্ত পৃষ্ঠার বিন্যাসটি ডিজাইন করতে এবং হোয়াইটবোর্ডে প্রবাহিত করতে পারি (বা ক্যামেরার মাধ্যমে ক্যাপচার করে)। আমি কোথায় যাচ্ছি এবং প্রথমে কী করা দরকার তা সম্পর্কে আমার সাধারণ ধারণাটি পরে আমি প্রথম গল্পগুলির জন্য পরীক্ষা লিখতে শুরু করব। সাধারণত, এটি এর মতো হয়: "ঠিক আছে, এটি করার জন্য আমার এই ক্লাসগুলির প্রয়োজন I'll আমি এইটি দিয়ে শুরু করব এবং এটি করা দরকার needs" তারপরে আমি আনন্দের সাথে TDDing শুরু করি এবং আর্কিটেকচার / নকশা অ্যাপ্লিকেশনগুলির প্রয়োজনীয়তা থেকে বৃদ্ধি পায়।

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


5

http://dn.codegear.com/article/31863

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


4

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

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

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

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

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


4

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

মূলত, আমি সঠিক দিকে যাচ্ছি কিনা তা জানার জন্য আমি যতটা সম্ভব কাজ করি।

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

আমি যত তাড়াতাড়ি সম্ভব কিছু সত্যিকারের গ্রাহক মান পাওয়ার দিকনির্দেশে কোড করি, যাতে কোনও গ্রাহক আমাকে বলতে পারেন যে আমার কোথায় যাওয়া উচিত।

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

আসুন একে "চরম প্রোগ্রামিং" বলি।


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

আপনি সেখানে কী করেছেন তা আমি দেখছি


3

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


2

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

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

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

সুতরাং যদি আপনাকে বেশ কয়েকটি বৃহত আর্থিক পোর্টফোলিওগুলি (কার্যকরী স্পেসিফিকেশন) প্রক্রিয়া করার প্রয়োজন হয় তবে আপনি নির্ধারণ করতে পারেন যে আপনাকে এই বৃহত স্পেসিফিকেশনটিকে বিভক্ত করতে হবে:

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

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

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


2

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


1

আমি আমার চিন্তাভাবনা দুটি ভাগে বিভক্ত করার চেষ্টা করি: আমি যে জিনিসগুলিতে হেরফের করতে চাইছি তার একটি প্রতিনিধিত্ব এবং আমি তাদের সাথে কী করতে চাই।

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

এই ডোমেন মডেলগুলিকে ইউএমএল ডোমেন মডেল, বর্গ চিত্র এবং এসকিউএল ইআরডি হিসাবে উপস্থাপন করা যেতে পারে।

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

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


1

সিস্টেমটি কোড করার আগে নিজেকে সম্পূর্ণরূপে চিন্তা করতে আমার নিজেকে সমস্যা হয়। কিছু উপাদানগুলিতে কেবল কার্সারি এক নজরে আনা খুব সহজ, যা আপনি কেবল পরে বুঝতে পেরেছিলেন যে সেগুলি তার চেয়ে বেশি জটিল।

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

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


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