Bahasa Melayu

Gaya Kepemimpinan Martin Fowler: Pengamal yang Mentakrif Cara Pasukan Perisian Berfikir

Profil Kepemimpinan Martin Fowler

Fakta Utama: Martin Fowler

  • Peranan: Chief Scientist di ThoughtWorks sejak 2000 (menyertai 1999)
  • Buku Penentu: Refactoring: Improving the Design of Existing Code (1999), Patterns of Enterprise Application Architecture (2002), Microservices (bersama James Lewis, 2014)
  • Platform: martinfowler.com — esai teknikal berwibawa dalam format "bliki" (blog + wiki) yang beliau pelopori, diterbitkan secara berterusan sejak akhir 1990-an
  • Agile Manifesto: Salah seorang daripada 17 penandatangan asal (Snowbird, Utah, 2001); memberikan asas praktik teknikal Extreme Programming
  • Model pengaruh: Diperoleh semata-mata — tiada kuasa kedudukan, tiada syarikat miliknya sendiri, tiada pasukan ribuan orang

Martin Fowler tidak pernah memimpin FAANG. Dia tidak pernah mengumpulkan berbilion dolar atau menguruskan organisasi ribuan orang. Dia menyertai ThoughtWorks pada 1999 sebagai Chief Scientist dan kekal di sana selama ini, menulis, merunding, dan menerbitkan secara berterusan selama lebih 25 tahun.

Model Fowler: Pengaruh Tanpa Kuasa

Model kepemimpinan di mana kredibiliti yang bertahan diperolehi dengan menamakan dan mengkodifikasi praktik yang bidang sudah lakukan secara tidak formal, menerbitkan definisi itu secara berterusan selama beberapa dekad, dan secara terbuka mengemas kini kedudukan apabila praktik melampaui teori. Kuasa tergabung melalui ketepatan, bukan hierarki — dan badan kerja itu sendiri menjadi carta organisasi.

Namun hampir setiap pasukan perisian yang bekerja hari ini menggunakan istilah, pola, dan praktik yang beliau namakan, takrifkan, atau populerkan. Refactoring, praktik meningkatkan struktur kod tanpa mengubah kelakuannya, adalah sesuatu yang dilakukan pembangun secara senyap sebelum Fowler menulis buku yang memberikan nama padanya pada 1999. Continuous integration adalah praktik berdisiplin sebelum beliau membantu menjadikannya standard. Domain models, active records, dan data mappers adalah pola seni bina sebelum beliau mengkatalognya pada 2002. Dan microservices adalah istilah yang hampir tidak wujud sebelum beliau dan James Lewis menerbitkan artikel yang mentakrifkan konsep pada martinfowler.com pada 2014, mencetuskan gelombang seni bina yang membentuk semula cara industri membina perisian.

Pengaruh Fowler datang sepenuhnya tanpa kuasa kedudukan. Dia tidak boleh memaksa sesiapa melakukan sesuatu. Dia memimpin melalui kejelasan pemikiran yang diterbitkan kepada pembangun di seluruh dunia dalam ufuk masa yang luar biasa panjang.

Memahami bagaimana itu berfungsi — dan di mana ia tidak — berbaloi dengan masa anda sama ada anda memimpin pasukan 10 orang atau organisasi kejuruteraan 500 orang.

Pecahan Gaya Kepemimpinan

