40+ বছরের জীবনকাল সহ ওয়েব অ্যাপ্লিকেশন ডিজাইনের পরামর্শ


73

দৃশ্যপট

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

  • ফর্ম ওয়ার্কফ্লো পরিচালনা
  • ফর্মগুলির তফসিল পরিচালনা
  • সুরক্ষা / ভূমিকা ভিত্তিক পরিচালনা
  • রিপোর্টিং ইঞ্জিন
  • মোবাইল / ট্যাবলেট সমর্থন

পরিস্থিতি

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

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

আমি দ্রুপালের মতো একটি সিএমএস সিস্টেম ব্যবহার করার পরামর্শ দিয়েছিলাম, কিন্তু ক্লায়েন্টের সংস্থায় নীতিগত কারণে, সিস্টেমটি অবশ্যই স্ক্র্যাচ থেকে তৈরি করা উচিত।

এই প্রথম আমি 40+ জীবনকালীন একটি সিস্টেম ডিজাইন করব। আমি কেবল 3-5 বছরের জীবনকালীন প্রকল্পগুলিতে কাজ করেছি, সুতরাং এই পরিস্থিতিটি খুব নতুন, তবুও উত্তেজনাপূর্ণ।

প্রশ্নাবলি

  • কোন ডিজাইনের বিবেচনাগুলি সিস্টেমটিকে আরও "ভবিষ্যতের প্রমাণ" করবে?
  • সিস্টেমটিকে আরও "ভবিষ্যতের প্রমাণ" তৈরি করতে ক্লায়েন্ট / প্রধানমন্ত্রীকে কোন প্রশ্ন জিজ্ঞাসা করা উচিত?

59
ভবিষ্যতের প্রুফিং একটি জিনিস তবে আমি বিশ্বাস করি যে কোনও ক্লায়েন্টের মোবাইল / ট্যাবলেট কম্পিউটিংয়ের বর্তমান ইতিহাসের চেয়ে 10x-20x দীর্ঘ বা ভাষার বর্তমান ইতিহাসের চেয়ে 5x-8x দীর্ঘ লম্বা একটি সফ্টওয়্যার জানতে চাওয়া হবে ব্যবহৃত হয় ... কম্পিউটিংয়ের প্রদত্ত মডেলটির স্থায়িত্ব সম্পর্কে অযৌক্তিক আশাবাদী।

31
40+ বছর 'ভবিষ্যতের প্রমাণ' হিসাবে ডিজাইন করা নিরর্থকতার অনুশীলনের মতো শোনাচ্ছে।
whatsisname

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

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

12
৪০+ বছর ধরে চলতে হবে এমন একটি অ্যাপ্লিকেশন স্থপতি করতে এবং প্রয়োগ করতে 2 জনের জন্য 6 মাস? আপনি কতটা ভাল তা বিবেচ্য নয়, ব্যর্থতার জন্য সেটআপের মতো মনে হচ্ছে। যদি আপনি আপনার সংস্থাকে বোঝাতে না পারেন যে এটি কতটা অযৌক্তিক, তবে আমি আপনাকে অন্য চাকরিটি ASAP হিসাবে সন্ধান করার পরামর্শ দিচ্ছি।
dsw88

উত্তর:


132

ডেটা কিং

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

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

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

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


13
"আমরা সম্ভবত 40 বছরের মধ্যে এই কোডটি ব্যবহার করব না!" এখানেই শুরু করার জন্য একটি Y2K বাগ ছিল। আপনার কোডটি প্রতিস্থাপন করা আশা করা কেবল খারাপ অভ্যাস।
ডগএম

71
Y2K 'বাগ' একটি ডেটা সমস্যা ছিল - 4 এর পরিবর্তে 2 সংখ্যা সংরক্ষণ করা হয়েছিল। যে কারণে আমি ডেটাতে ফোকাস করার পরামর্শ দিই।
গ্র্যান্ডমাস্টারবি

24
ভাল যুক্তি. মনের মধ্যে এই কিপিং, যদি কেউ সত্যিই আশা তাদের তথ্য (এবং সম্ভবত পাশাপাশি ডাটাবেস) এখন থেকে 40+ বছর ব্যবহার হচ্ছে এমন, এটা শ্রেষ্ঠ হতে পারে যতটা সম্ভব কম বিক্রেতা-নির্দিষ্ট বৈশিষ্ট্য সঙ্গে ডাটাবেসের ডিজাইন করতে। আপনার যে সমস্ত কোডটি বিশেষ ওরাকল / এমএস-এসকিউএল / যে কোনও কার্যকারিতা থেকে এখন থেকে 20 বছর ধরে নির্ভর করে আপনার সমস্ত আনট্যাগল / পুনর্লিখন করতে হবে আপনার সাথে সন্তুষ্ট হবে না। ;)
হতাশ

