মার্টিন ফাউলার

মার্টিন ফাউলার (জন্ম ১৮ ডিসেম্বর ১৯৬৩) একজন ব্রিটিশ সফটওয়্যার প্রকৌশলী, লেখক ও সফটওয়্যার উন্নয়ন বিষয়ক আন্তর্জাতিক বক্তা। তিনি অবজেক্ট-ওরিয়েন্টেড বিশ্লেষণ ও নকশা, ইউএমএল, প্যাটার্ন এবং অ্যাজাইল সফটওয়্যার উন্নয়ন পদ্ধতির (যেমন Extreme programming (এক্সট্রিম প্রোগ্রামিং)) উপর বিশেষজ্ঞ।

উক্তি

মানুষ প্রায়শই তারা কতটা সময় ডিবাগিংয়ে ব্যয় করে তা অবমূল্যায়ন করে। তারা দীর্ঘস্থায়ী একটি বাগ খুঁজে পেতে কতটা সময় লাগে সেটাও তারা কম বোঝে। কিন্তু টেস্টিংয়ের মাধ্যমে, আমি সঙ্গে সঙ্গেই বুঝে যাই কখন আমি একটি বাগ যুক্ত করেছি। এতে আমি সঙ্গে সঙ্গে বাগটি ঠিক করে ফেলতে পারি, তার আগে যে এটি গিয়ে কোথাও লুকিয়ে পড়বে। ডিবাগিং-এর চেয়ে বেশি হতাশাজনক বা সময় নষ্টকারী জিনিস খুব কমই আছে। যদি আমরা শুরুতেই বাগ তৈরি না করতাম, তাহলে কি এটা অনেক দ্রুততর হতো না?
- মার্টিন ফাউলার (Martin Fowler) (২০০২), উদ্ধৃত: ইভল্যুশনারি ডিজাইন: মার্টিন ফাউলারের সঙ্গে একটি আলাপ, তৃতীয় অংশ, বিল ভেনার্স, ১৮ নভেম্বর ২০০২।
স্বচ্ছতা মূল্যবান, কিন্তু অনেক কিছুই বিতরণকৃত অবজেক্টে স্বচ্ছ করা গেলেও, পারফরম্যান্স সাধারণত এর মধ্যে পড়ে না।
- ফাউলার (Fowler) (২০০৩), সফটওয়্যার ডেভেলপমেন্ট, ভলিউম ১১, পৃষ্ঠা ৯৯।
রিফ্যাক্টরিং হলো একটি বিদ্যমান কোডবেসকে পুনর্গঠনের জন্য একটি শৃঙ্খলাবদ্ধ কৌশল, যার মাধ্যমে কোডের বাহ্যিক আচরণ না বদলে অভ্যন্তরীণ গঠন পরিবর্তন করা হয়। এর মূল হলো একাধিক ছোট ছোট আচরণ-সংরক্ষণকারী রূপান্তর। প্রতিটি রূপান্তর (যাকে 'রিফ্যাক্টরিং' বলা হয়) সামান্য কাজ করে, কিন্তু একাধিক রূপান্তরের মাধ্যমে একটি বড় পুনর্গঠন ঘটানো যায়। যেহেতু প্রতিটি রিফ্যাক্টরিং ছোট, তাই ভুল হওয়ার সম্ভাবনাও কম। এবং প্রতিটি ছোট রিফ্যাক্টরিংয়ের পর সিস্টেমটি সচল অবস্থায় থাকে, যার ফলে পুরো সিস্টেম ভেঙে পড়ার ঝুঁকি অনেক কমে যায়।
- মার্টিন ফাউলার (Martin Fowler), refactoring.com-এ, উদ্ধৃত: লরেন্স বার্নস্টেইন ও সি. এম. ইউহাস (২০০৫), ট্রাস্টওর্থি সিস্টেমস থ্রু কোয়ান্টিটেটিভ সফটওয়্যার ইঞ্জিনিয়ারিং, পৃষ্ঠা ২৬৬।
আমি যেসব জিনিসের খোঁজ করার চেষ্টা করছি তার মধ্যে একটি হলো, ভালো বা খারাপ ডিজাইনের পেছনে থাকা সহজ নিয়মগুলো। আমি মনে করি, সবচেয়ে মূল্যবান নিয়মগুলোর একটি হলো পুনরাবৃত্তি এড়ানো। এক্সট্রিম প্রোগ্রামিং (Extreme Programming) পদ্ধতিতে একে বলা হয় একবারই এবং শুধু একবার (Once and only once)।
- মার্টিন ফাউলার (Martin Fowler), উদ্ধৃত: জেমস শোর ও শেন ওয়ার্ডেন (২০০৭), দ্য আর্ট অফ অ্যাজাইল ডেভেলপমেন্ট, পৃষ্ঠা ৩১৯।
ডিজাইনাররা প্রায়শই জটিল কিছু করে ফেলেন, যেটা নির্দিষ্ট কোনো হার্ডওয়্যার প্ল্যাটফর্মে সক্ষমতা বাড়াতে সাহায্য করে, অথচ সেটা করার চেয়ে বরং আরও হার্ডওয়্যার কেনা সস্তা হতে পারত।
- মার্টিন ফাউলার (Martin Fowler) (২০১২), প্যাটার্নস অফ এন্টারপ্রাইজ অ্যাপ্লিকেশন আর্কিটেকচার।

