কোডিং মানগুলিতে প্রকল্পের নেতৃত্বের সাথে মতবিরোধ [বন্ধ]


16

তাই আমি গত 1 বছর ধরে আমার প্রকল্পের নেতৃত্বের সাথে একটি নতুন প্রকল্পে কাজ করছি।

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

এখন যেহেতু আমি উভয় সাব-প্রকল্পের নেতৃত্ব বিকাশকারী (দলটি বাড়তে চলেছে; সে এখনও আমার থেকে উপরে), এই বিষয়গুলি আমাকে বিরক্ত করেছে এবং আমি তাদের যত্ন নিতে চেয়েছিলাম, কিন্তু প্রত্যাখ্যান করা হয়েছিল:

  1. কোনও কোঁকড়া ধনুর্বন্ধনী, বড় আকারের ফাংশন, মিশ্র উদ্ধৃতি ব্যবহার (ডাবল এবং একক ডাব্লু / লুকানো যুক্তি), === না ব্যবহার করে বিশাল ফাংশন সহ বিশাল ক্লাস। নীচের লাইন, আরও ভাল হতে পারে।
  2. বিজ্ঞপ্তি / সতর্কতা বন্ধ করার জন্য পিএইচপি-র বিকল্পের উপর নির্ভর করুন। কোডটি ভেরিয়েবল এবং অ্যারে কীগুলির অচিহ্নযুক্ত ব্যবহারগুলি পূর্ণ। চলকগুলি ifs এর ভিতরে সংজ্ঞায়িত হয়।

উপরোক্ত 2 ইস্যুতে যুক্তি:

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

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

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

আমি কি ভুল করছি? আমি কি আমার ব্যক্তিগত পছন্দ আরোপ করব?


11
@ কোড কোডিং মানক! = কোড পর্যালোচনা
কোডসইনচোস

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

4
কোঁকড়া ধনুর্বন্ধনী যখন আপনি একটি if, foreach এবং একে অপরের অভ্যন্তরে অন্য দেখেন :) বাছাই করা হয় না। দৃ all়ভাবে বাঁধা প্রকল্পগুলিতে এটি ধারাবাহিক কোড দেখার বিষয়।
জর্জ কাগান

3
@timenomad আমি যা বলতে চাইছি তা হ'ল প্রথমে সবচেয়ে সহজ, অন্তত বিতর্কিত নির্দেশিকা প্রবর্তন করে। "4 স্পেস ইনডেন্ট ব্যবহার করুন; ইনডেন্টেশনের জন্য ট্যাব অক্ষর ব্যবহার করবেন না" এই জাতীয় জিনিস। বা "
ইউএনএফএস

8
আপনি কি কোডিং মানগুলির সুবিধাগুলি নিয়ে গবেষণা করেছেন এবং কেবল আপনার মতামতই উপস্থাপন করেছেন না, তবে অন্যান্য উত্স থেকে প্রাপ্ত তথ্য (বিশেষত যাঁরা আপনি সম্মানজনক বলে বিবেচনা করবেন)? আপনি কি দলের বাকী সদস্যদের সাথে তাদের চিন্তাভাবনা পেতে কথা বলেছেন - কোডিং মানের অভাবে তাদের কি সমস্যা আছে?
থমাস Owens

উত্তর:


15

আপনারা কেন আরও ভাল (এবং তাঁর ব্যবহারে কী কী বড় সমস্যা আসতে পারে) এর জন্য যদি আপনি দৃ strong় মামলা করতে পারেন তবে আপনি ব্যক্তিগত পছন্দ আরোপ করছেন না, বরং সফলতার জন্য একটি প্রকল্প স্থাপনের চেষ্টা করছেন।

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

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

উপরে আমার মন্তব্য প্রতি:

তিনি যদি প্রকল্পের নেতৃত্ব হন, তবে বোঝা যাচ্ছে যে এটি মূলত তাঁর ডাক।

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