4
এটা কঠিন পরামর্শ। এখনও প্রচুর কোবল প্রোগ্রাম চলছে যা মূলত 20-30 বছর আগে লেখা হয়েছিল written যদিও প্রযুক্তিটি এগিয়ে চলেছে, যদি আপনার ডেটা এবং অবজেক্টের মডেলটি শক্ত হয় এবং ডেটা আগ্রহের থেকে যায় তবে আপনার কোডটি কোনও না কোনও রূপে ব্যবহারে থাকবে।
ববলে

7
যেহেতু কেউ Y2K এনেছেন: ইউনিক্স ওয়াই 2 কে ( en.wikedia.org/wiki/Year_2038_problem ) সম্পর্কে সচেতন হন ।
মিস্টার ফক্স

40

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

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

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

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

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


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

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

3
... কমিট কমপক্ষে এসভিএন সম্পূর্ণ কমিট ইতিহাসের সাথে সম্ভব।
ফিওলা

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

2
আমি প্রস্তাব দিচ্ছি যে আপনি কেবল বাগ ট্র্যাকিং এবং স্পেসিফিকেশন সংখ্যার পরে টেস্টের নাম করবেন না , যেমন: ক) বাগ নম্বরগুলি 0 থেকে শুরু হবে (যেহেতু কেউ পছন্দ করে না> 5-অঙ্কের নম্বর এবং বাগ ট্র্যাকিং সফ্টওয়্যার এক্সচেঞ্জ হয়; খ) নির্দিষ্টকরণের ঝোঁক to get হারিয়ে (কুরুচিপূর্ণ কিন্তু এটি প্রায়শই ঘটে যথেষ্ট); গ) সেক্সি নামগুলি প্রায়শই এটি যথেষ্ট পরিমাণে পরিষ্কার করে দেয়। যদিও, স্পেক / বাগ আইডির একটি রেফারেন্স থাকা সর্বদা একটি ভাল ধারণা।
বার্নস্টেইন

29

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

কোনও ডাটাবেসের আংশিক অ-স্বাভাবিককরণ কোনও মেডিকেল সেটিংয়ে সম্পূর্ণ অপ্রত্যাশিত নয়। মেডিকেল ডাটাবেসের কিছু অংশের বৈশিষ্ট্য রয়েছে যা এএভি (সত্তা / বৈশিষ্ট্য / মান) মডেলের জন্য তাদের উপযুক্ত করে তোলে ।


2
@ user2708395 EAV ডিজাইনটি সম্পর্কে সতর্ক থাকুন কারণ এটি সর্বাধিক পারফরম্যান্ট বা কোয়েরি করা সহজ না। এটি রিপোর্ট করার জন্য ভাল পছন্দ নাও হতে পারে।
maple_shaft

@ ম্যাপেল_শ্যাফ্ট আমি এটিও পড়েছি। আমি এটির সাথে খুব সতর্ক হতে যাচ্ছি যখন আমি এমন কিছু হরর গল্প শুনেছি যেখানে লোকেরা এটি অতিরিক্ত ব্যবহার করে। ক্লায়েন্ট কেবল মাসে একবার রিপোর্ট উত্পন্ন করে কোয়েরি করা সহজ করার জন্য কিছু প্রতিবেদনের ডেটাবেস ব্যবহার করে দেখছেন।
পিট

4
@ ম্যাপেল_শ্যাফ্ট: সাধারণত EAV স্কিমা / ডাটাবেস থেকে আলাদা রিপোর্টিং স্কিমা / ডাটাবেসে ডেটা বের করা হয়।
হতাশ

নিবন্ধন করুন আপনার স্কিমায় যে নমনীয়তা EAV সরবরাহ করে তা মেলে না তবে এটি অবশ্যই সমস্ত অধ্যবসায়ের জন্য রূপালী বুলেট নয়।
ম্যাপেল_শ্যাফ্ট

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

13

সামনের দিকের দৃষ্টিকোণ থেকে উত্তর:

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

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

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