অ্যানালিসিস প্যাটার্নস: রিইউজেবল অবজেক্ট মডেলস (Analysis Patterns: Reusable Object Models), ১৯৯৭ (1997)

মডেলিং নীতি: মডেল সঠিক বা ভুল নয়; তারা কম বা বেশি উপযোগী হতে পারে।
- পৃষ্ঠা ২

প্রায়ই বলা হয়, একটি প্যাটার্ন যেভাবেই লেখা হোক না কেন, এর চারটি মৌলিক অংশ থাকে: যে প্রেক্ষাপটে এটি কার্যকর, সেই প্রসঙ্গের বর্ণনা; যে সমস্যাটি এটি সমাধান করে; সমাধান গঠনে প্রভাব ফেলতে পারে এমন শক্তিগুলো (forces); এবং শেষ পর্যন্ত যে সমাধান সেই শক্তিগুলোকে সামলে দেয়। … এটি এমন সংজ্ঞাকে সমর্থন করে, যা বলে “একটি প্যাটার্ন হলো একটি প্রসঙ্গে একটি সমস্যার সমাধান”—একটি সংজ্ঞা যা দুর্ভাগ্যবশত একটি একক সমস্যা-সমাধান জোড়াতেই সীমাবদ্ধ থাকে।
- পৃষ্ঠা ৬
আমি যে সংজ্ঞাটি ব্যবহার করি প্যাটার্নের জন্য, তা হলো: এমন একটি ধারণা যা একবার বাস্তব পরিস্থিতিতে কার্যকর হয়েছে এবং সম্ভবত অন্য ক্ষেত্রেও কার্যকর হবে।
- পৃষ্ঠা ৮
এই বইয়ের উদ্দেশ্যে UML ব্যবহারের দ্বিতীয় সমস্যাটি হলো, ইউনিফায়েড মডেলিং ল্যাঙ্গুয়েজ (Unified Modeling Language) বাস্তবায়ন মডেলিংয়ের ওপর গুরুত্ব দেয়, ধারণাগত মডেলিং (conceptual modeling)-এর ওপর নয়।
- পৃষ্ঠা ৩১৪

রিফ্যাক্টরিং: ইমপ্রুভিং দ্য ডিজাইন অফ এক্সিস্টিং কোড, ১৯৯৯

মার্টিন ফাউলার (Martin Fowler), কেন্ট বেক (Kent Beck), জন ব্রান্ট, উইলিয়াম অপডাইক এবং ডন রবার্টস (১৯৯৯), রিফ্যাক্টরিং: ইমপ্রুভিং দ্য ডিজাইন অফ এক্সিস্টিং কোড, অ্যাডিসন-ওয়েসলি।

