নতুন কাঠামো তৈরির জন্য কি সাধারণ নিয়ম বা সেরা অনুশীলন রয়েছে?


17

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

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

আমি নিশ্চিত যে একটি কাঠামো বা গ্রন্থাগারের বিকাশ এবং একটি প্রয়োগের মধ্যে কিছু পার্থক্য রয়েছে are


আমরা কি ধরে নেব ইসিএম মানে এন্টারপ্রাইজ কনটেন্ট ম্যানেজমেন্ট [সিস্টেম]?
মার্ক ক্যানলাস

হ্যাঁ, আমি আলফ্রেসকো
Andrea Girardi

উত্তর:


14

ফ্রেমওয়ার্ক বর্জ্য সিন্ড্রোম এড়াতে প্রথমে আমার 2 টি বিধি এখানে রইল:

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

আপনি সেগুলি পাস করার পরে এটি পরীক্ষা করে দেখুন:


1
আমি যুক্ত করব যে আপনি যদি এমন একটি কাঠামো খুঁজে না পান যা আপনার ৮০/২০ বিধি পূরণ করে তবে আপনি অত্যন্ত অনন্য ডোমেইনে কাজ করছেন বা আপনি নিজের ডোমেনটি যথেষ্ট পরিমাণে বুঝতে পারছেন না।
এলগ্রিঙ্গো গ্র্যান্ডে

5

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

2) ডকুমেন্টেশন, ডকুমেন্টেশন, ডকুমেন্টেশন।

3) ডকুমেন্টেশন, ডকুমেন্টেশন, ডকুমেন্টেশন।


3

বেদনাদায়ক অভিজ্ঞতা এবং প্রচুর অপচয় করার প্রচেষ্টা এই পরামর্শের দিকে পরিচালিত করে: কার্যকারী সফ্টওয়্যার থেকে একটি কাঠামো বের করুন বা রিফ্যাক্টর করুন। আপনি ভবিষ্যতে একটি কাঠামো বের করতে চাইবেন মনে করে এই সফ্টওয়্যারটি তৈরি করুন তবে প্রথমে কাঠামোটি তৈরি করবেন না।


3

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


2

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

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

3) আপনি কী কাঠামোটি অর্জন করতে চান, বাস্তববাদী লক্ষ্য এবং সামগ্রিক অগ্রাধিকারগুলি নিয়ে নিজের জন্য একটি প্রকল্প সংক্ষিপ্ত সেট করুন।

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

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


2

আমি যা বলেছি তার সাথে অনেকটা একমত এবং আমার মনে হয় আরও কিছু অব্যাহত রেখে গেছে তাই আমি শুরু থেকে শুরু করব।

চতুর পদ্ধতি

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

ব্যক্তি ও পারস্পরিক ক্রিয়ার উপর প্রক্রিয়া এবং সরঞ্জাম
ওয়ার্কিং সফ্টওয়্যার উপর ব্যাপক ডকুমেন্টেশন
গ্রাহক সহযোগিতা উপর চুক্তি আপস
জবাবে পরিবর্তন করতে উপর একটি পরিকল্পনা নিম্নলিখিত

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

যোগাযোগ

যে কাঠামোটি তৈরি করছে তাকে জানতে হবে:

  1. এটি কীভাবে ব্যবহৃত হবে: টার্গেট অ্যাপ্লিকেশন
  2. কী সমস্যাটি সমাধান করার উদ্দেশ্যে এটি করা হয়েছে: লক্ষ্য সমস্যা
  3. কে এটি ব্যবহার করবেন: লক্ষ্য শ্রোতা

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

শৈলী

বলা বাহুল্য, একটি প্রোগ্রামিং স্টাইল / ফর্ম্যাট স্থাপন করুন এবং এটির সাথে আটকে দিন।

ই এর

  1. পরিমিতি : কোডটি প্রোগ্রাম্যিকভাবে ব্যবহার করুন, আক্ষরিক নয়।
  2. দক্ষতা : আপনার কোডটি পুনরায় ব্যবহারের উদ্দেশ্যে। গতির কোনও ক্ষয়ক্ষতি বহুগুণে বৃদ্ধি পায়।
  3. রক্ষণাবেক্ষণযোগ্যতা : আপনি বলেছেন প্রোগ্রামগুলিকে সংশোধন না করে বেশ কয়েকটি প্রোগ্রাম আপডেট করার জন্য ফ্রেমওয়ার্কটি সম্পাদনা করতে সক্ষম হতে চান।
  4. ব্যবহারযোগ্যতা : অ্যাপ্লিকেশনগুলি হুপের মাধ্যমে ঝাঁপ না দিয়ে আসলে কী আপনার কাঠামোটি ব্যবহার করতে পারে?
  5. ব্যবহারিকতা : যদি আপনাকে এমনটি না করতে হয় তবে চাকাটি পুনর্নবীকরণ করবেন না। আপনার কাঠামো অন্যান্য ফ্রেমওয়ার্কের উপর নির্ভর করতে পারে।
  6. অপ্রয়োজনীয়তা : ব্যাতিক্রম / ত্রুটিগুলি ধরুন। সব জায়গা। এগুলি পরিচালনা করুন। সব জায়গা। ত্রুটিগুলি পরিচালনা করতে স্থানীয় সুযোগে কোনও কোড ছাড়া কখনও বিশ্বাস করবেন না, এমনকি যদি আপনি জানেন যে এটি এটি করে।

পি.এসই তে স্বাগতম! আমি আপনার কাঠামোর ব্যতিক্রম ধরায় w / # 6 এ সম্মত নই agree আমি একটি বড় বিশ্বাসী যে কাঠামোটি একটি পরম ব্র্যাট হওয়া উচিত এবং ব্যতিক্রমগুলি ছুঁড়ে ফেলা উচিত এবং এগুলি ধরার জন্য ফ্রেমওয়ার্কটি ব্যবহার করে বা (আরও ভাল) তাদের কোডটি পুনরায় তৈরি করতে যাতে ব্যতিক্রম এড়াতে - কনভেনশন অনুসারে উত্সাহিত করা উচিত।
জারোদ নেটটলেস

0

আমি নিশ্চিত যে একটি কাঠামো বা গ্রন্থাগারের বিকাশ এবং একটি প্রয়োগের মধ্যে কিছু পার্থক্য রয়েছে are

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

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

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

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

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

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