কেন আরও ভাল মানের হওয়া উচিত তার জন্য আপনি যদি দৃ strong় কেস তৈরি করেন তবে তার উপরে উঠে যাওয়া কেবলমাত্র কাজ করবে ।


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

7
@timenomad: তারপরে আপনার সিভি তীক্ষ্ণ করার সময় এসেছে।
মনিকার সাথে লাইটনেস রেস

1
jd13, সেখানে নয় "ডিসেন্ট উপরের ব্যবস্থাপনা"। অস্তিত্ব নেই শুধু বিন্দু চুল
রবার্ট ব্রিস্টো-জনসন

13

মূলত:

  • আপনি তার কোডিং শৈলী পছন্দ করেন না । এটা আপনার অধিকার।
  • তিনি এটিকে ঠিক মতো দেখতে পেয়েছেন এবং দিন / সপ্তাহ / আরও বেশি সময় ব্যয় করেছেন কেবল শৈলীর সামঞ্জস্য করা সময় নষ্ট করা । এটাই তার অধিকার।

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

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


এটি প্রায়শই আপনি কীভাবে জিজ্ঞাসা করেন তার উপরও নির্ভর করে । উদাহরণ:

তুমি কি চাও:

কোড প্রিটিয়ের তৈরি

কি বলব না:

আপনার কোডটি সেভাবেই চুষছে

কি বলতে:

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


তুমি কি চাও:

আর কোনও চেক করা সতর্কতা নেই

কি বলব না:

আপনার কোডটি সেভাবেই চুষছে

কি বলতে:

আমি এই এবং সেই সতর্কতা থেকে মুক্তি পাওয়ার দ্রুত উপায় জানি। তারপরে, এগুলি পুনরায় সক্ষম করে, আমরা যদি ভবিষ্যতে কিছু ভেঙে ফেলা যায় তবে আমরা আরও দ্রুত সনাক্ত করতে পারি।


এবং সর্বশেষে:

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


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


সাইড নোট

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


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

2
@ রাইময়েড সম্পূর্ণরূপে সম্মত হন। তিনি জোর দিয়েছিলেন যে পিএইচপি-র ক্ষমাশীল প্রকৃতিটি আলিঙ্গন করা এবং তার পুরোপুরি অভ্যস্ত হতে হবে! তবে এটি সমস্ত বাগ তৈরি করা।
জর্জ কাগান