যখন তুমি বুঝতে পারো যে কোনো প্রোগ্রামে একটি নতুন বৈশিষ্ট্য যুক্ত করতে হবে, কিন্তু প্রোগ্রামের কোড সেই বৈশিষ্ট্য যুক্ত করার জন্য সুবিধাজনকভাবে গঠিত নয়—তখন প্রথমে কোডটি রিফ্যাক্টর করো যাতে বৈশিষ্ট্যটি যুক্ত করা সহজ হয়, তারপর বৈশিষ্ট্যটি যোগ করো।
- পৃষ্ঠা ৭
যেকোনো নির্বোধ এমন কোড লিখতে পারে যা কম্পিউটার বুঝতে পারে। ভালো প্রোগ্রামাররা এমন কোড লেখে যা মানুষ বুঝতে পারে।
- পৃষ্ঠা ১৫
রিফ্যাক্টরিং (নাউন): সফটওয়্যারের অভ্যন্তরীণ গঠন এমনভাবে পরিবর্তন করা যাতে তা বোঝা সহজ হয় এবং পরিবর্তন করাও সস্তা হয়, কিন্তু এর দৃশ্যমান আচরণ অপরিবর্তিত থাকে। To refactor (ক্রিয়া): সফটওয়্যারকে পুনর্গঠনের জন্য একাধিক রিফ্যাক্টরিং প্রয়োগ করা, যাতে সফটওয়্যারের দৃশ্যমান আচরণ অপরিবর্তিত থাকে।
- পৃষ্ঠা ৩৩–৪৩; উদ্ধৃত: মিলিতিয়াডিস লাইত্রাস, প্যাট্রিসিয়া অর্ডোনেজ দে পাবলোস, এরনেস্তো দামিয়ানি (২০১১), সেমান্টিক ওয়েব পার্সোনালাইজেশন অ্যান্ড কনটেক্সট অ্যাওয়ারনেস, পৃষ্ঠা ১১১
প্রায়ই দেখা যায়, তিন বা চারটি নির্দিষ্ট তথ্য একসঙ্গে অনেক জায়গায় ব্যবহৃত হচ্ছে—কয়েকটি ক্লাসের ফিল্ডে, অনেক মেথড সিগনেচারে প্যারামিটার হিসেবে। এইরকম তথ্যগুলোর গুচ্ছকে আলাদা একটি অবজেক্টে রূপান্তর করাই ভালো।
- পৃষ্ঠা ৮১
যখন তোমার মনে হয় তোমাকে কোনো মন্তব্য (comment) লিখতে হবে, তখন প্রথমে চেষ্টা করো কোডটি এমনভাবে রিফ্যাক্টর করতে যাতে মন্তব্যটি অপ্রয়োজনীয় হয়ে পড়ে।
- পৃষ্ঠা ৮৮
মূল বিষয়টি হলো, যেসব অংশ ভুল হওয়ার সম্ভাবনা বেশি, সেগুলোই টেস্ট করা। এইভাবে টেস্টিং থেকে সবচেয়ে বেশি লাভ পাওয়া যায়। অসম্পূর্ণ টেস্ট লেখা ও চালানো পুরোপুরি বাদ দেওয়ার চেয়ে ভালো।
- পৃষ্ঠা ৯৮

আ ব্রিফ গাইড টু দ্য স্ট্যান্ডার্ড অবজেক্ট মডেলিং ল্যাঙ্গুয়েজ (A Brief Guide to the Standard Object Modeling Language), ২০০৪

