Seringkali saya mendengar programmer menertawakan rekan satu tim yang menulis kode lambat. Ungkapan kasar, merasa benar sendiri dalam gaya "orang bodoh ini melewati koleksi empat kali, meski bisa jadi satu", dan sejenisnya. Ketika Anda mendengar itu, Anda langsung berpikir - yah, semuanya ada di bisnis, mengapa melakukan pengulangan yang tidak perlu? Mengapa Anda tidak dapat mempelajari beberapa hal dasar, seperti cara kerja ekspresi LINQ di C #, dan menulis kode normal? Anda menertawakan orang bodoh yang tidak kompeten sampai mereka mulai menertawakan Anda. Dan percayalah - tidak ada pengetahuan pemrograman yang akan menyelamatkan Anda dari situasi di mana Anda secara tidak sadar menyukai algoritma kuadrat daripada yang linier.
Saya tidak tahu apakah ada orang yang menertawakan kode saya, tetapi saya yakin - lebih dari sekali atau dua kali saya menulis solusi yang seratus kali lebih lambat daripada yang seharusnya. Tapi dalam kasus ini, sengaja saya tulis kurang optimal. Misalnya, di C # ada loop for, dan ada metode Select collection (dalam bahasa lain lebih sering disebut map). Putarannya lebih cepat, tetapi saya menemukan pendekatan fungsional lebih estetis - dan saya menggunakannya. Saya tahu bahwa hanya ada sedikit data, tidak akan ada kemacetan, dan saya menulis kode yang, menurut saya, lebih cantik, lebih mudah dibaca, dan karenanya lebih baik. Ada banyak solusi seperti itu dalam pengembangan - dan saya memilih untuk menulis kode produktif hanya jika saya tahu pasti bahwa jika tidak penarikan akan menjadi masalah.
, -, , — . , , , . — LINQ . C# — yield — , , . — — , , . , , — .
- , yield, - . , LINQ . - , , , , . . LINQ — , .
— , . BenchmarkDotNet, Pro .NET Benchmarking, , , , , . , — .
, ? , .
Select — Select. , , , , , , .
, . " " — , . " ". , , .
, , — . . for select, , ? C#, , C# — . C++. . , , — . , , — ** . , .
, . , C#. . — , , — . , .
, . Queue, List — , . , , . — .
, . . — , . , , — , . , .
— “ ”, “ ” — , — , . , , , — . , — , , . , .
— . , ", C#, LINQ" , . , . — — — . , "yarn start" . , , . . , — — .
— . , , . — . , , , , , , . . , , . .
— , . , .
Tidak ada salahnya Anda memilih yang lebih cantik, tapi tidak lebih cepat. Dan tidak ada tragedi jika Anda tidak tahu bahwa keputusan Anda sangat tidak optimal. Masalahnya dimulai ketika Anda mengatakan produktivitas itu omong kosong dan membiarkan individu melakukannya. Tidak bro. Mempelajari cara mempercepat kode bukanlah pekerjaan bagi para kutu buku kinerja, itu bagian dari pekerjaan kami. Ketika keengganan Anda untuk mempelajari hal-hal yang rumit membuat kode Anda lambat dan juga jelek, maka Anda memiliki masalah besar.
Tonton podcast saya