2
(আ্যাক। এটি দেখা যাচ্ছে যে,
পিএইচপি'র সমস্যাগুলি

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

13

এটি সম্ভবত বিতর্কিত হতে চলেছে তবে ...

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

কখনও। কখনো। করে. এই. কখনোই না। যতবার আপনি এটি করেন, এটি আমাদের সকলকে এক দশক পিছনে ফেলে দেয়। এটি এইভাবে খেলবে:

  • সিনিয়র ম্যানেজার 1: "আমাদের এই সমস্যাটি ব্লাহ, ব্লা, ব্লা, কোডিং মান এবং সময় নষ্ট সম্পর্কে কিছু করার জন্য বলা হয়েছে।"

  • সিনিয়র ম্যানেজার 2: "এবং তারা আমাদের তাদের অহংকার টার্ফ যুদ্ধগুলি সমাধান করতে বলছে কারণ?"

  • সিনিয়র ম্যানেজার 3: "কারণ তারা এমন বাচ্চা শিশু যারা যোগাযোগ করতে পারে না এবং যত্ন করে না / বুঝতে পারে না যে ব্যবসায়ের মূল্য কী? *"

  • সিনিয়র ম্যানেজার 2: "এটি অবশ্যই হবে Who গল্ফের জন্য কে প্রস্তুত?"

তারপরে আপনি এবং আপনার বসের পারফরম্যান্স পর্যালোচনা সময় আসে:

"[আপনার বসের সিনিয়র ম্যানেজার]: আমি দুঃখিত তবে কিছুটা উদ্বেগ রয়েছে যে আপনি নিজের সরাসরি রিপোর্ট পরিচালনা করতে পারবেন না এবং আপনি সেরা অনুশীলনগুলি অনুসরণ করছেন না (যদিও কিছু মম্বু জাম্বো টাইপ করা ছাড়া আপনি কী করেন তা আমার কোনও ধারণা নেই) যা সফ্টওয়্যারটিকে কার্যক্ষম করে তোলে) "

"[আপনার কাছে সিনিয়র ম্যানেজার]: আমি দুঃখিত তবে কিছুটা উদ্বেগ রয়েছে যে আপনি আপনার সমবয়সীদের সাথে ভাল সম্পর্ক করেন না এবং আপনার তাত্ক্ষণিক সুপারভাইজারের নির্দেশনা অনুসরণ করতে সমস্যা হয়" "

এবং এ কারণেই আমরা আমাদের তৈরি করা মানটির তুলনায় বেশিরভাগ স্বল্প বেতনে আছি **

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


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

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

*** হ্যাঁ আমি বুঝতে পারি যে কারিগরি debtণ ব্যবসায় ডুবে যাওয়ার পর্যায়ে পৌঁছে যেতে পারে। আমি কেবল ভাবি না যে কোঁকড়া ধনুর্বন্ধনী আপনাকে রক্ষা করবে (যা বলা হচ্ছে, আমি কখনও ধনুর্বন্ধনী বাদ দিই না এবং অন্যকে নাও দৃ strongly়ভাবে পছন্দ করি)।


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

আমি একটি অস্বীকৃতি যোগ করতে হবে :) ধন্যবাদ, আপনি একই!
জর্জ কাগান

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

5

আইএমএইচও, আপনি একজন 'এটি কাজ করছে' বিকাশকারীদের মুখোমুখি হচ্ছেন, তাদের পরবর্তী লোকের যত্ন নেওয়ার মতো নয়। তার যুক্তি খালি মূল্যহীন।

আপনি তার কোড সম্পর্কে যা কিছু বলেন তা কেবল তার পক্ষে কাঁচা আলস্য। একই কোডিং স্ট্যান্ডার্ড অনুসরণকারী প্রকল্পগুলি কঠোরতা সম্পর্কে। আপনি রোবট নন; আপনি প্রকৌশলী; আপনি কঠোর হতে অনুমিত।

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

তবে আমি সম্ভবত আপনাকে উত্তর দেব কিছু হ'ল সুর:

এটি কাজ করছে, পরিবর্তনের কোনও অর্থ নেই

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


1
এটি একটি সফল প্রকল্পের জন্য সক্রিয়ভাবে সেট আপ করার চেষ্টা করে খুব ভাল কাজ করে না। আসলে, "ঠিক আছে, আমি খুব অলস, তাই এটিকে স্ক্রু করে বলি, প্রকল্পটি জাহান্নামে যেতে দাও" বলার চেয়ে এটি বেশি ভাল নয়।
jleach

1
এটি একটি ন্যায্য বিষয়। আমি এটি পড়েছি কারণ আপনি চিহ্নিত করার পরামর্শ দিচ্ছিলেন যে দোষটি তার কোডিং প্যাটার্নের কারণে হয়েছিল।
ম্যাথু হোয়াইট

1
@ ম্যাথুউইটেড অন্য কেউ যাতে বুঝতে না পারে সেজন্য আমি সম্পাদনা করেছি।
ওয়ালফ্র্যাট

3

আপনি যখন কোনও প্রকল্পে কাজ করেন, আপনাকে অগ্রাধিকার নির্ধারণ করতে হবে।

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

এবং নতুন কোডিং মান অনুসারে বিদ্যমান কোড পরিবর্তন করা অগ্রাধিকার তালিকার সত্যই কম।

