আমার কর্মক্ষেত্রে প্রতিষ্ঠিত সম্মেলনগুলি অনুসরণ করতে কি আমার একটি খারাপ কোডিং শৈলী অনুসরণ করা উচিত?

Question

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

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

বিদ্যমান ফাংশনগুলির স্টাইল অনুসারে আমি কি সবকিছু বিশাল আকারের ফাংশনে রেখেছি বা আমার নিজের ফাংশনে অ্যালার্মগুলি আবদ্ধ করতে হবে?

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

সংক্ষেপে, আমি তুলনা করছি

showAlarms(){
    // tons of code
}

বিরুদ্ধে

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

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

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

Comments

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

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

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

— পরিবেশন করুন

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

— 22-29 এ পরিবেশন করুন

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

— দ্রুত_না

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

— জ্যাকবিবি

Answer 1

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

আমি ব্যক্তিগতভাবে এটিতে প্রথম স্থানটিতে রিয়েল-টাইম মিশন-সমালোচনামূলক কোডিংয়ের দিকে ছুটে এসেছি। আমি এর মতো কোড দেখেছি:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

আমি উজ্জ্বল এবং চকচকে ও সি সি ++ বিকাশকারী হয়েছি, আমি তত্ক্ষণাত তাদের আরএআইআই ব্যবহার না করে ম্যানুয়ালি লক এবং মল্টেক্সগুলি আনলক করে যে ঝুঁকির ঝুঁকির মুখোমুখি হয়েছিল তাদের তাৎক্ষণিকভাবে ডাকলাম । আমি জোর দিয়েছিলাম যে এটি আরও ভাল ছিল:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

অনেক সহজ এবং এটি নিরাপদ, তাই না ?! সংকলক যখন আপনার জন্য এটি করতে পারে তখন কেন সমস্ত নিয়ন্ত্রণ প্রবাহের পথে তাদের মুটেক্সগুলি আনলক করার জন্য বিকাশকারীদের মনে রাখা দরকার!

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

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

তাই চারপাশে জিজ্ঞাসা করুন। নিশ্চয়ই একজন প্রবীণ বিকাশকারী আছেন যে তারা কেন এইভাবে এটি করে তা বোঝার জন্য আপনার সাথে কাজ করতে পারে। অথবা, একজন সিনিয়র বিকাশকারী আছেন যিনি আপনাকে কোডের এই অংশে একটি রিফ্যাক্টরের খরচ এবং সুবিধা বুঝতে সহায়তা করতে পারেন। যেভাবেই হোক, চারপাশে জিজ্ঞাসা করুন!

Comments

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

— কেলভিন

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

— ডক ব্রাউন

@ ডকব্রাউন কেবলমাত্র তারা প্রযুক্তিগত না হওয়ার অর্থ এই নয় যে তারা কারণ নয়। বিকাশকারীদের মনে রাখা এটি গুরুত্বপূর্ণ যে তারা বৃহত মেশিনের একটি অংশ। (আমি যে পাঠটি পুনরায় শিখতে হয়েছিল তার সংখ্যা আমি গণনা করতে পারি না)

— কর্ট

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

— কর্ণ

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

— আম্মনকে

Answer 2

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

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

অ্যাডেনডাম, মন্তব্যের কারণে: "300 লাইন" এবং "ব্যবহার করা কঠিন" হ'ল আইএমএইচও খারাপ কোডের জন্য শক্তিশালী ইঙ্গিত। আমার অভিজ্ঞতার সাথে এটির খুব কম সম্ভাবনা রয়েছে কারণ কিছু "লুকানো প্রযুক্তিগত কারণ" কেন এই জাতীয় কোডটি আরও বেশি পঠনযোগ্য ফ্যাশনে প্রয়োগ করা যায় না, কর্ট অ্যামনের উত্তরটির তুলনার সাথে। যাইহোক, আমি কর্টের সাথে একমত আছি আপনার দলে দায়িত্বশীলদের সাথে এটি নিয়ে আলোচনা করা উচিত - কেন কোড বা এই "ধরণের ধরণের" পরিবর্তন করা যায় না তার अस्पष्ट কারণগুলি খুঁজে না, তবে জিনিসগুলি না ভেঙে কীভাবে কোডটি নিরাপদে রিফ্যাক্ট করা যায় তা সন্ধান করতে to ।

Comments

এমনকি উপযুক্ত প্রোগ্রামাররা কঠোর সময়সীমার মধ্যে থাকলে এই অপরাধ করে।

— বাগানের মাথা

@ গ্রেডেনহেড, আমি সময় বাঁচাতে 300-লাইনের ফাংশনটি রিফ্যাক্টরিং বুঝতে পারি না, তবে 300-লাইনের ফাংশনটি লেখার ফলে আপনার সময় সাশ্রয়ের কোনও সম্ভাব্য উপায় নেই।

