শেষ ব্যবহারকারীদের নাম পরিবর্তন হলে আমাদের কতদূর কোড এবং ডেটা নামকরণ করা উচিত?

Question

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

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

• সিএসএস শ্রেণি যা বোতামটি সবুজ করে তোলে: ".অ্যাকসেপ্টেড";
• মডেল পদ্ধতি যা ডিওএম নোডে শ্রেণি বৈশিষ্ট্য যাচাই করে এবং বাঁধে: "isAccepted";
• জাভাস্ক্রিপ্ট স্থিতি বৈশিষ্ট্য: "পর্যালোচনা করা", "গৃহীত" এবং "প্রকাশিত" সহ অ্যারে;
• মাইএসকিএল স্থিতি কলাম: "পর্যালোচনা করা", "স্বীকৃত" এবং "প্রকাশিত" সহ ENUM;
• পরীক্ষার নাম;

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

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

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

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

Comments

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

— রবার্ট হার্ভে

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

— একক

আমি কেবল ডিবিতে ডেটা স্থানান্তর সম্পর্কে চিন্তা করতে হবে। এটি যদি 1000 রেকর্ড হয় তবে সন্দেহ নেই। এটি স্থানান্তর! এটি যদি 1000000 এর চেয়ে বেশি হয় তবে আমি ভাবতে পারি। তবে এখনও ভাবেন যে 1 মিলের সাধারণ আপডেটগুলি খুব দ্রুত হবে be আপনি উল্লিখিত সমস্ত জিনিস আমার জন্য নতুন নাম।

— পাইওটার পেরাক

এর জন্য ডেটা মাইগ্রেশন করার দরকার নেই, এটি মাইএসকিউএল থেকে আইডিটি ব্যবহার করতে হবে (বা

— এনএমএসের

Answer 1

আমার জন্য, প্রশ্নযুক্ত আইটেমের সাথে সম্পর্কিত সমস্ত কিছু পরিবর্তন করা অবশ্যই সেরা।

এটি কোড অবক্ষয়ের একটি রূপ, এবং 1 টি আইটেম পরিবর্তন না করা কোনও বড় ব্যাপার নাও হতে পারে, এটি কোড বেসের জন্য সুর নির্ধারণ করে।

এটি ভবিষ্যতে বিভ্রান্তির দিকেও নিয়ে যেতে পারে এবং কোড ডেভেল / ডোমেন বুঝতে নতুন ডেভসকে আরও শক্ত করে তুলতে পারে।

Comments

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

— মেটাফাইট

Answer 2

প্রশ্নের সামগ্রী এবং ট্যাগগুলি থেকে আমি বিশ্বাস করব যে আপনি সর্বব্যাপী ভাষা ব্যবহার করছেন।

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

আমি সাধারণত যা করেছি (এবং সম্পন্ন দেখেছি) তা হ'ল:

• 1-শট আপফ্রন্ট রিফ্যাক্টরিং: আপডেট ভাষাটি গ্রহণের জন্য অ্যাপ্লিকেশনটির সমস্ত স্তরকে রিফ্যাক্টর; অথবা
• লগ প্রযুক্তিগত debtণ: আপনি এখনই ব্যবহারকারীর মুখোমুখি কোডটি পরিবর্তন করতে পারেন, এবং তারপরে আপডেট হওয়া ভাষার সাথে তাল মিলিয়ে বাকী অ্যাপ্লিকেশন স্তরগুলি আনতে প্রযুক্তিগত debtণ সংক্রান্ত কার্যগুলি লগ করুন। এটি সাধারণত এক মুঠো বোরিং (তবে পরিচালনাযোগ্য) কার্যের ফলস্বরূপ। (সন্ধ্যা 5 টায় পারফেক্ট!)

আমি মনে করি এখানে মূল জিনিসটি হ'ল আপনি যা বর্ণনা করছেন তা প্রযুক্তিগত debtণ এবং এটি হিসাবে স্বীকৃত হওয়া উচিত।

আমার কাছে এমন ম্যানেজার রয়েছে যারা যুক্তি দিয়েছিলেন যে আমাদের এমন তুচ্ছ কাজগুলিতে সময় নষ্ট করা উচিত নয় যা কোনও দৃশ্যমান কার্যকারিতা যুক্ত করে না। এই যখন ঋণ উপমা সত্যিই উপকারে আসে। এটি এই পর্যন্ত ফোটে:

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

Answer 3

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

সেই জায়গায়, কেবল আপনার কোডে এমন শর্তাদি ব্যবহার করুন যা সর্বাধিক বিস্তৃত বোঝা যায় understood বিকাশকারীরা এটি জানেন এবং এটি আশা করতে পারে তাই ডোমেন থেকে নামগুলি চয়ন করুন।

Comments

আমি মনে করি ওপি অন্যরকম সমস্যার কথা বলছে। তিনি যে প্রতিবন্ধকতাগুলি বর্ণনা করছেন তা সর্বব্যাপী ভাষা ( c2.com/cgi/wiki?UbiquitousLanguage ) ব্যবহার করা থেকে শুরু হয়েছে seem ইউএলটি ব্যবহার করার সময় আপনি আসলে আপনার কোডটিকে ইউআই হিসাবে একই ভাষা (বিশেষ্য, ক্রিয়া) ব্যবহার করতে চান।

— মেটাফাইট

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

— ক্রিস

L10n এর জন্য আর একটি ক্ষেত্রে যখন বিপণন তাদের নিজস্ব শর্তাদি আবিষ্কার করার সিদ্ধান্ত নেয়।

— বার্ট ভ্যান ইনজেন শেনাও

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

— মেটাফাইট

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

— রিবল্ডেডিডে

Answer 4

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

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

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

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

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

3. প্রোগ্রামার কোডটি ডিবাগ করলে, সে প্রাসঙ্গিক কার্যগুলিতে ব্রেকপয়েন্ট সেট করতে চায় wants শেষ ব্যবহারকারীর নামকরণ এবং উত্স নামকরণ একমত না হলে উপযুক্ত ফাংশনগুলি খুঁজে পাওয়া শক্ত। আত্মবিশ্বাসী হওয়া এমনকি শক্ত বা অসম্ভব হতে পারে যে সম্পর্কিত ফাংশনগুলির একটি তালিকা এমনকি সম্পূর্ণ even (দেখুন 1.)

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

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

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

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

[1] একাধিক বিকাশকারী জড়িত থাকার কারণে।

Answer 5

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

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

এটি ভাবতে সহায়তা করতে পারে যে আপনি যদি এই পরিবর্তনটি করেন তবে আশা করি একই পিসটি অন্য গ্রাহকরা মূলত কোনও পণ্যতে রূপান্তরিত করে ব্যবহার করার পরে আপনাকে আর এটি করার দরকার পড়বে না।