Gaya Berat Cara ia Ditunjukkan
Pengamal-Sarjana 55% Kredibiliti Fowler datang daripada gabungan pengalaman pembangunan tangan dan dokumentasi teliti. Dia tidak menulis teori dalam keterpencilan daripada jabatan universiti. Dia bekerja pada projek sebenar dengan klien sebenar dan mengekstrak pola yang muncul berulang kali. "Refactoring" adalah berdasarkan teknik terdokumen yang beliau dan rakan sekerja gunakan dalam terlibatan perundingan. "Patterns of Enterprise Application Architecture" mengkatalogkan pola yang beliau perhatikan merentasi puluhan sistem perusahaan. Asas pengamal ialah apa yang menjadikan beasiswa itu mendarat dengan orang yang perlu menulis kod setiap hari.
Pembina Infrastruktur Intelektual 45% Sumbangan kedua Fowler adalah mencipta kosa kata bersama. Sebelum "refactoring" adalah praktik yang dinamakan, pasukan bercakap samar tentang "membersihkan kod" atau "menstruktur semula." Sebaik sahaja ia mempunyai nama dan katalog teknik khusus, pasukan dapat berbincang secara jelas tentang apa yang mereka lakukan dan mengapa. Hal yang sama berlaku untuk microservices: sebelum artikel 2014, arkitektur membina perkhidmatan teragih tanpa bahasa bersama yang jelas untuk membincangkan tukar ganti. Fowler memberi konsep nama dan takrifan, yang membenarkan industri memiliki hujah sebenar tentang bila microservices masuk akal dan bila mereka tidak.

Pembahagian 55/45 menjelaskan mengapa Fowler dikaji oleh pengamal dan bukannya hanya strategis. Infrastruktur intelektual yang beliau bina berakar pada praktik, yang memberikan kepadanya jenis ketahanan yang berlainan daripada rangka kerja yang dibuat pada jarak dari kod berfungsi.

Sifat-Sifat Kepemimpinan Utama

Sifat Penilaian Maksud dalam Praktik
Dokumentasi pola yang teliti Luar Biasa Buku-buku Fowler terkenal kerana mendokumentasikan bukan hanya apa itu pola tetapi bila menggunakannya, bila tidak menggunakannya, dan tukar ganti apa yang terlibat. "Patterns of Enterprise Application Architecture" bukanlah senarai praktik baik. Ia adalah rangka kerja keputusan: diberikan konteks khusus dengan kekangan khusus, berikut adalah pola yang terpakai, inilah kos mereka, dan inilah yang anda dapatkan. Dokumentasi kontekstual yang teliti semacam itu jarang berlaku dan menjadikan buku-buku itu dirujuk bertahun-tahun selepas ia ditulis, bukannya berguna hanya apabila anda mula-mula membacanya.
Pengaruh yang diperoleh (tiada kuasa kedudukan) Sangat Tinggi Fowler telah mempengaruhi praktik ratusan ribu pembangun tanpa pernah memiliki kuasa ke atas mana-mana daripada mereka. Mekanismenya adalah persuasi murni: kualiti pemikirannya, kejelasan tulisannya, dan konsistensi outputnya selama 25 tahun. Model itu boleh dipindahkan kepada mana-mana pemimpin yang ingin membina pengaruh organisasi yang tidak bergantung pada gelaran mereka. Ia lambat — ia mengambil Fowler bertahun-tahun untuk membina kuasa yang menjadikan tulisannya semasa segera berpengaruh — tetapi ia tahan lama dengan cara yang kuasa kedudukan tidak.
Irama penerbitan panjang (25+ tahun) Tinggi Bliki pada martinfowler.com telah dikemas kini secara berterusan sejak akhir 1990-an. Itu adalah komitmen yang luar biasa: kebanyakan pengamal berhenti menerbitkan secara tetap sebaik sahaja mereka telah membuat sumbangan utama mereka. Penerbitan berterusan Fowler bermakna model intelektual beliau kelihatan dalam ufuk masa yang panjang — anda dapat melihat bagaimana pemikirannya berubah, apa yang beliau pertimbangkan semula, dan di mana beliau telah mengemas kini kedudukan yang beliau pegang secara terbuka. Catatan panjang itu adalah sebahagian daripada apa yang menjadikannya terpercaya: beliau telah konsisten betul cukup lama sehingga kedudukan baru yang beliau ambil diambil dengan serius.
Kesediaan untuk mengembangkan kedudukan awam Tinggi Fowler telah secara terbuka mengemas kini pandangannya mengenai beberapa topik utama. Beliau mengarang bersama Agile Manifesto pada 2001 dan telah menulis secara ekstensif tentang bagaimana Agile telah rosak oleh pensijilan dan kembung proses — pada asasnya mengkritik industri yang terbentuk di sekitar sumbangan beliau sendiri. Beliau mencipta microservices dan selepas itu menulis tentang "microservice premium": idea bahawa microservices menambah kerumitan yang tidak bernilai untuk kebanyakan organisasi. Beliau tidak membela badan kerja beliau sendiri. Beliau cuba menggambarkan keadaan praktik semasa dengan jelas, walaupun bermakna mengemas kini kedudukan yang berkaitan dengan namanya.

