বড় পরিবর্তনগুলি / ইন্টার্ন হিসাবে পুনঃলিখনের প্রস্তাব দেওয়া [বন্ধ]

Question

প্রসঙ্গ:

• এটি একটি অভ্যন্তরীণ প্রকল্প (যা আমি মনে করি না যে প্রচুর লোক ব্যবহার করে)
• এটা পুরানো
• আমরা এটি আপডেট করছি

বিষয়:

1. এটি এমভিসি কাঠামোটি আপত্তি করে (মডেলগুলির ব্যবহার নয়, দর্শনে ব্যবসায়িক যুক্তি ইত্যাদি)
2. আমাদের যা করতে বলা হচ্ছে তা ছোট, তবে কম সংযুক্তির কারণে আমাদের দুটি বিকল্প রয়েছে:
   1. জিনিস বোচ চালিয়ে যান
   2. কোডের বড় অংশগুলিকে চারপাশে সরান বা জিনিসটি আবার লিখুন

সমাধান (আমি দেখতে):

1. এটির সাথে কাজ চালিয়ে যাওয়া, শীঘ্রই সম্পন্ন করার পক্ষে সর্বোত্তম অনুশীলনগুলি উপেক্ষা করুন এবং রিফ্যাক্টরিং / পুনর্লিখনের মাধ্যমে নতুন বাগগুলি প্রবর্তন না করার জন্য
2. refactor / লেখা

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

Comments

এটি কেন যেমন হয় তেমনি গবেষণা করার বিষয়টি বিবেচনা করুন। এমন কিছু ভাল কারণ থাকতে পারে যা আপনি এখনও জানতে পারেন নি।

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

— জোনো

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

— জোয়েল ইথারটন

আপনার রিফেক্টর এবং পুনর্লিখন কেন তা একইরকম লেখা রয়েছে তা আমি জানি না। তারা না.

— ক্যাফগিকে

আমি জানি যে তারা নেই, তবে আপনি যদি অ্যাপ্লিকেশনটি দেখে থাকেন তবে আপনি বুঝতে পারেন যে তারা এই প্রসঙ্গে কীভাবে মিল রয়েছে

— 7983879342

Answer 1

ঠিক আছে এখানে যায়।

আপনি মনে করেন অ্যাপ্লিকেশনটি খারাপভাবে কাঠামোগত এবং খারাপভাবে লেখা হয়েছে।

গ্রাহক মনে করেন এটি কাজ করে।

আপনি এর "অভ্যন্তরীণ সৌন্দর্য" উন্নত করা ছাড়া অন্য কোনও কারণে এটি পুনর্লিখন করতে চান।

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

খারাপভাবে লেখা বাজে কাঠামোগত কোডের মূল আপত্তিটি এটি বোঝা শক্ত hard

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

সুতরাং আপনার গ্রাহক এখন একটি অ্যাপ্লিকেশন পেতে প্রচুর অর্থ ব্যয় করেছেন যা মূল অ্যাপ্লিকেশনটির চেয়ে মারাত্মক খারাপ। আপনি জনপ্রিয় হতে চলেছেন না!

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

সুতরাং আমার পরামর্শটি হ'ল পুরাতন কোড বেসটি চলমান রাখা, এবং চুপ করে থাকা। গ্রাহক কেবল এমন একটি সিস্টেম চায় যা তারা কোডটিকে কুৎসিত মনে করে তবে তারা সত্যই যত্ন করে না।

Comments

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

— 7983879342

বিষয়টিতে এত কঠোর শোনার জন্য দুঃখিত, তবে, রিফ্যাক্টরিং সত্যিই কঠিন হতে পারে এবং যদি না আপনি আপনার ব্যবহারকারীদের জন্য কিছু স্পষ্টত উপকার না দেখান তবে এটি বেশ কৃতজ্ঞ।

— জেমস অ্যান্ডারসন

Answer 2

আপনার পরিবর্তন প্রস্তাব। প্রত্যেকের ব্যবসায়ের ক্ষেত্রে পরিষ্কার থাকুন : আপনার প্রস্তাবিত পরিবর্তন কেন পুরো ব্যবস্থাটিকে সহায়তা করবে? যদি তা না হয় তবে পিছনের দিকে ধাক্কা expect কিছু নষ্ট হয়নি এমন ফিক্সিংয়ের জন্য কেন অর্থ ব্যয় করবেন? এবং এই ধরনের সিস্টেম আরো প্রসার্য উপার্জন যেমন কারণ উদ্বেগের বিচ্ছিন্নতার may বৈধ পারে (আপনি কার সাথে কথা বলছেন তার উপর নির্ভর করে) তবে 99% সময় কেবলমাত্র "এটি সঠিকভাবে প্রয়োগ করা হয়নি" বললে আপনি কোথাও পাবেন না। নিশ্চিত হয়ে নিন যে আপনি প্রকল্পটিতে মূল্য যুক্ত করছেন এবং কেবলমাত্র কাজের প্রস্তাব করবেন না (এমনকি এটি কোড সাফ করে না কেন)।

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