— ডাংফ

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

— ডক ব্রাউন

@ ড্যাংএফ এটি সময় সাশ্রয় করে যখন আপনি কেবল ফাংশনে রিফ্যাক্টরের পরিবর্তে 5 টি লাইন যুক্ত করেন। এগুলি সাধারণত বৃদ্ধি পায় যখন প্রাথমিক ফাংশন দীর্ঘ হয় (30+ লাইন) এবং পরবর্তী প্রোগ্রামার মনে করেন "এটি আমার কোড নয়, আমি এটিটি ভাঙ্গতে না রিফ্যাক্টর করব না, কেবল এখানে এবং সেখানে কয়েকটি লাইন যুক্ত করব"।

— ডিউরিস

@ জুরিস, যেমনটা আমি বুঝতে পেরেছি, প্রশ্নটি একটি নতুন ফাংশন তৈরির বিষয়ে, বিদ্যমান বিদ্যমানগুলি রিফ্যাক্টর করার নয়। আপনি যদি একটি নতুন ফাংশন লিখছেন তবে আপনি এটি একটি একক দানব ক্রিয়ায় পরিণত করে সময় সাশ্রয় করবেন না।

— ডাংফ

Answer 3

না।

প্র্যাগমেটিক প্রোগ্রামার বইটিতে লেখক ব্রোকন উইন্ডো থিওরি সম্পর্কে কথা বলেছেন ।

এই তত্ত্ব রাষ্ট্র:

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

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

বইটিতে লেখক এই তত্ত্ব এবং কোডের মধ্যে একটি সমান্তরাল লিখেছেন। একবার আপনি এর মতো কোড পেয়ে গেলে আপনি থামিয়ে নিজেকে সেই একই প্রশ্নটি জিজ্ঞাসা করেন।

এবং উত্তর নেই.

আপনি একবারে এই ভাঙা উইন্ডোটি ছেড়ে দিলে - আমাদের ক্ষেত্রে, খারাপ কোড - এটি এমন প্রভাব তৈরি করবে যা প্রত্যেকে ভাঙা উইন্ডো পিছনে ফেলে দেবে।

এবং একদিন কোডটি চূর্ণবিচূর্ণ হবে।

ক্লিন কোড এবং ক্লিন কোডারের একটি অনুলিপি প্রত্যেককে দিন।

এবং আপনি যখন সাবজেক্টে থাকবেন তখন টিডিডির একটি অনুলিপিও ভাল।

Comments

কোডবেস যদি ভাঙা উইন্ডো ছাড়া কিছুই না গ্রিনহাউস হয়?

— অ্যালান শুটকো

@ অ্যালানশুতকো তাহলে আপনার জীবনবৃত্তান্ত বর্তমান কিনা তা নিশ্চিত করুন? এখনই আলাদা নিয়োগকর্তা সন্ধান করুন ।

— ডেভিড মন্টগোমেরি

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

— ডক ব্রাউন

বাহ, "ভাঙা উইন্ডো" তত্ত্বটি মনে হয় কী নির্বিচারে সাদৃশ্য।

— সামথারে

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

— কোথাও কোথাও

Answer 4

হ্যাঁ, এটি জন্য যান। স্ট্রাকচার! = স্টাইল

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

সাবধান হও

শুধু নিশ্চিত হয়ে উঠুন যে আপনি অন্য কোনও ক্ষেত্রে নেতিবাচক পরিণতি ঘটাচ্ছেন না যা আপনার কাছে ঘটেনি। উদাহরণ স্বরূপ,

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

ভদ্র হও

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

Comments

"এমন একটি প্রবাহকে আটকে রাখার চেষ্টা করুন যা পুরানো শৈলীতে অভ্যস্ত লোকদের বোঝায়।" - সুতরাং, আপনার পরামর্শটি কি একইভাবে প্রোগ্রাম করার জন্য অযোগ্য ক্লাউন আগে যা করেছিল? 300 লাইন ফাংশন যুক্ত করা সহজ করে তুলছে না।

— BЈовић

অনুরূপ প্রবাহকে আটকে রাখতে আমি বলিনি। আমি বললাম এমন একটি প্রবাহকে আটকে দিন যা তারা বুঝতে পারবে।

— জন উ

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

— পিটার এ স্নাইডার

Answer 5

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

Comments

" কোনও কারণ নেই, এটি কেবল আমাদের নীতি। "

Answer 6

উত্তরটি কোড পর্যালোচনায় রয়েছে।

আসল প্রশ্নটি হল আপনি যদি ভাল ফ্যাক্টর কোডটি চালু করেন তবে আপনি কি কেবলমাত্র এটির সাথে কাজ করতে ইচ্ছুক হতে চলেছেন?