3 Keputusan yang Mentakrif Martin Fowler

1. Menerbitkan "Refactoring" pada 1999

Sebelum 1999, pembersihan kod adalah praktik tidak formal yang tidak dapat dibincangkan. Pembangun melakukannya, tetapi ia kekurangan kosa kata, pembenaran, atau teknik sistematik. Pengurus yang melihat pembangun "membersihkan kod lama" dan bukannya menghantar ciri-ciri tidak mempunyai rangka kerja untuk memahami mengapa itu bernilai.

Refactoring: Improving the Design of Existing Code mengubah itu. Fowler terus mendokumentasikan praktik berkembang pada martinfowler.com, yang telah menjadi rujukan pengamal selama lebih 25 tahun. Buku Fowler, yang dikarang bersama Kent Beck dan yang lain, memberi praktik nama dan mendokumentasikan 72 teknik refactoring khusus dengan mekanik jelas: apa yang perlu dilakukan, apa yang perlu diperiksa sebelum melakukannya, dan apa yang seharusnya menjadi hasilnya. Ia juga mengartikulasikan hubungan antara refactoring dan pengujian — anda hanya boleh refactor kod yang aman dengan ujian untuknya, kerana ujian adalah apa yang membenarkan anda mengesahkan kelakuan tidak berubah.

Akibat perniagaan adalah bahawa pasukan sekarang boleh mempunyai perbincangan jujur tentang hutang teknikal. Bukan "kami memerlukan masa untuk membersihkan kod" — permintaan yang terdengar samar dan pilihan — tetapi "kami perlu menggunakan refactoring khusus ini sebelum menambah ciri ini, kerana struktur semasa akan menjadikan ciri itu mahal untuk diuji dan mahal untuk diubah." Itu adalah klaim khusus dengan pembenaran yang dapat dipertahankan. Fowler memberikan pembangun kosa kata untuk membuatnya.

Edisi kedua pada 2018 mengemaskini katalog untuk JavaScript moden dan pola berorientasi objek, menunjukkan bahawa Fowler masih terlibat dengan praktik semasa hampir 20 tahun kemudian dan bukannya mengekalkan snapshot 1999.

Untuk pengendali hari ini, pengajaran daripada "Refactoring" bukanlah tentang kod khusus. Ini tentang nilai menamakan praktik yang organisasi anda lakukan tidak formal. Setiap organisasi mempunyai tingkah laku berkesan yang berfungsi tetapi tidak dinamakan, didokumentasikan, atau sengaja diajar. Pada saat anda menamainya, anda boleh membincangkannya, meningkatkannya, dan memasukkan orang baru ke dalamnya. Itu adalah kaedah Fowler yang digunakan pada sebarang domain.

2. Mengarang Agile Manifesto pada 2001

Pada Februari 2001, 17 pengamal bertemu di Snowbird, Utah, dan menghasilkan Agile Manifesto — dokumen empat nilai, dua belas prinsip yang menggambarkan cara berbeza membina perisian daripada metodologi proses berat yang dominan pada masa itu. Fowler adalah salah seorang daripada 17 penandatangan.

Sumbangan Fowler kepada Manifesto bukanlah pernyataan nilai itu sendiri — itu adalah kolektif — tetapi asas praktik teknikal. Beliau telah mempraktikkan dan mengajar teknik Extreme Programming (XP): test-driven development, continuous integration, pair programming, penerbitan kecil. Praktik-praktik itu adalah apa yang menjadikan nilai Manifesto berfungsi. "Merespons perubahan melalui mengikuti rancangan" terdengar seperti nilai. Continuous integration dan test-driven development adalah praktik kejuruteraan yang menjadikan aman merespons perubahan tanpa memecahkan fungsi sedia ada.