পুনশ্চ. "মাইক্রো-অপ্টিমাইজেশন" বনাম "সুপার-ফাস্ট কম্পিউটার": সম্পূর্ণ ভুল যুক্তি। মাইক্রো-অপ্টিমাইজেশনের বিরুদ্ধে যুক্তিটি কম্পিউটারগুলি দ্রুত নয় এমন যুক্তিটি হ'ল মাইক্রো-অপটিমাইজেশনগুলিতে সময় নষ্ট করা মানে আপনার আসল সঞ্চয় করার পিছনে সময় নেই ।

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


1
... বাহ, আমি আশ্চর্য হয়েছি কেউ আসলে এটিকে কমিয়ে দিয়েছে। আমি দশবার ভোট দিয়েছি।
ডাগলিনিগুলি

1
@timenomad "আমরা চক্র নষ্ট করতে পারি"! = "আমাদের চক্র নষ্ট করা উচিত"। আমি মনে করি মাইক্রো অপ্টিমাইজেশনের বড় সমস্যাটি হ'ল এটি বেশিরভাগ স্ক্রিপ্টিং ভাষায় সম্পূর্ণ হারানো কারণ। সর্বোপরি এটি বিমূর্ততার কারণে কিছুই করার ঝোঁক নেই, সবচেয়ে খারাপ এটি ওভারহেড যুক্ত করতে পারে।

1
@ ইটিমনোমাদ যদি আপনাকে কেবল একদিন নিয়ে যায় তবে কোনও আলোচনা হওয়া উচিত নয়, যেহেতু আপনি এখন উভয় প্রকল্পের নেতৃত্ব বিকাশকারী এবং যেহেতু এটি কোনও বড় কৌশলগত সিদ্ধান্ত নয় এটি কেবল আপনার পছন্দ হবে।
jjmontes

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

1
উত্সাহ দেওয়া কারণ আমি দেখেছি কোডিং মান যুদ্ধগুলি আন্তঃব্যক্তিক সম্পর্ক এবং দলের মনোবলকে বিশাল ক্ষতি করে।
ডেভিড 25272

2

পিএইচপি আমাদের পেশার সবচেয়ে অভিজাত দল নয়। আসলে আপনি তার সম্ভবত হার্ড-উইনড সফ্টওয়্যার সিস্টেমের সমালোচনা করছেন। আপনার পেশাদার মানটি তার এক হিসাবে উচ্চতর।

তারপরে যদি আপনার দায়িত্বের অধীনে কোডটি উন্নত করার কোনও উপায় নেই, তবে কেবলমাত্র একটি সমাধান রয়েছে: এগিয়ে যান

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

আপনি এত সুন্দর কাজ নাও পেতে পারেন, তবে আপনি আরও পেশাগতভাবে আসবেন। সুতরাং ধৈর্য ধরুন এবং কিছু স্ব-অধ্যয়ন করুন। নিরাপদ অর্থ. তারপরে আপনার প্রকল্পগুলিতে কিছুটা ছাড়ের জন্য জিজ্ঞাসা করুন বা কিছু কাজের অফার নিন।


2
পিএইচপি এর নমনীয় স্বভাবটি কখনও কখনও তার সর্বোত্তম বৈশিষ্ট্যের জন্য ভুল হয় (শয়তান উদ্দেশ্যে)
জর্জ কাগান

2

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

কোড বেসের স্টাইল ঠিক করা এখনই আপনার সময়ের সেরা ব্যবহার?

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

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

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

এইভাবে, প্রতিটি পরিবর্তন:

  1. প্রযুক্তিগত নিখুঁততা প্রেরণার পাশাপাশি একটি ব্যবসায়িক অনুপ্রেরণাও রয়েছে
  2. একটি বৃহত সময়ের বিনিয়োগ হিসাবে দেখা হবে না (কারণ এটি না!)
  3. যথাযথভাবে ভাল স্টাইলিস্টিক অভ্যাস স্থাপন করবে কারণ আপনি এবং আপনার দল এটি সময়ের সাথে এটি করছে
  4. কোড বেসে একটি বৃহত ঝুঁকি উপস্থাপন করবে না কারণ আপনি একবারে খুব বেশি পরিবর্তন করছেন না

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