প্রথমত, আপনাকে অফিসিয়াল স্ট্যান্ডার্ড এবং শুধুমাত্র অফিসিয়াল স্ট্যান্ডার্ডগুলিতে কোড করতে হবে । কোনও জাভাস্ক্রিপ্ট বৈশিষ্ট্যগুলি অনুমোদিত অনুমোদিত ECMAScript মানের অংশ নয়; ES5.1 বর্তমান সংস্করণ এবং সাধারণত সমর্থিত তাই এটি লক্ষ্য করা নিরাপদ। একইভাবে, এইচটিএমএল 5, সিএসএস এবং ইউনিকোডের বর্তমান সংস্করণগুলি ভাল। কোনও পরীক্ষামূলক জাভাস্ক্রিপ্ট, সিএসএস 3 বা এইচটিএমএল বৈশিষ্ট্য নেই (যা বিক্রেতা-উপসর্গযুক্ত বা ব্রাউজারগুলির মধ্যে 100% চুক্তি ছাড়াই রয়েছে)। এবং কোনও ব্রাউজার-নির্দিষ্ট সামঞ্জস্য হ্যাক নেই। আপনি একবারে কোনও নতুন বৈশিষ্ট্যটি স্ট্যান্ডার্ডে ব্যবহার করা শুরু করতে পারেন এবং প্রত্যেকে এটি উপসর্গ ছাড়াই সমর্থন করে।

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

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

দ্বিতীয়ত, ট্রেন্ডি জাভাস্ক্রিপ্ট অ্যাপ্লিকেশন ফ্রেমওয়ার্কগুলি এড়িয়ে চলুন, বিশেষত যদি তারা আপনার অ্যাপ্লিকেশনটিকে কোড করার পদ্ধতি পরিবর্তন করে। ব্যাকবোন ছিল সমস্ত ক্রোধ, তারপরে স্প্রাউটকোর এবং এমবার ছিল, এবং এখন অ্যাঙ্গুলারের কাঠামোর প্রত্যেকে প্রচার করতে পছন্দ করে। এগুলি কার্যকর হতে পারে তবে এগুলির মধ্যেও কিছু সাধারণ বিষয় রয়েছে: নতুন সংস্করণগুলি প্রকাশিত হওয়ার সাথে সাথে তাদের অ্যাপ্লিকেশনগুলি ভেঙে দেয় এবং কোড পরিবর্তন করতে হয় এবং তাদের দীর্ঘায়ু প্রশ্নবিদ্ধ। আমি সম্প্রতি একটি কৌণিক 1.1 অ্যাপ্লিকেশনটি 1.2 তে আপডেট করেছি এবং বেশ কিছুটা আবার লিখতে হয়েছিল। একইভাবে, ব্যাকবোন 2 থেকে 3 এ যেতে অনেকগুলি HTML পরিবর্তন দরকার। স্ট্যান্ডার্ডগুলি কোনও কারণে ধীর গতিতে চলছে তবে এই ফ্রেমওয়ার্কগুলি দ্রুত চলে এবং পর্যায়ক্রমে ভাঙা জিনিসগুলি ব্যয়।

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

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

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

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

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

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

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

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


1
'জেএস ফ্রেমওয়ার্কগুলি' সম্পর্কে ভাল পরামর্শ ব্যাকএন্ড ফ্রেমওয়ার্কগুলিতেও প্রযোজ্য। দেখুন আঙ্কেল বব মার্টিন পরামর্শ
ব্রায়ান লো

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

10

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

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

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

REST হ'ল কয়েক দশকের মাপে সফ্টওয়্যার ডিজাইন : প্রতিটি বিবরণ সফ্টওয়্যার দীর্ঘায়ু এবং স্বাধীন বিবর্তনের প্রচার করার উদ্দেশ্যে promote

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724

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

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


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

9

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

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

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


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