Agile Manifesto menjadi dokumen paling berpengaruh dalam metodologi pembangunan perisian abad ke-21. Ia juga menjana industri pensijilan, proses, dan rangka kerja perundingan yang Fowler kemudian menghabiskan tahun mengkritik sebagai asasnya bertentangan dengan niatnya yang asal.

Pada 2018, Fowler mengarang "Agile Fluency," yang secara jelas membezakan antara pasukan yang menggunakan kosa kata Agile dan pasukan yang mempunyai praktik teknikal asas yang menjadikan Agile bernilai. Kedudukannya, dinyatakan dengan jelas: Scrum tanpa continuous integration dan test-driven development adalah teater. Praktik-praktik itu penting; upacara adalah sekunder. Kebanyakan organisasi melaksanakan upacara dan melangkau praktik, yang merupakan alasan mereka tidak mendapat hasil yang dijangkakan oleh penulis manifesto.

3. Mencipta "Microservices" dengan James Lewis pada 2014

Pada Mac 2014, Fowler dan James Lewis menerbitkan artikel pada martinfowler.com bertajuk "Microservices." Artikel itu menggambarkan gaya seni bina perisian — perkhidmatan kecil, boleh digunakan secara bebas yang berkomunikasi melalui API — yang pasukan di Netflix, Amazon, dan ThoughtWorks telah membina tanpa nama biasa.

Artikel itu mendapat nama dengan betul, tukar ganti sebagian besar dengan betul, dan lengkung penggunaan secara dramatik salah. Apa yang diikuti adalah gelombang seni bina yang tersapu melalui industri, dengan ribuan syarikat membina semula aplikasi monolitik mereka sebagai ekosistem microservices. Ekosistem Docker dan Kubernetes yang muncul selari menjadikan microservices dapat dilaksanakan secara teknikal pada skala yang jauh lebih besar daripada sebelum ini.

Fowler dan Lewis menggambarkan pola dengan tepat. Tetapi menamakan sesuatu mencipta permintaan untuk menggunakannya di mana-mana, termasuk tempat di mana ia tidak sesuai. Werner Vogels di Amazon telah membina model perkhidmatan teragih dari dalam ke luar — operasi, pada skala — manakala Fowler mentakrifnya secara konseptual, dan jurang antara kekangan produksi yang telah dimenangi susah-payah Vogels dan pengambilan konsep industrinya tanpa kekangan itu menjelaskan banyak kegagalan microservices yang diikuti. Microservices menambah overhed sebenar: kependaman rangkaian antara perkhidmatan, kerumitan pengesan teragih, infrastruktur penemuan perkhidmatan, dan beban operasi menjalankan puluhan sistem yang digunakan secara bebas daripada satu. Untuk pasukan 5 jurutera yang menghantar produk yang tidak lagi perlu berskala, overhed itu mahal berbanding manfaat.

Fowler selepas itu menulis tentang apa yang beliau panggil "microservice premium" — pemerhatian bahawa microservices hanya membayar pada skala dan saiz organisasi yang kebanyakan pasukan tidak miliki. Beliau juga menulis "MonolithFirst," berhujah bahawa pasukan harus bermula dengan monolith dan mengekstrak microservices apabila mereka memahami sempadan mana yang benar-benar stabil. Itu adalah semakan ketara bagi narasi yang dibuat oleh artikel 2014, dan ia mencerminkan kesediaan Fowler untuk membetulkan arah walaupun pembetulan itu bertentangan dengan karyanya sendiri yang bereputasi tinggi.

Apa yang Martin Fowler Akan Lakukan dalam Peranan Anda