আমি বিশেষত পিএইচপি সম্পর্কে জানি না, তবে অনেক ক্ষেত্রে স্বয়ংক্রিয় সরঞ্জামগুলি এই ধরণের জিনিসগুলি কয়েক মিনিটের মধ্যে পরিচালনা করতে পারে এবং তারপরে প্রত্যেকে নতুন স্টাইলটি এগিয়ে যেতে ব্যবহার করতে পারে।
কেসি

1

আপনার সীসা সম্পর্কে এই প্রশ্ন জিজ্ঞাসা করুন।

  • তারা কি একা কাজ করতে অভ্যস্ত নাকি খুব ছোট দলের সাথে?
  • তারা কি বেশিরভাগই এই একটি দোকানে কোড করে?
  • তারা সিদ্ধান্ত নিতে অভ্যস্ত?
  • তারা কি "কেবল এটি সম্পন্ন করা" করতে অভ্যস্ত?
  • তারা কি বেশিরভাগ কোড লিখেছিল?

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

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

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

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

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

এই এমন কেউ যিনি কখনও সফ্টওয়্যার ইঞ্জিনিয়ারিং এবং সফ্টওয়্যার আর্কিটেকচার সঠিকভাবে শিখেন নি। তারা যা কিছু কাজ করে তা একত্রে বাছাই করে।

আপনার লোকজনের সমস্যা আছে, প্রযুক্তিগত সমস্যা নেই।

আপনাকে আপনার সীসা পুনরায় প্রশিক্ষণ করতে হবে, বা আপনাকে প্রস্থান করতে হবে।


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


পুনরায় প্রশিক্ষণ করতে আপনাকে ...

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

তাঁর স্টাইলকে গুরুত্ব সহকারে নিন এবং তাঁর মাথার ভিতরে .ুকুন এটি সম্পর্কে তাকে জিজ্ঞাসা করুন। কেন সে তার মতো করে কাজ করে? পড়লে সে কী দেখবে? এটি কীভাবে তার সরঞ্জামগুলির সাথে যোগাযোগ করে? কীভাবে সে কোডের মধ্য দিয়ে চলে? এই সমস্ত কিছু জানার ফলে আপনি তাঁর আপত্তিগুলি বুঝতে এবং তার সমাধান করতে পারবেন।

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

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

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

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

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

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


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


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

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

1

আমি কি ভুল করছি?

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

তারপরে কোডিং শৈলীর উন্নতির পরামর্শ দেওয়া আপনার পক্ষে ভুল নয়।

নীচের লাইন, কোড নয় আমি কাজ করতে চাই

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

আমি কি আমার ব্যক্তিগত পছন্দ আরোপ করব?

না তিনি প্রকল্পের নেতৃত্ব এবং আপনি নন। এটি তার ডাক, যদিও এই ক্ষেত্রে তিনি "উপরের দিকে ডেলিগ্রেটিড"।

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

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

আপনি ফাইলগুলি সম্পাদনা করে এমন লোকদের যুক্তিযুক্তভাবে (আমার মনে হয়) ফাইলটি ইতিমধ্যে লিখিত শৈলীতে এটি করতে বলতে পারেন is এটি আপনাকে আপনার লিখিত ফাইলগুলিতে মান বজায় রাখতে সহায়তা করে। দুর্ভাগ্যক্রমে এর ফ্লিপ দিকটি হ'ল আপনাকে তাঁর স্টাইলের অনুরূপ কিছু লিখেছেন এমন ফাইলগুলি সম্পাদনা করতে হবে।

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


1

[আমার পরিচালক বলেছেন যে তিনি] লোকদের উপর কোডিং শৈলীর প্রয়োগ করতে পছন্দ করেন না [কারণ] আমরা রোবট নই।

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

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

এমনকি কোনও খারাপ স্টাইল কোনও স্টাইলের চেয়ে ভাল is

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