7

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

  • বড় ওপেন সোর্স প্রযুক্তি ব্যবহার করুন। ডেটাগুলির জন্য, ক্লোজড-সোর্স সিস্টেমগুলি ঝুঁকির একটি বড় উত্স কারণ কোনও সংস্থা পরিকল্পনা করতে পারে না যে কারা সংস্থাগুলির অধীনে চলেছে বা কৌশলগুলি পরিবর্তন করতে পারে এবং ডেটাতে সমস্ত অ্যাক্সেস নিয়ে তা নিয়ে থাকে। এছাড়াও, একটি প্রাণবন্ত সম্প্রদায় ব্যতীত ছোট ছোট ওপেন সোর্স প্রকল্পগুলির সমর্থন হ্রাস হওয়ার সম্ভাবনাও বেশি।

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

  • ব্যাপকভাবে গৃহীত মানগুলি ব্যবহার করে সিস্টেমটি ডিকুয়াল করুন। ওয়েব পরিষেবাগুলিতে সমস্ত ডেটা অ্যাক্সেস এবং মিউটেশন ভাঙ্গা এই দিকে এক ধাপ। পরিবর্তনগুলি জমা দেওয়ার জন্য বার্তার সারিগুলির সাথে এটি মিশ্রন করা এবং সিস্টেমের স্বতন্ত্র অংশগুলি সময়ের সাথে সাথে ভাষা বা প্রযুক্তি পরিবর্তন করতে সহায়তা করে।


দুর্ভাগ্যক্রমে, একটি স্কিমহীন ডাটাবেস ব্যবহার করার অর্থ এই নয় যে ডেটা পুনর্গঠন এবং পুনর্গঠন শূন্যের জন্য ব্যয় হয়।
অ্যালেক্স ডি

4

ঠিক আছে, তাই আমি এখানে কিছু জিনিস বলতে যাচ্ছি যা সম্ভবত বেশ জনপ্রিয় না হয়, তবে এখানে আমার সাথে থাকুন।

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

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

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

প্রকল্পটিকে দ্রুপালের মতো কিছুতে বাঁধতে চাইলে বোঝায় যে প্রকল্পে এমন লোকের প্রয়োজন কেন যারা এই ধরণের প্রকল্পে কাজ করতে অভ্যস্ত। আপনি অ্যাপ্লিকেশন এমন কোনও কিছুতে বাঁধতে চান না যা কেবল কয়েক বছরের মধ্যে স্টাইলের বাইরে চলে যেতে পারে। যদি আপনি তা করেন, 5-10 বছরে সিস্টেমে কাজ করার জন্য কাউকে খুঁজে পাওয়া খুব দ্রুত খুব কঠিন হয়ে উঠতে পারে।

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


3

অ্যাপ্লিকেশনটি কোনও বিবর্তন ছাড়াই 40 বছর বেঁচে থাকতে হবে না। তবে, এটি স্ক্র্যাচ থেকে তৈরি করা উচিত বা হওয়া উচিত, এটি এখনও 'কার্যকরী' হতে পারে।

সবচেয়ে গুরুত্বপূর্ণ বিষয়টি হ'ল 'ডেটা আর্কিটেকচার' যা কিছু স্থিতিশীলতা ও শাসন ব্যবস্থার পাশাপাশি এক্সটেনসিবলকে মঞ্জুরি দেয়।

আমরা ডেটা আর্কিটেকচার এবং শ্রমশ্রেণীর নকশা তৈরি করেছি যা মানবতার শেষের দিকে প্রায় বেঁচে থাকতে পারে তবে তবুও এটি সম্প্রসারণযোগ্য হতে পারে। আপনার জন্য এটি করার জন্য আপনি একজন সত্যিকারের ডেটা ট্যাক্সোনমি / ডেটা আর্কিটেকচার ব্যক্তির সন্ধান পেয়েছেন।


আমি মনে করি শুরু থেকেই এই প্রকল্পের ব্যর্থতা হ'ল এটি কোনও উপযুক্ত ডেটা আর্কিটেক্ট ছাড়াই শুরু হয়েছিল। এটি অবশ্যই খুব দৃ advice় পরামর্শ।
পিট

আমাকে ফোন করার এবং ভাড়া নেওয়ার সময় :) আমরা কথা বলার সাথে সাথে কিছু সংস্থার জন্য ডেটা গভর্নেন্স এবং ট্যাক্সোনমি জিনিস করা :)
অ্যালেক্স এস

3

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

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

অবসর নেওয়ার আগে আমি যে সংস্থার জন্য কাজ করেছি তার মধ্যে এমন একটি সিস্টেম চলছে যা স্ক্র্যাচ থেকে লেখা হয়েছিল এবং প্রায় 25 বছর ধরে অবিচ্ছিন্নভাবে বৃদ্ধি পেয়েছে এবং এটি মাঝারি খুচরা বিক্রেতার কার্যত সমস্ত দিক কভার করে। এই সিস্টেমের দিকগুলি যা আমি গুরুত্বপূর্ণ মনে করি তা হ'ল:

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

2

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

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

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