প্রকল্পটি প্রায় সম্পন্ন হয়েছে, তবে পদ্ধতিগত স্প্যাগেটি কোড। আমি কি আবার লিখি বা কেবল চালানোর চেষ্টা চালিয়ে যাচ্ছি? [বন্ধ]


242

আমি একটি শিক্ষানবিশ ওয়েব বিকাশকারী (অভিজ্ঞতার এক বছর)।

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

ককি যখন আমি তখন ফিরে এসেছিলাম, কম্পিউটার সায়েন্সে ডিপ্লোমা নিয়ে, আমি যে কোনও কিছু তৈরি করতে পারব এই ভেবে অফারটি মেনে নিয়েছিলাম।

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

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

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

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

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

আমার এই অবিরাম চিন্তাভাবনা আছে যে আমাকে পুরো প্রকল্পটি আবার লিখতে হবে। তবে, আমি এটি করতে পারি না ... তারা জিজ্ঞাসা করে যে এটি কখন শেষ হবে।

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

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

আমি কি আবার লিখি, বা কেবল চালানোর চেষ্টা চালিয়ে যাচ্ছি, বা অন্য কোনও বিকল্প যা আমি মিস করেছি?


142
আপনি যেভাবে শুরু করেছেন এটি শেষ করুন এবং পরবর্তী সংস্করণে প্রযুক্তিগত debtণটি পরিষ্কার করুন (যদি এটি থাকে)। আপনার বস পার্থক্য জানতে পারবেন না। আপনি এটি ভাল পরীক্ষা করে নিন।
রবার্ট হার্ভে

45
"তবে peopleশ্বর কেবল জানেন যে লোকেরা যখন এটি ব্যবহার শুরু করে তখনই কি ঘটতে পারে" ... এটি সফ্টওয়্যার বিকাশের মজাদার। এর সাথে
অভ্যস্ত

144
এটি আপনার নির্মিত প্রতিটি একক সিস্টেম হবে।
খারিজ করুন

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

14
আমার বাবা আমাকে বলতেন "মাঝে মাঝে আপনাকে ইঞ্জিনিয়ারদের গুলি করতে হবে এবং জাহাজ চালাতে হবে।"
কর্সিকা

উত্তর:


253

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

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

দ্বিতীয়ত, আপনি অনেক মূল্যবান জিনিস শিখেছেন, সুতরাং এটি আপনাকে যা শিখিয়েছে তার জন্য আপনার অভিজ্ঞতার প্রশংসা করা উচিত :

  1. পরিকল্পনা বা আর্কিটেকচার ছাড়াই স্লিং কোড হ'ল বিপর্যয়ের একটি রেসিপি
  2. কোড লেখার চেয়ে প্রোগ্রামিংয়ের আরও অনেক কিছুই রয়েছে
  3. অ-প্রযুক্তিগত ব্যবসায়ের মালিকরা প্রায়শই প্রযুক্তিগত সিদ্ধান্তের প্রভাব বুঝতে পারেন না (যেমন কাকে ভাড়া দেবেন) এবং বিকাশকারীদের তাদের বিষয়গুলি ব্যাখ্যা করার বিষয়।
  4. বেশিরভাগ সমস্যাগুলি ইতিমধ্যে বিদ্যমান ফ্রেমওয়ার্কগুলিতে আপনি যেগুলি সমাধান করবেন তার চেয়ে আরও ভাল সমাধান করা হয়েছে। এটি বিদ্যমান ফ্রেমওয়ার্কগুলি কখন এবং কখন সেগুলি ব্যবহার করে তা জানতে অর্থ প্রদান করে।
  5. অল্প গাইডেন্স সহ বড় প্রকল্পে নির্ধারিত স্কুল থেকে সতেজ হওয়া লোকেরা একটি বাটি স্প্যাগেটি কোড তৈরি করে। এই স্বাভাবিক.