Comments

+1, বিশেষত "পেশাদার জগতে, কারণ যে কোনও কিছু ভুল প্রয়োগ করা হয়েছে তার অর্থ এই নয় যে এটি ভেঙে গেছে"

— স্টুপার ইউসার

+1 এবং বিপরীতভাবে ... ঠিক কিছু বাস্তবায়িত হয়ে যায় এর অর্থ এটি কার্যকর হয় না।

— জোয়েল ইথারটন

Answer 3

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

আপনি যদি মনে করেন এটি সত্য নয় তবে আপনার এখানে যতটা মামলা হয়েছে তার চেয়ে বেশি কেস তৈরি করতে হবে।

অ্যাপ্লিকেশনটির উন্নতি করার ক্ষেত্রে, আপনার আপডেটগুলির সময় প্রাকৃতিকভাবে ঘটে এমন কিছুটা রিফ্যাক্টরিংয়ের জন্য আপনার কিছু সুযোগ থাকতে পারে।

Comments

স্বল্প ব্যবহারের অভ্যন্তরীণ অ্যাপ্লিকেশনটির একটি নতুন পুনরায় লেখায় স্বল্প সুবিধার জন্য +1। আপনার সময়টি অন্য কোথাও বেশি লাভজনকভাবে ব্যবহার করা যেতে পারে (যদি না তারা আপনার জন্য প্রশিক্ষণ অনুশীলন হিসাবে এটি ব্যবহার করতে চান)

— ɐɪ

Answer 4

তুমি ইন্টার্ন। সম্ভবতঃ আপনি একেবারে নতুন। তারা সম্ভবত আপনাকে একজন নির্বোধের জন্য সন্দেহ করে।

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

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

অবশেষে , আপনি আপনার দক্ষতা এবং জ্ঞান প্রদর্শিত হিসাবে, আপনি একটি বা দুটি পরামর্শ বন্ধ করতে সক্ষম হতে পারে।

Answer 5

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

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

মনে রাখবেন যে এই অ্যাপ্লিকেশনটি রিফ্যাক্টর করার উত্তর সম্ভবত সম্ভবত বেশি হবে না; আমি কোনও ইন্টার্ন কখনই অভ্যন্তরীণ অ্যাপ্লিকেশনটির পুনর্লিখন গ্রহণ করতে চাইব না (যখন আপনার ইন্টার্নশিপটি সম্পন্ন হবে এবং পুনর্লিখনটি কেবল অর্ধ-সমাপ্ত হবে তখন কী হবে?) প্লাস, অভ্যন্তরীণ অ্যাপ্লিকেশনটির আশেপাশে হাঁটাহাঁটি করার চেয়ে সম্ভবত আরও গুরুত্বপূর্ণ জিনিস আপনি কাজ করতে পারেন ।

তবে আপনার সহকর্মীদের জিজ্ঞাসা করা কখনই ব্যাথা করে না এবং যদি আপনি তা করেন তবে আপনি কিছু শিখবেন। এবং এটি, 7983879342, হ'ল ইন্টার্নশিপ সম্পর্কে।

Answer 6

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

আপনি কিছুটা নকব্যাক পেলেও, এটি আমাদের শেখার এবং বড় হওয়ার উপায় though

Answer 7

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

তবে এর অর্থ এই নয় যে আপনার বয় স্কাউট বিধি ভুলে যাওয়া উচিত :

আপনি যতটা খুঁজে পেয়েছেন তার চেয়ে ক্যাম্পগ্রাউন্ড ক্লিনারটি সর্বদা ছেড়ে যান।

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

Answer 8

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

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

Answer 9

বেশিরভাগ পরিবর্তনগুলি সাধারণ নিয়ম হিসাবে ক্রমবর্ধমানভাবে ঘটে।

কিছু বিষয় মনে রাখতে হবে;

• আবেদনের ইতিহাস কী?
• আজ কেন কুরুচিপূর্ণ?
• স্থাপত্য পরিবর্তনের সুবিধা কী?

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

Answer 10

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

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