আমি, এখানকার বেশিরভাগ লোকের মতোই বিশ্বাস করি যে 300 লাইন ফাংশন একটি ঘৃণা। যাইহোক, উইন্ডেক্সকে ল্যান্ডফিলে নিয়ে যাওয়া খুব ভাল কাজ করে না। সমস্যাটি কোড নয়, এটি কোডার্স।

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

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

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

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

Comments

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

— ব্র্যান্ডন

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

— ব্র্যান্ডন

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

— জেডিগোগস

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

— candied_orange

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

— ব্র্যান্ডন

Answer 7

কখনও কখনও আপনাকে প্রবাহের সাথে যেতে হবে।

যেমনটি আপনি বলেছেন যে আপনাকে একটি বিদ্যমান ওয়ার্কিং কোডবেসে কোনও ফাংশন বাস্তবায়নের দায়িত্ব দেওয়া হয়েছে।

গণ্ডগোল নির্বিশেষে এবং আমি বুঝতে পারি এটি পরিষ্কার করার জন্য এটি লোভনীয়। তবে ব্যবসায়িক বিশ্বে আপনার কাছে সবসময় রিফ্যাক্টর কোড করার সুযোগ থাকে না।

আমি বলব যে আপনাকে যা করতে বলা হয়েছে ঠিক তাই করুন এবং এগিয়ে যান।

আপনি যদি মনে করেন যে এটি টিমের সাথে আলোচনার জন্য আপনার সামনে আনার প্রয়োজনের চেয়ে এটি রিফ্যাক্টরিং বা পুনর্লিখনের পক্ষে মূল্যবান।

Comments

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

— ব্র্যান্ডন

ওপিকে কয়েকশ লাইন কোডের সংশোধন না করে একটি ফাংশন লিখতে বলা হয়েছে

— মেডা

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

— রোটনিগ

"যদি এটি না ভেঙে যায় তবে এটি ঠিক করবেন না।" আমার একটি 20 বছরের পুরনো গাড়ি আছে যা একটি সামান্য তেল ফাঁস করে দেয়। অর্থ ব্যয় মূল্যবান? না? নির্ভরযোগ্য? হ্যাঁ.

Answer 8

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

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

একবার আপনি এই ঘাঁটিগুলি coveredেকে ফেললে তাদের সঠিক মনে কেউ আপনাকে চ্যালেঞ্জ জানাতে পারে না। বোনাস আইটেম হিসাবে, কিছু মাইক্রো-বেঞ্চমার্কিং করুন এবং এটি আপনার ক্ষেত্রে সত্যই যুক্ত হবে।

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

Comments

আমি বর্তমান কোডটি রিফ্যাক্টর করছি না, আমি কেবল একটি নতুন ফাংশন লিখছি, নিশ্চিত নই যে আমার কেবল 'কনভেনশন' অনুসরণ করা উচিত এবং এটি 300+ লাইন মনস্ট্রোসিটিতে কোড করা উচিত বা এটিকে লজিকাল খণ্ডগুলিতে ভেঙে ফেলা উচিত যেমন আমি সাধারণত করি তবে কোড বেস এই অংশে করা হয়নি।

— জাস্টিন

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

— স্কিপি

Answer 9

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

সুতরাং, বর্তমান কোড বেসটি আপনার পছন্দ অনুযায়ী আলাদা কোডিং শৈলীর ব্যবহার বলে মনে হচ্ছে। তোমার কি করা উচিত? প্রথমে আপনাকে খুঁজে বের করতে হবে:

1. এটি কি আপনার বর্তমান দল দ্বারা ইচ্ছাকৃতভাবে ডিজাইনের সিদ্ধান্তকে সমর্থন করে?
2. তারা কি চান যে আপনি এই স্টাইলটি অনুসরণ করুন?

এটির একটি মাত্র উপায় রয়েছে is জিজ্ঞাসা করুন ।

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

Comments

আমি পুঙ্খানুপুঙ্খভাবে সম্মত হই এবং যোগ করি, "অন্যেরা যা করেছে তার অনুসরণ না করে আপনি কি বরখাস্ত হতে পারেন বা অন্যথায় সমস্যায় পড়েছেন?" তাহলে উত্তর হ্যাঁ! প্রতিটি খারাপ জিনিস অনুসরণ করে সংস্থাটির আপনার এটি করা এবং এটি মোকাবেলা করা প্রয়োজন।

— রব

Answer 10

"স্টাইল" এর বিভিন্ন স্তর রয়েছে।

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

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

তারপরে প্রকল্পটির দ্বারা ব্যবহৃত লাইব্রেরি এবং ফ্রেমওয়ার্ক রয়েছে।

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

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

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