কীভাবে এগিয়ে যেতে হবে আপনার জন্য এখানে আরও কিছু পরামর্শ:

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

4
অ-প্রযুক্তিগত ব্যবসায়ের লোকদের তাদের জিনিসগুলি মনে রাখে এবং কোনওভাবে প্রযুক্তিগত জিনিসগুলি বুঝতে পারে না। এটি বিকাশকারীদের তাদের প্রযুক্তি ও কার্যকর বিকল্পগুলি ব্যয় এবং সুবিধাগুলির সাথে উপস্থাপন করার জন্য অবলম্বন করে (যার মধ্যে এইরকম কুখ্যাত ও কঠিন ও সর্বজনীন ঘৃণ্য বিষয়গুলি জড়িত যাতে কাজগুলি কতক্ষণ গ্রহণ করবে তা অনুমান করতে শেখার মতো)।
জান হুডেক

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

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

11
প্রথম পয়েন্ট একা জন্য +1। সবাইকে মনে রাখবেন, শিপিংও একটি বৈশিষ্ট্য
thegrinner

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

114

এটি ঠিকঠাক করার জন্য আমার দিকে ছুঁড়ে দেওয়া অন্যান্য সিস্টেমের মতো শোনাচ্ছে।

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

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

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

সম্পাদনা করুন (যেহেতু এই প্রশ্নের প্রচুর ভোট রয়েছে পাশাপাশি আমি আরও কিছু সামগ্রী যুক্ত করতে পারি)

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

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

ওহ এবং ইউনিট টেস্টিং বা সিস্টেম পরীক্ষার মাধ্যমে ব্যবহারকারী পরীক্ষাকে বিভ্রান্ত করবেন না।

  • ইউনিট টেস্টিং - আমার কোড ফাংশনটি কি সঠিক মানটি দেয়?
  • সিস্টেম টেস্টিং - আমি এক্স-এ ক্লিক করলে এটি ত্রুটি ঘটায়?
  • ব্যবহারকারী স্বীকৃতি পরীক্ষা (ইউএটি) - প্রোগ্রামটি প্রয়োজনীয়তার সাথে সামঞ্জস্য হয়? তারা আপনাকে এটি করার জন্য বলেছে তা কি তা করে? এটি সরাসরি যেতে পারেন?

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

একবার আপনি কয়েকবার এই প্রক্রিয়াটি অতিক্রম করার পরে আপনি চটপটি শুরু করতে পারেন .. তবে এটি অন্য একটি বিশ্ব :)

টিএল; ডিআর টেস্টিং ভাল


7
সত্য এবং সাধারণ। আমি বলব যে এটি ছেড়ে দেওয়া এমনকি স্পষ্টতই নৈতিক, প্রকল্পের কর্মীদের পরিচালনা করা নতুন আগত জুনিয়রদের সমস্যা নয়, সুতরাং কেউ যদি এর কারণে চলে যায় তবে আমি একেবারে বুঝতে পারি।
CsBalazsHungary

1
বেশিরভাগ লোকেরা টাকা নেবে এবং অদৃশ্য হয়ে যাবে তা স্বীকার করার জন্য +1। এই ধরণের জিনিসটি পরামর্শদাতাদের কাজে রাখে।
জেমস_পিক

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

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

@ ব্যবহারকারী 2785724 - আপনি কোড লিখছেন তবে আপনি একজন সত্যিকারের প্রোগ্রামার। হতে পারে আপনার অভিজ্ঞতা কম রয়েছে, তবে এটি আপনাকে কোনও কম কোডার বানায় না।
রক্লান

61

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

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

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

সর্বশেষে, আরও একটি বিস্তৃত প্রস্তাবিত পাঠ: মাটির বড় বল


1
+ + long.MaxValue জন্য c2.com/cgi/wiki আমি যে সাইট ভালোবাসি, যদিও এটা কোন ধরনের মৃত বলে মনে হয়।
ব্যবহারকারী

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