Jika anda seorang CEO, prinsip refactoring berlaku untuk proses organisasi. Setiap organisasi mengumpul hutang proses: aliran kerja persetujuan yang dirancang untuk masalah yang tidak lagi wujud, struktur pelaporan yang masuk akal pada skala sebelumnya, hak keputusan yang tidak dikemas kini sejak pemerolehan dua tahun lalu. Wawasan Fowler adalah bahawa anda tidak boleh refactor dengan aman tanpa ujian — mekanisme maklum balas yang memberitahu anda sama ada tingkah laku telah berubah tanpa disengajakan. Sebelum merancang semula proses organisasi utama, tanya: apakah yang setara dengan suite ujian di sini? Apakah mekanisme maklum balas yang akan memberitahu anda sama ada perubahan itu meningkat atau hanya mengubahnya?

Jika anda seorang COO, pelajaran tulang belakang teknikal Agile Manifesto boleh digunakan secara terus. Kebanyakan organisasi yang "lakukan Agile" telah melaksanakan upacara sprint — sprint dua minggu, standup harian, retrospektif — tanpa praktik kejuruteraan yang menjadikan upacara itu bernilai. Continuous integration, pengujian automatik, dan penerbitan kecil yang kerap adalah apa yang menjadikan aman untuk merancang dalam kenaikan dua minggu tanpa mengumpul risiko tersembunyi. Jika pasukan kejuruteraan anda melakukan sprint tetapi penempatan mengambil minggu dan liputan ujian rendah, anda mendapat overhed Agile tanpa manfaat. Pembetulannya bukanlah lebih banyak proses; ia adalah praktik teknikal yang Fowler gambarkan pada 2001.

Jika anda seorang pemimpin produk, nasihat MonolithFirst Fowler bernilai digunakan pada keputusan seni bina produk. Tekanan untuk merancang untuk skala dari hari pertama — untuk membina seni bina microservices sebelum anda mempunyai skala yang memerlukan ia — menghasilkan sistem yang kompleks sebelum mereka betul. Anda tidak tahu modul mana yang perlu berskala secara bebas sehingga anda telah membina produk dan melihat bagaimana ia benar-benar digunakan. Marty Cagan membuat hujah selari daripada sisi produk: anda tidak tahu apa yang perlu dibina sehingga anda telah belajar daripada pengguna, yang merupakan alasan mengapa pelaburan seni bina prematur dan komitmen roadmap prematur gagal untuk alasan asas yang sama. Nasihat Fowler: bina perkara paling mudah yang berfungsi, belajar daripada pengeluaran, dan ekstrak bahagian yang memerlukan penskalaan bebas apabila anda memahami apa bahagian-bahagian itu. Seni bina harus mencerminkan sistem yang anda benar-benar miliki, bukan sistem yang anda harap miliki dalam tiga tahun.

Jika anda berada dalam jualan atau pemasaran, model pengaruh Fowler — memperoleh kepercayaan melalui keluaran berkualiti tinggi yang konsisten dalam ufuk masa yang panjang — lebih terpakai untuk pemasaran kandungan dan kepimpinan pemikiran daripada pendekatan eksekutif lain dalam siri ini. Beliau membina salah satu suara paling berwibawa dalam perisian dengan menerbitkan secara berterusan, mengemas kini kedudukannya secara terbuka apabila ia ternyata salah, dan mengutamakan ketepatan daripada penglibatan. Kebanyakan program pemasaran kandungan meng-optimakan untuk jangkauan. Fowler meng-optimakan untuk kepercayaan. Perbezaannya tergabung selama bertahun-tahun: penontonnya membaca artikel baru kerana mereka mempercayai keputusannya daripada yang sebelumnya, bukan kerana tajuk itu membuat mereka klik.

Bagaimana Rework Operasionalkan Playbook Fowler

Leveraj Fowler datang daripada mengkodifikasi pola — mengambil tingkah laku yang pasukan lakukan secara implicit dan mengubahnya menjadi artifak yang dinamakan, dapat diajar, dapat dirujuk. Itu betul-betul jurang yang kebanyakan pasukan operasi hidup di dalamnya: pengetahuan institusional tentang bagaimana perjanjian benar-benar ditutup, bagaimana onboarding benar-benar berfungsi, atau bagaimana eskalasi benar-benar dijalankan hidup dalam kepala segelintir orang senior dan tiada tempat lain. Peranan Rework adalah menjadi katalog pola untuk operasi anda. Tahap pipeline, senarai semak serah, aliran keputusan, dan playbook lintas pasukan menjadi "Patterns of Enterprise Application Architecture" pasukan anda — didokumentasikan, disenaraikan versi, dan dapat dirujuk dan bukannya suku kaum. Dan seperti karya Fowler, pola berkembang secara terbuka: apabila tahap tidak lagi sesuai, anda menamainya semula, mengemas kini entri, dan keseluruhan pasukan melihat perubahan. Itu adalah operasi yang digerakkan pola — pengaruh tanpa kuasa, digunakan untuk cara kerja benar-benar mengalir.

