Pada awal karir saya, saya mendengar ungkapan ini dari kepala departemen ACS dari salah satu pabrik Soviet ketika dia menawarkan untuk pergi bekerja di departemennya.Secara alami, maka saya tidak berpikir, dan sekarang saya tidak berpikir bahwa pemrograman dapat menjadi pengganti seks yang baik. Tetapi hanya setelah bertahun-tahun, apakah dia mampu sepenuhnya menghargai kedalaman emosi yang dia masukkan ke dalam kalimatnya. Termasuk karena saya sendiri terkadang merasakan perasaan bergetar ketika menciptakan arsitektur yang sempurna atau kode program yang indah. Dan walaupun konsep kecantikan untuk setiap orang mungkin memiliki konsepnya masing-masing, tetapi keinginan untuk kesempurnaan adalah sama untuk semua orang.Namun, emosi adalah satu hal dan insinyur pria masuk akal, itu berbeda. Dan saya sudah lama tertarik dengan pertanyaan itu, tetapi apa alasan sebenarnya mengapa saya ingin membuat kode ini indah?Siapa pun yang tertarik untuk memikirkan alasan menemukan keindahan dalam pengembangan perangkat lunak dan disiplin ilmu teknis lainnya, saya bertanya di bawah cat.Kata pengantar
Dorongan untuk menulis artikel ini adalah materi baru-baru ini tentang Habr " Hentikan sudah takut keputusan indah subyektif dalam kode - Anda bukan robot, " di mana penulis mencoba untuk membuktikan keinginan intuitifnya untuk membuat kode yang indah.Namun, dilihat dari komentar pada artikel itu, tidak semua pembaca berbagi argumen penulis di tingkat "engineering chuyka". Meskipun ada konsonan dengan argumen seperti itu:“Tentu saja, kodenya harus indah. Pohon Natal, tongkat, SEMUA dalam kehidupan harus indah! Kalau tidak, jika ada sesuatu yang jelek, Anda dapat memperkuat beton mengatakan "ini adalah bug" (kadang-kadang Anda harus hidup dengan itu, tetapi itu adalah bug!) "
Benar, yang lain menyarankan menolak suara hati dan tidak menunda memulai pengobatan untuk "perfeksionisme patologis, yang mungkin merupakan bentuk obsesi, kompulsi atau OCD."Tetapi jika kita membuang olok-olok dan lelucon, maka fenomena keinginan untuk kecantikan telah diperhatikan sejak zaman kuno dan tidak asing dengan salah satu disiplin teknis. Bagaimanapun, tidak mungkin ada orang yang akan berpendapat bahwa hasil karya seorang arsitek atau insinyur dalam desain mobil tidak dapat menjadi kesempurnaan teknis dan estetika.
Tetapi bagi saya, pengembangan perangkat lunak lebih dekat, yang akan dibahas nanti.Sakramen proses pembuatan perangkat lunak
Pengembangan perangkat lunak dapat didekati dari sudut yang berbeda. Di satu sisi, ini adalah disiplin teknis murni yang tidak memungkinkan kebebasan, dibangun di atas pendekatan yang kuat dan konsisten untuk pembangunan. Ini adalah proses lama dan debugged, yang meliputi pengumpulan persyaratan, pengembangan spesifikasi teknis, perencanaan, pemantauan implementasi rencana, pemrosesan hasil yang diperoleh, dll.Pilihan lain untuk mengembangkan produk perangkat lunak adalah Agile yang ceroboh, yang meludahi konvensi dan memuji keinginan pelanggan. Dia siap untuk membuat kembali setidaknya setiap iterasi arsitektur produk perangkat lunak dalam upaya untuk mencapai hasil yang diinginkan. Metode ini lebih seperti seni mencapai keseimbangan antara mendapatkan perangkat lunak yang berfungsi dan kelelahan penuh pada kepercayaan dan sumber daya pelanggan.Dan hanya dengan waktu Anda mulai memahami bahwa kebenaran umum jauh lebih fleksibel. Dan di air terjun yang jernih ada sedikit fleksibilitas, dan di Agile ada rencana dan tenggat waktu. Karena itu, kebenaran, seperti biasa, ada di antara keduanya.Tetapi semua ini hanya berlaku untuk sisi eksternal dari proses kerja. Dan hal yang paling menyedihkan adalah membuat kode yang indah sama sekali tidak tergantung padanya.Selain itu, kode yang sama dapat dikenali sebagai cantik dan jelek sekaligus! Dan ini berarti bahwa konsep kecantikan adalah murni individu (siapa yang akan meragukannya). Apa kode yang indah, dan bagaimana cara menulisnya? , Hasil dari ke-20 Kompetisi Internasional kode yang tidak diketahui di C .Karena itu, saya harus menggali lebih dalam, ke dasar proses ini. Dalam arah identitas pribadi pengembang, yang dapat bertindak sebagai programmer, arsitek, penguji, analis, atau bahkan semuanya sekaligus pada waktu yang bersamaan atau pada titik waktu yang berbeda.Jadi apa yang mendorong roda penggerak ini, di perusahaan kecil dan perusahaan besar, di mesin tanpa jiwa dari industri perangkat lunak?Tentu saja, pencarian kekuatan pendorong tidak dapat dilakukan tanpa psikologi.Apa kekuatan pendorongnya?
Tidak, saya tidak akan mengutip makalah ilmiah tentang psikologi atau motivasi pribadi. Sekarang siapa pun, jika diinginkan, akan menemukan banyak artikel tentang topik ini.Saya tertarik pada klasifikasi alasan memotivasi yang memotivasi pengembang untuk membuat kode program. Karena ada harapan bahwa dalam hal ini dimungkinkan untuk menemukan alasan keinginan pengembang, kadang-kadang mengevaluasi sumber dari sudut pandang estetika.Sayangnya, saya tidak memenuhi klasifikasi seperti itu (mungkin saya tidak menemukannya atau tidak melihat di sana), oleh karena itu, sebagai hasil dari menganalisis pengalaman saya sendiri dan berkomunikasi dengan kolega saya, saya memutuskan untuk secara mandiri mengidentifikasi jenis motivasi berikut untuk pengembang dengan nama konvensional: Bahan , Sosial dan Internal .Motivasi material
Jenis motivasi ini didasarkan pada insentif ekonomi. Pengembang tidak peduli apa dan bagaimana menulis. Dia akan mencoba untuk mematuhi gaya pengkodean yang disetujui dalam proyek dan dia tidak peduli tentang keindahan kode. Dengan demikian, evaluasi hasil kerja (baik milik mereka sendiri dan hasil kerja rekan) akan terjadi dari sudut pandang formal, di mana tidak ada tempat untuk estetika.Motivasi sosial
Dalam hal ini, kriteria utama untuk mengevaluasi hasil pekerjaan adalah pendapat tim, yang dapat berupa rekan kerja, teman di universitas, dll. Selain itu, penilaian dibuat tidak hanya dengan kriteria formal untuk kepatuhan dengan gaya pengkodean. Sudah ada komponen emosional, kriteria abstrak keindahan.Dan itu sudah menjadi penting bagi pengembang bahwa hasil karyanya harus pertama-tama diterima dan disetujui oleh tim, dan alasan materi mungkin berjalan di pinggir jalan. Dalam kasus yang paling canggih, pengembang siap untuk menulis kode bahkan "untuk makanan", untuk memuaskan rasa harga diri di antara kelompok sasaran atau di lingkungan sosialnya.Motivasi intrinsik
Motivasi seperti itu sangat mirip dengan sosial, hanya faktor evaluasi bukan tim, tetapi pengembang itu sendiri. Dengan motivasi internal, insentif material sama sekali tidak ada, dan hasil karya mungkin tidak pernah dipublikasikan sama sekali, karena dia telah membawa (atau terus membawa) kepuasan kepada penulisnya hanya dengan fakta keberadaannya dan tidak memerlukan penilaian konfirmasi dari luar.Tentu saja, pemisahan motif untuk programmer seperti itu bersifat kondisional dan dapat mengalir dari satu tipe ke tipe lainnya atau bahkan menjadi kombinasi dari beberapa faktor pendorong.Tetapi jika Anda melihat hasil karya programmer dari sudut pandang ini, maka dalam sistem klasifikasi seperti itu Anda sudah dapat menemukan beberapa logika dan mencoba menemukan keindahan di hampir semua kode sumber (program dari kontes IOCCC ):typedef unsigned char t;t*F="%c",l[]="|\\/=_ \n](.\0(),*(.(=(}*.)[[*.",N='\n',*
r;typedef(*H)();extern H Ar;Q(a){return(a|-a)>>31;}H S(c,a){return(H)(a&~c|(int
)Ar&c);}extern t*ist;V(t*u){*u^=*u&2^(*u>>7)*185;}Z(t*u,t n){*u-=n;}e(t c,H h){
R(h,Q(* r^c));}
I(){r=l +7-4*Q(
getchar ()^*l);
}R(H h, int c){Ar=S
(c,h);- main() ;}P(){r
++;}z() { O(&N);}
O(t*c){ printf( F,+*c);
}T(){r= "This is not a function\n" ;}w(U){
U=Z(r,8 ); r-=~Q(*
r/8-4); return 0; }M(){r=
ist-68; } h(){t G
=r[1]-r [2]^*r;
G^=30;V (&G);e(
0,(O(&G ),P(P(*
r++)),z));}g(){M();R(h,0);}f(){P(O(r));e('f',g);}p(){P();e('a',f);}d(){P(O(r));
e('n',p);}c(u){u=r[-2];T(Ar=d);R(f,Q(u^'"'));}n(){e(w(O(l+*r%8)),c);}a(){I();R(
n,0);}main(){S(Q(Ar),a)();}H Ar;t*ist="Rene Magritte"-(1898-1967);
Ketika lelucon membuat Anda berpikir
Awalnya, artikel ini ditulis sebagai lelucon, dan namanya berbicara sendiri, jadi gambar dipilih sesuai.Bayangkan keterkejutan saya ketika saya menyadari bahwa klasifikasi motif yang dirumuskan untuk para programmer yang mengidamkan kecantikan mengingatkan saya pada sesuatu. Motif-motif ini sangat jelas diproyeksikan ke piramida kebutuhan Maslow yang terkenal.
Motivasi material menutup kebutuhan akan fondasi piramida. Ini adalah kebutuhan fisiologis dan keamanan. Motivasi sosial jatuh di tengah piramida dan mengarah ke kepuasan kebutuhan untuk memiliki, cinta dan pengakuan. Dan akhirnya, Motivasi Intrinsik sangat jelas diproyeksikan ke puncak piramida dan menutup kebutuhan akan pengetahuan, estetika dan aktualisasi diri.Apakah ini bukan lelucon?
Sebagai hasil dari upaya yang tidak serius untuk mempelajari hasrat untuk kecantikan di kalangan pemrogram, diperoleh kesimpulan yang cukup masuk akal yang, jika diinginkan, dapat digunakan dalam industri pengembangan perangkat lunak.Memang, dalam kasus munculnya metodologi nyata untuk menilai keindahan kode dari sudut pandang motivasi, tidak akan sulit untuk menambahkannya ke berbagai utilitas untuk mengevaluasi gaya pengkodean, seperti pylint, cpplint dan serat lainnya. Dan setelah itu akan mungkin untuk menilai motivasi pengembang tertentu tanpa melakukan tes psikologis apa pun dan mengisi kuesioner yang membosankan. Ini akan cukup untuk melewatkan kode mereka melalui alat analisa.Mungkin aku bahkan membiarkan jin keluar dari botol, karena jika menjadi mungkin untuk mengukur motivasi dengan kode yang dibuat, maka langkah alami berikutnya adalah transisi ke manajemennya. Memang, metode penilaian motivasi ini sangat mudah diotomatisasi, dan di mana ada peluang untuk pengukuran operasional, ada juga peluang untuk manajemen operasional dari parameter yang diukur.Dengan kata lain, ketersediaan informasi operasional tentang kondisi mental anggota tim untuk manajer proyek akan membantu mereka mengevaluasi hasil upaya untuk menggeser motivasi ke arah motif sosial atau internal, secara alami, untuk menghemat insentif ekonomi. ;-)PEMBARUAN 1: Saya akan meninggalkan tautan ke sketsa darijanvarevpada topik artikel: Sergey dan "pemrograman lebih baik daripada seks"UPDATE 2:Menurut hasil pertama pemungutan suara, kecenderungan muncul untuk memilih terutama untuk motivasi intrinsik (145 - 60,3%). Tetapi sebelum memilih opsi ketiga ketika memilih, harap pertimbangkan ini: Siapa yang menentukan kriteria kualitas (atau estetika) dalam proyek Anda?Jika Anda seorang pemimpin tim, arsitek, atau orang lain yang menerima atau secara signifikan memengaruhi aturan untuk menentukan penilaian semacam itu, maka pilihan Anda adalah yang tepat.Tetapi jika kontribusi Anda pada pembentukan kriteria kualitas kode tidak signifikan (misalnya, kriteria seperti itu ditentukan bahkan sebelum Anda bergabung dengan proyek), tetapi semuanya sesuai dengan Anda sepenuhnya, maka kemungkinan besar Anda selaras dengan motivasi internal dan sosial, tetapi ketika diwawancarai, pilihan yang tepat pilih opsi kedua yaitu motivasi sosial.Untuk memverifikasi ini dengan jelas, bayangkan sebuah situasi di mana Anda memiliki suasana hati "hitam" yang buruk dan hasil kerja (kode program yang ditulis pada waktu itu) sesuai dengan itu. Apakah komit Anda akan disetujui? Jika ya, bahkan jika Anda tidak sepenuhnya memenuhi kriteria kualitas yang diterima, maka motivasi Anda benar-benar Internal. Tetapi jika kode Anda ditolak, maka motivasi Anda tetap Sosial, meskipun biasanya itu selaras dengan Internal.