বিকাশের পদ্ধতিগুলি কি কোনও বিকাশকারীর ব্যক্তিত্ববাদকে স্কোয়াশ করা উচিত?


9

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

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

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


20
এটি অত্যন্ত খারাপ যে আপনার ক্লাসটি জলপ্রপাতের পদ্ধতিটি শিখিয়ে দিচ্ছে যা এটি সফ্টওয়্যার বিকাশের জন্য খারাপ প্রক্রিয়ার একটি সাধারণ উদাহরণ।
is

6
আমি বলব এই ক্লাসটি আপনাকে অনেক কিছু শিখিয়েছে।
জেফো

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

10
খুব সুন্দর প্রতিটি বিকাশকারী বিকাশকারীর ব্যক্তিত্ববাদের ক্ষেত্রে দেখেছেন যা স্কোয়াশ করা উচিত ছিল। (যদিও সম্ভবত জলপ্রপাত পদ্ধতি দ্বারা নয়)।
PSr

2
@ ওয়াটসিসনাম, আমি দৃ strongly়ভাবে একমত নই প্রতিটি বিকাশকারীকে জলপ্রপাতের বিকাশ শিখতে হবে যাতে তারা এটি খারাপ সফ্টওয়্যার বিকাশের একটি সাধারণ উদাহরণ হিসাবে বিবেচনা করে এবং অভিজ্ঞতা অর্জন করে। আরও অনেকগুলি দোকান এখনও সঠিক বা ভুলের জন্য জলপ্রপাত এবং এটি গুরুত্বপূর্ণ যে গ্রেডগুলি সে জন্য প্রস্তুত করা উচিত।
maple_shaft

উত্তর:


10

আপনি প্রশিক্ষককে জিজ্ঞাসা করেছিলেন কেন আপনাকে সমস্ত পদ্ধতি তালিকাভুক্ত করতে হয়েছিল?

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

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


বিভিন্ন উদ্দেশ্যে কীভাবে বিভিন্ন ডিজাইনের প্রয়োজন তা নির্দেশ করার জন্য +1। বর্গ নকশা সম্পর্কে ভাল পয়েন্ট; প্রশিক্ষককে জিজ্ঞাসা করা একটি ভাল ধারণা
এথেল ইভান্স

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

9

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

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

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

আপনি জলপ্রপাতের ঘাটতি পেয়েছেন হ্যাঁ তবে সমস্ত কিছুর শক্তি এবং দুর্বলতা রয়েছে।


4

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

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

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

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

এই সমস্ত খুব বৈধ পয়েন্ট।

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

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

আমি মনে করি এটি সত্য যে ডিজাইন এবং বাস্তবায়নের মধ্যে পুনরাবৃত্তি হওয়া দরকার - এটি এমন একটি সমস্যা যা traditionalতিহ্যবাহী জলপ্রপাতের জন্য নয়।


1
@ পিলমুনচার খুব কম লোক এটি পড়েছেন, এটি এক ধরনের দুঃখজনক।
টমাসের মালিক

3
সেই কাগজটির সবচেয়ে দুঃখজনক বিষয় হ'ল বেশিরভাগ লোকেরা প্রকৃতপক্ষে এটির মধ্য দিয়ে জলপ্রপাত আবিষ্কার করেছিল, যদিও এটি এমন একটি কাগজ যা অনুশীলনটিকে পুরোপুরি খারাপ করে দেয়।
জোয়েরি সেব্রিচটস

3

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

আপনি যদি এটিকে ক্লান্তিকর বলে মনে করেন, আপনি কোনও বাস্তব কাজের প্রোগ্রামিং না পাওয়া পর্যন্ত অপেক্ষা করুন। এক মুহুর্তের জন্য বিবেচনা করুন, সেই সফ্টওয়্যারটি আপনার জন্য একটি কার্যকর ক্যারিয়ার নাও হতে পারে।

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

তাই?

প্রশিক্ষক আমাদের প্রতিটি ফাংশন তালিকাবদ্ধ করে জিজ্ঞাসা করে আমাদের ভুল বলেছিলেন?

না এটি একটি সাধারণ প্রয়োজন।

এবং, এই নকশা পদ্ধতিগুলি কোড লেখার জন্য ডিজাইনের প্রয়োগকারী (বিকাশকারী) ব্যক্তিত্ববাদকে স্কোয়াশ করে কীভাবে তারা এটি সর্বোত্তমভাবে বুঝতে পারে?