Petikan Terkenal & Pelajaran Melampaui Dewan Pengarah

Daripada martinfowler.com: "Bodoh apa pun boleh menulis kod yang komputer boleh fahami. Pengatur yang baik menulis kod yang manusia boleh fahami." Jeff Dean membina sistem pada skala beberapa jurutera telah menyentuh, tetapi titik Fowler berlaku malah di sana: halangan pada pasukan infrastruktur Google bukanlah kepandaian mentah — ia sama ada orang yang mewarisi sistem dapat memahaminya dengan baik cukup untuk memperluasnya dengan aman. Itu adalah prinsip pengamal-sarjana dalam satu ayat. Kod adalah komunikasi antara orang, bukan hanya arahan kepada mesin. Halangan yang dominan dalam pembangunan perisian berskala besar bukanlah sama ada kod berfungsi — ia sama ada orang yang perlu mengubahnya enam bulan dari sekarang boleh memahaminya dengan baik cukup untuk mengubahnya dengan aman. Seluruh badan kerja Fowler adalah elaborasi prinsip itu.

Mengenai refactoring, daripada pengenalan buku: "Refactoring adalah teknik berdisiplin untuk menstruktur semula badan kod yang sedia ada, mengubah struktur dalaman tanpa mengubah kelakuan luarnya." Ketepatan takrifan itu penting. "Tanpa mengubah kelakuan luarnya" adalah halangan yang menjadikan refactoring aman. Setiap teknik refactoring dalam katalognya dirancang untuk mengekalkan kelakuan sambil meningkatkan struktur. Disiplin adalah apa yang membezakan refactoring daripada menulis semula — pembezaan yang pasukan hilang apabila mereka menggunakan perkataan secara longgar.

Beliau juga menulis, dalam "Is Design Dead?" pada 2000, tentang hubungan antara rancangan dan perubahan: "Banyak perkara yang kami gunakan untuk membenarkan rancangan awal telah ternyata salah dalam praktik." Itu adalah pernyataan yang lebih keras daripada rupa untuk jurutera yang telah dilatih untuk merancang sebelum membina. Hujah Fowler adalah bahawa rancangan harus berterusan dan bukannya dimulai di hadapan — bahawa anda belajar apa rancangan yang betul adalah dengan membina, dan bahawa merancang terlalu banyak sebelum anda mempunyai pembelajaran itu menghasilkan sistem yang dioptimakan untuk masalah anda tidak sepenuhnya fahami.

Di Mana Gaya Ini Pecah

Pengaruh tanpa kuasa adalah lambat. Fowler telah membina reputasinya selama 25 tahun. Anda tidak boleh meminjam kaedahnya dalam kitaran produk enam bulan.

Menamakan pola tidak menjamin pelaksanaan yang baik. Microservices adalah contoh paling jelas: penerangan seni bina yang teliti menjadi kelilinggi kargo. Pasukan mengambil pola tanpa kematangan organisasi, pelaburan perkakas, atau skala yang menjadikannya bernilai. Fowler menamakan konsep dengan betul, tetapi penamaan itu mempercepatkan penggunaan lebih cepat daripada pemahaman. Itu adalah risiko yang wujud dalam pembangunan infrastruktur intelektual — anda menghantar alat yang berkuasa kepada orang yang mungkin tidak mempunyai konteks untuk menggunakannya dengan aman.