9
@ অ্যাডাম জোনস: তবে আপনি তার সফটওয়্যারটি ব্যবহার করছেন। এখনই। তিনি এই সাইটের পিছনে মূল লোক।
জানু হুডেক

1
@ জনহুদেক তিনি এবং আতউড
jpmc26

5
অবশেষে, অন্য কেউ যিনি কখনও এই সাইটটি দেখার আগে স্পোলস্কির কথা শোনেন নি। এখানে পড়া থেকে আপনি ভাবেন যে তিনিই দ্বিতীয় আসছেন।
MDMoore313

29

আমি প্রথম কোথায় এটি পড়েছি তা ভুলে গিয়েছি, তবে আমি কেবল কিছুটা আরও দৃfully়তার সাথে, অন্য লোকেরা যা বলেছে তা প্রতিধ্বনিত করতে চেয়েছিলাম:

শিপিং একটি বৈশিষ্ট্য।

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


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

24

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

নিখুঁত হ'ল শত্রু।

ক্লায়েন্টের জন্য একটি নিখুঁত সফ্টওয়্যার যা এখন প্রকাশিত হবে না তার চেয়ে ভাল একটি সফ্টওয়্যার রাখাই সর্বদা ভাল।

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


15

আমি [...] মামার বব ক্লিন কোড পড়েছি।

আমার এই অবিরাম চিন্তাভাবনা আছে যে আমাকে পুরো প্রকল্পটি আবার লিখতে হবে।

এই বইয়ের একটি বিভাগ রয়েছে, খুব যথাযথভাবে, "দ্য গ্র্যান্ড রিডিজাইন ইন দি স্কাই"।

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

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


6
কিছুটা সত্য. আমি এক দশক ধরে একই কোডবেসের নকশাকে পুনরাবৃত্তি করছি এবং আমি এখনও মনে করি গত বছর আমি যা করেছি তার আর্কিটেকচারটি বাজে কথা। আপনি শেখা কখনই বন্ধ করবেন না।
জোয়েরি সেব্রেচটস

1
এবং কেবল স্পষ্ট করে বলার জন্য, কী কী বৃদ্ধিবৃদ্ধিযোগ্য উন্নতিগুলি সম্ভব হয়েছে তা হ'ল আপনি বিদ্যমান কার্যকারিতা ভঙ্গ করছেন না এমন কিছুটা আত্মবিশ্বাস দেওয়ার জন্য আপনার কাছে পরীক্ষার ব্যাটারি রয়েছে। যদি আপনি নিজেকে "" আমি এটি পরিবর্তন করতে পারি না "ভাবছেন বলে মনে করেন তবে আপনি সবেমাত্র এমন কোনও জায়গা সনাক্ত করেছেন যার পরীক্ষার কভারেজ দরকার।
ফিল্ডিন

9

আপনি ভাল করছেন।

আপনি বলছেন যে আপনার কোডটি কাজ করে, এবং এটি প্রায় শিপিংয়ের জন্য প্রস্তুত, তাই না? এবং আপনি বুঝতে পেরেছেন যে আপনার কোডটি ব্যাপকভাবে উন্নত হতে পারে। ভাল.

আপনার দ্বিধাটি আমাকে ফ্রিল্যান্সিংয়ের সাথে আমার প্রথম অভিজ্ঞতার কথা মনে করিয়ে দেয় (বহু ভাষাতে POS সিস্টেম তৈরি করতে ইউনিতে আমার ২ য় বর্ষে ভাড়া নেওয়া) getting আমি সীমাহীন প্রশ্নবিদ্ধ হয়েছি কারণ আমি কখনই কোডটি নিয়ে সন্তুষ্ট নই, স্কেলাবিলিটি চেয়েছিলাম, আরও ভাল চাকা পুনরায় উদ্ভাবন করতে চেয়েছিলাম ... তবে আমি কেবল প্রকল্পটি বিলম্ব করেছি (যেমন, প্রায় 12 মাসের মধ্যে) এবং ... কী? আপনি জিনিসটি নিযুক্ত করার পরে এটি এখনও অনেক প্রুফিং, পরীক্ষা, প্যাচিং ইত্যাদি প্রয়োজন ...

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