হ্যাঁ. ব্যক্তিদের আত্মা-চূর্ণ করা সফ্টওয়্যার বিকাশের একটি গুরুত্বপূর্ণ অঙ্গ। সমস্ত স্বতন্ত্রতা সমস্ত সম্ভাব্য উপায়ে সব সময়ে সমস্ত প্রোগ্রামারদের থেকে পিটানো হবে। এটি বলে যে কোথাও কোথাও "God'sশ্বরের নিয়মকানুনের প্রোগ্রামিং" কোনও পর্বত থেকে কোনও নবীকে দেওয়া হয়েছিল।

না, আপনি কেবল টেডিয়ামের দিকে ঝুঁকছেন। এটি পেতে এবং কাজে ফিরে পেতে।


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

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

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

1
@ এস লট - আমার উদ্দেশ্যটি হ'ল যদি সফ্টওয়্যার বিকাশ ক্লান্তিকর হয় তবে আপনি এটি ভুল করছেন। আমরা প্রোগ্রামার। আমরা টেডিয়াম স্বয়ংক্রিয় করি। আমরা কোডে নিজেকে পুনরাবৃত্তি করি না এবং ডকুমেন্টেশনেও নিজেকে পুনরাবৃত্তি করার কোনও কারণ নেই।
কেভিন

1
@ কেভিন: এই উত্তরটি খাঁটি ব্যঙ্গাত্মক। যেমনটি, এটি সম্পূর্ণরূপে অনুপযুক্ত এবং আমি এটি পতাকাঙ্কিত করেছি।
মাইকেল বর্গওয়ার্ট

1

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

এবং পদ্ধতিগুলিও সীমাবদ্ধ করার জন্য তৈরি করা হয়।

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

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

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


1

আমি মনে করি প্রশিক্ষক আপনাকে এই প্রকল্পটি করার জন্য উজ্জ্বল, এবং এইভাবে আপনাকে জলপ্রপাতের উন্নয়নের পক্ষে এবং (বেশিরভাগ) কনসটি শেখায়।


1

প্রকল্প বিশ্লেষণ জটিলতা নির্ধারণের থাম্বের একটি সহজ নিয়ম হ'ল "যে বিকাশকারী বা তিনি যার জন্য কাজ করেন সেটিকে তৈরি করা সফ্টওয়্যারটির সাথে ঘটে যাওয়া যথেষ্ট নাটকীয় (সাধারণত মৃত্যু বা বিপুল পরিমাণ অর্থ হারিয়ে যাওয়া) এর জন্য দায়ী করা যেতে পারে?"

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

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

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


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

@ ক্রিস্টোফার: সেই অনুযায়ী আমার উত্তরটি সামঞ্জস্য করেছেন, মন্তব্যের জন্য ধন্যবাদ :)
ম্যাথিউউ

0

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


0

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

প্রশিক্ষক কি "আপনাকে ভুল বলেছেন"?

আমি তাই মনে করি.

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


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

@ অ্যান্ড্রু ফিনেল: সত্যটি এতটা বেদনাদায়ক, এতগুলি স্তরে।
পিটার রাওয়েল

2
@ অ্যান্ড্রু - আমি ডিওডি 2167 তে কাজ করেছি। এটি চর্চা হওয়ার সাথে সাথে এটি ভয়াবহ এবং অনুৎসাহী ছিল। পরে আমি অন্য একটি সংস্থার হয়ে কাজ করেছি যা প্রায়শই ডেলিভারি দিয়ে সরকারের জন্য চৌকস বিকাশ করছে। ক্লায়েন্ট বন্যভাবে খুশি। ছয় মাসে তাদের একটি কার্যকর অ্যাপ্লিকেশন ছিল এবং ত্রৈমাসিকভাবে নতুন বৈশিষ্ট্যগুলি পেয়েছে।
কেভিন ক্লিন

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

2
@ অ্যান্ড্রু এটি কেবল সরকারই নয়। আমি "পণ্য" এর জন্য 40 পৃষ্ঠাগুলির স্পেসিফিকেশন দেখেছি; সাধারণত আপনি এই টেবিলটি থেকে সবকিছু নির্বাচন করতে পারেন এবং দয়া করে ডাইমিকেটেড পাইপটি আমাকে দিতে পারেন। এগুলি পড়তে কেউ কখনও বিরক্ত হয় না ...
বেন
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.