Dan suara pengamal-sarjana tidak diterjemahkan kepada syarikat dalam tekanan pelaksanaan. Tulisan Fowler adalah bertujuan, bernuansa, dan panjang. Ia dirancang untuk perenungan, bukan untuk membuat keputusan di bawah tempoh akhir. Pemimpin yang perlu memilih seni bina dalam seminggu dan menghantar dalam sebulan tidak mempunyai kemewahan bekerja melalui analisis kontekstual penuh yang buku-bukunya perlukan. Rangka kerja beliau paling berguna untuk pemimpin yang mempunyai kestabilan operasi cukup untuk berfikir dengan teliti — yang tidak selalu situasi anda benar-benar berada.

Soalan Lazim tentang Kepemimpinan Martin Fowler

Siapakah Martin Fowler?

Martin Fowler adalah seorang jurutera perisian British, pengarang, dan Chief Scientist di ThoughtWorks, yang luas dianggap sebagai salah satu suara paling berpengaruh dalam seni bina perisian dan praktik kejuruteraan. Beliau telah membentuk bidang tanpa pernah memimpin syarikat — dengan menulis buku, menerbitkan esai pada martinfowler.com, dan mengkodifikasi pola yang pengamal gunakan setiap hari.

Apakah Refactoring menurut Fowler?

Dalam bukunya 1999, Fowler mentakrifkan refactoring sebagai "teknik berdisiplin untuk menstruktur semula badan kod yang sedia ada, mengubah struktur dalaman tanpa mengubah kelakuan luarnya." Buku itu mengkatalogkan 72 teknik khusus dengan mekanik jelas dan mengikat praktik kepada pengujian automatik, yang memungkinkan anda refactor dengan aman tanpa memperkenalkan regresi.

Apakah peranan Fowler di ThoughtWorks?

Fowler menyertai ThoughtWorks pada 1999 dan telah berkhidmat sebagai Chief Scientist sejak 2000. Peranan itu luar biasa — ia bukan kepimpinan operasi firma tetapi mandat untuk menulis, merunding pada terlibatan klien, dan menerbitkan pola yang muncul daripada praktik ThoughtWorks. Ia adalah platform di mana beliau telah menghasilkan kebanyakan kerja awamnya.

Apakah yang dikenali oleh martinfowler.com?

Laman web dikenali untuk format "bliki" — hibrid blog dan wiki yang Fowler pelopori pada awal 2000-an — di mana esai teknikal bentuk panjang duduk bersama entri rujukan yang dikemas kini secara berterusan. Ia telah menjadi rujukan berwibawa tentang seni bina perusahaan, microservices, refactoring, continuous integration, dan praktik agile selama lebih 25 tahun.

Apakah sumbangan Fowler kepada Microservices?

Pada Mac 2014, Fowler dan James Lewis menerbitkan artikel pada martinfowler.com bertajuk "Microservices" yang memberi gaya seni bina namanya dan takrifan paling banyak dipetik. Artikel itu menggambarkan pola yang pasukan di Netflix, Amazon, dan ThoughtWorks sudah mempraktikkan tanpa kosa kata bersama, dan ia mencetuskan gelombang penggunaan industri yang diikuti.

Apa yang boleh pemimpin kejuruteraan pelajari daripada Martin Fowler?

Tiga perkara. Pertama, namakan praktik pasukan anda lakukan tidak formal — penamaan menjadikannya mudah dibincang, mudah diajar, dan dapat diperbaiki. Kedua, bina pengaruh melalui keluaran yang konsisten dan tepat dalam ufuk masa yang panjang daripada melalui gelaran atau bilangan pegawai. Ketiga, bersedia untuk secara terbuka mengemas kini kedudukan anda sendiri apabila praktik menunjukkan mereka tidak lengkap. Fowler mengemas kini pandangannya tentang Agile, tentang microservices, dan tentang rancangan awal — dan kesediaan itu adalah sebahagian daripada alasan beliau kekal dipercaya.

Untuk bacaan berkaitan tentang praktik kejuruteraan dan budaya, lihat Gaya Kepemimpinan Werner Vogels, Gaya Kepemimpinan Linus Torvalds, dan Gaya Kepemimpinan Andy Grove.