স্টিভ মেলর (Stephen J. Mellor) এবং আমি পৃথকভাবে UML ব্যবহারের তিনটি রূপ চিহ্নিত করেছি: স্কেচ (sketch), ব্লুপ্রিন্ট (blueprint), এবং প্রোগ্রামিং ল্যাঙ্গুয়েজ (programming language)। আমার পক্ষপাতদুষ্ট চোখে সবচেয়ে সাধারণ রূপ হলো UML-কে একটি স্কেচ হিসেবে ব্যবহার করা। এই ব্যবহারে, ডেভেলপাররা UML ব্যবহার করেন একটি সিস্টেমের কিছু দিক বোঝাতে। ব্লুপ্রিন্টের মতো, স্কেচকেও ফরোয়ার্ড ইঞ্জিনিয়ারিং বা রিভার্স ইঞ্জিনিয়ারিংয়ের জন্য ব্যবহার করা যায়। ফরোয়ার্ড ইঞ্জিনিয়ারিং-এ কোড লেখার আগে UML ডায়াগ্রাম আঁকা হয়; আর রিভার্স ইঞ্জিনিয়ারিং-এ কোড থেকে UML ডায়াগ্রাম তৈরি করে বোঝার চেষ্টা করা হয়।
- পৃষ্ঠা ২
অবজেক্ট ওরিয়েন্টেড (object-oriented) গ্রাফিকাল মডেলিং ল্যাঙ্গুয়েজ নিয়ে গুরুত্বপূর্ণ বইগুলো প্রকাশিত হয় ১৯৮৮ থেকে ১৯৯২ সালের মধ্যে। এই ক্ষেত্রে অগ্রণী ব্যক্তিদের মধ্যে ছিলেন: গ্রেডি বুচ (Grady Booch) [Booch, OOAD]; পিটার কোড (Peter Coad) [Coad, OOA], [Coad, OOD]; আইভার জ্যাকবসন (Ivar Jacobson) (Objectory) [Jacobson, OOSE]; জিম ওডেল [Odell]; জিম রামবঘ (Jim Rumbaugh) (OMT) [Rumbaugh, insights], [Rumbaugh, OMT]; স্যালি শ্লেয়ার (Sally Shlaer) ও স্টিভ মেলর (Steve Mellor) [Shlaer and Mellor, data], [Shlaer and Mellor, states]; এবং রেবেকা উইর্‌ফস-ব্রক (Rebecca Wirfs-Brock) (Responsibility Driven Design) [Wirfs-Brock]।
- পৃষ্ঠা ৭

ইউএমএল ডিস্টিল্ড: আ ব্রিফ গাইড টু দ্য স্ট্যান্ডার্ড অবজেক্ট মডেলিং (UML Distilled: A Brief Guide to the Standard Object Modeling), ২০০৪ (2004)

মার্টিন ফাউলার (Martin Fowler), UML Distilled: A Brief Guide to the Standard Object Modeling Language, ২০০৪।

গ্রাফিকাল ডিজাইন নোটেশন অনেক দিন ধরেই আমাদের সঙ্গে আছে… এর প্রধান মূল্য যোগাযোগ এবং বোঝার ক্ষেত্রে। একটি ভালো ডায়াগ্রাম প্রায়শই ডিজাইন সম্পর্কে ধারণা বোঝাতে সাহায্য করে, বিশেষত যখন তুমি অনেক বিস্তারিত তথ্য এড়াতে চাও। ডায়াগ্রাম একটি সফটওয়্যার সিস্টেম বা ব্যবসায়িক প্রক্রিয়া বোঝাতেও সহায়ক। কোনো টিম যখন কিছু বোঝার চেষ্টা করে, তখন ডায়াগ্রাম বোঝার প্রক্রিয়া ও সেই বোঝাপড়াকে পুরো টিমে ছড়িয়ে দিতে সাহায্য করে। যদিও এগুলো এখনো পাঠ্য প্রোগ্রামিং ভাষার বিকল্প নয়, তবুও তারা একটি সহায়ক হাতিয়ার। … এসব গ্রাফিকাল নোটেশনের মধ্যে UML-এর গুরুত্ব এর ব্যাপক ব্যবহার ও অবজেক্ট ওরিয়েন্টেড উন্নয়ন সম্প্রদায়ে মানীকরণের কারণে।
- পৃষ্ঠা xxvi
পরিপূর্ণতা (comprehensiveness) হচ্ছে বোধগম্যতার (comprehensibility) শত্রু।
- পৃষ্ঠা ৩২