আমি যখন সম্পূর্ণ পুনরায় লেখাগুলি দেখেছি কেবলমাত্র সেই ক্ষেত্রেই যখন টিম একযোগে নতুন সরঞ্জামচেন / কাঠামো গ্রহণ করেছিল।

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

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

অন্য গ্রাহক আপনাকে অনুরূপ কিছু তৈরি করতে বললে সমস্ত কিছুর পুনর্লিখনের জন্য আরও ভাল সময় হবে।

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


7

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

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

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

যদি প্রকল্পের এমন কিছু দিক রয়েছে যা বৈধভাবে বহুবর্ষ, প্রয়োগের উত্তরাধিকার ইত্যাদির জন্য আহ্বান জানায়, তবে আমি প্রস্তাব দেব যে সম্ভবত প্রকল্পের আকারটি হ্রাস করা হয়নি।


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

4

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


4

যে কারণে অন্যরা পুরোপুরি ব্যাখ্যা করেছে, এখন সময় শেষ হয়েছে যে প্রকল্পটি শেষ করে এটিকে চালিত করা হবে, যা হতে পারে তা বেদনাদায়ক।

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

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

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

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

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

1

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


0

এটি আমি ব্যক্তিগতভাবে করব:

  1. প্রস্থান করুন, একটি অজুহাত তৈরি করুন এবং ছেড়ে দিন (আপনি এমনকি খারাপ দেখায় না তাই আপনার বেতনের কিছু অংশ দিতে পারেন)
  2. আপনার কোডটি যথাসম্ভব পরিষ্কার করুন
  3. আপনার কাজের সমস্ত ভাল অংশের উপর ডকুমেন্টেশন তৈরি করুন যেমন আপনার ভাল ডিজাইন, ভাল ধারণা ইত্যাদি ...

কেন আমি এই সবগুলি আপনাকে পরামর্শ দিচ্ছি?

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

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

আমাকে বিশ্বাস করুন, এমন কিছু লোক আছেন যারা আপনাকে সম্পর্কে প্রচুর অনুমান করেছিলেন কারণ যে কোনও মুহূর্তে আপনি যে কোনও উদ্দেশ্যেই কিছু করেছিলেন। তাদের কাছে, আপনি যদি পরিস্থিতি A তে এটি করেন তবে আপনি এটি বি তে করবেন They তারা খুব সাধারণ মনে করে।


0

আরও দুটি পরামর্শ, আমি এর মধ্যে কমপক্ষে একটি করে বাজি দেব you

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

2) সংস্করণ নিয়ন্ত্রণ ব্যবহার শুরু করুন, যদিও আশা করি আপনি ইতিমধ্যে এটি করছেন।

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

সম্পাদন করা

বাহ, কেউ সত্যিই এটি পছন্দ করেন নি - ডাউনটোট এবং একটি মুছা পতাকা? কেন?

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


-2

আপনার প্রশ্নের উত্তর দিতে: যেমনটি অনেকে বলেছেন, না। এটি প্রেরণ করুন এবং বাগগুলি ঠিক করার প্রক্রিয়াটিতে এটি কিছুটা সাফ করুন।

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


-2

তিনি আপনাকে নিয়োগ দেওয়ার সময় আপনার বস আপনার অভিজ্ঞতার স্তর সম্পর্কে অবগত ছিলেন। কেবল আপনার উদ্বেগ প্রকাশ করুন এবং তাকে জানাতে আপনি এটি সম্পর্কে উদ্বিগ্ন। আপনি আরও শিখলেন এবং পরবর্তী প্রকল্পটি আপনি আরও কতটা ভাল করতে পারবেন তাও তাকে জানান let


-2

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

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

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