Bagaimana saya dapat meningkatkan keterampilan saya saat mengerjakan proyek yang sebenarnya, tanpa adanya pengembang yang lebih berpengalaman? [Tutup]

Saya adalah pengembang utama di sebuah perusahaan kecil, bekerja dengan C # dan ASP.Net. Tim kami kecil, 2-3 orang, tanpa banyak pengalaman dalam pengembangan dan desain. Saya tidak memiliki kesempatan untuk belajar dari lebih banyak pengembang senior, tidak ada seorang pun di tim saya yang membimbing dan membantu saya memilih pendekatan terbaik, karena saya sendiri yang menangani sebagian besar proyek.

Bagaimana saya bisa meningkatkan keterampilan pengembangan perangkat lunak saya saat mengerjakan proyek yang sebenarnya, tanpa adanya pengembang yang lebih berpengalaman?

Ada banyak sumber untuk belajar dari rekan-rekan yang lebih berpengalaman: buku, blog pengembang yang terampil, Stack Exchange, ceramah / konferensi, dll. Ulasan kode juga sangat penting, dan CodeReview.SE adalah sumber daya yang berharga.

Mari kita lihat bagaimana ini bisa bekerja pada contoh.

Contoh

Anda sedang membaca posting blog yang menyebutkan istilah "ETL". Anda tidak tahu artinya, tetapi dari artikel ini, Anda samar-samar mengerti bahwa itu adalah semacam proses atau alur kerja yang memindahkan data dari beberapa dukungan data ke yang lain.

Anda pergi ke Wikipedia dan sumber daya lainnya dan mendapatkan visi yang lebih tepat tentang hal itu. Masih belum jelas kapan akan berguna menggunakan ETL. Setelah semua, tampaknya jauh lebih mudah untuk menulis query SQL yang akan melakukan semua pekerjaan, daripada menghabiskan terlalu banyak waktu untuk membangun ETL nyata.

Untuk menjawab pertanyaan-pertanyaan itu, Anda meminjam buku tentang ETL dari perpustakaan setempat Anda. Ini menjelaskan bahwa beberapa proses ekstrak-transform-beban tidak mudah dilakukan dengan query SQL sederhana: tidak hanya fase ekstrak dapat berurusan dengan beberapa, beragam dukungan data, tidak hanya database relasional, tetapi juga langkah transformasi bisa sangat rumit untuk baik memvalidasi / menormalkan data dan memetakannya.

Anda sekarang memiliki visi yang jelas tentang apa itu ETL, bagaimana menggunakannya dan terutama ketika Anda membutuhkan ETL dan kapan itu bukan alat yang tepat. Sementara itu, Anda telah menerapkan ETL kecil sebagai proyek pribadi. Proyek ini memungkinkan Anda menemukan beberapa poin yang tidak cukup jelas untuk Anda dan tidak dicakup oleh buku. Poin-poin itu agak abstrak dan tidak terkait dengan kode sumber, Anda memposting pertanyaan di Programmers.SE .

Ketika Anda memiliki kesempatan untuk membangun satu di perusahaan Anda, Anda mulai membuatnya. Anda memiliki beberapa masalah. Beberapa terkait dengan kode; Anda memposting pertanyaan di Stack Overflow . Lainnya terkait dengan database; Anda mengajukan pertanyaan pada DBA.SE .

Akhirnya, ada konferensi yang dilakukan oleh pengembang yang sangat terampil tentang cara mengoptimalkan ETL. Anda menghadiri konferensi ini dan memberi Anda petunjuk berharga tentang perangkat tambahan yang dapat Anda lakukan untuk proyek Anda.

Anda juga mulai mengikuti blog pengembang yang telah mengerjakan berbagai ETL selama bertahun-tahun. Sangat menarik untuk melihat berbagai pendekatan, dan melalui blog ini, Anda belajar tentang ECCD; Anda tertarik, jadi Anda meminjam ETK Toolkit Data Warehouse oleh Ralph Kimball, buku yang berbicara secara rinci tentang proses "ekstrak, bersihkan, sesuaikan, dan kirim". Blog yang sama juga menyebutkan banyak aplikasi yang dimaksudkan untuk membuat ETL tanpa keterampilan pemrograman. Ini sangat berguna untuk ETL yang telah Anda lakukan untuk perusahaan Anda, karena bos Anda, orang yang tidak memiliki teknologi, terus-menerus meminta Anda untuk melakukan beberapa perubahan kecil terhadap apa yang telah Anda lakukan.

Menemukan banyak hal

IMHO, bagian yang sulit, ketika Anda tidak memiliki mentor atau kolega yang lebih berpengalaman, adalah untuk menemukan sesuatu, dan dengan menemukan, maksud saya lulus dari negara bagian "Saya belum pernah mendengar tentang hal ini" ke "Saya sudah mendengar tentang itu tetapi tidak tahu apa itu ".

Jika seseorang meninjau kode saya dan mengatakan bahwa saya benar-benar harus mulai menggunakan beberapa konvensi gaya, dengan sedikit rasa ingin tahu saya dapat menemukan bahwa dalam pemrograman, ada berbagai gaya penulisan kode, bahwa seseorang harus tetap dengan gaya untuk bahasa tertentu dan basis kode, dan bahwa banyak bahasa memiliki alat untuk menegakkan gaya (seperti StyleCop untuk C #).

Jika tidak ada yang memberi tahu saya tentang gayanya, bagaimana saya tahu bahwa hal semacam itu ada?

Di situlah sumber daya seperti blog atau Stack Exchange sangat berguna. Wikipedia tidak akan membantu (kecuali Anda menghabiskan berhari-hari memukul halaman acak tentang pemrograman), dan buku-buku jarang berbicara tentang hal-hal itu.

Hal yang sama berlaku juga untuk pola dan praktik atau hal-hal yang kurang terkait dengan kode. Sebagai contoh, saya hampir tidak membayangkan beberapa pengembang bangun di pagi hari mengatakan pada dirinya sendiri bahwa dia harus belajar sesuatu tentang ITIL sementara dia tidak pernah peduli tentang ITIL sebelumnya.

Setelah Anda menemukan istilah baru, cukup mudah untuk mempelajarinya. Jika Anda telah memberikan istilah baru "kontrak kode" dan Anda adalah pengembang C #, Anda dapat dengan mudah menemukan cukup informasi sendiri di MSDN (atau, lebih baik, dalam buku Jon Skeet).

Keingintahuan membantu

Ketika saya bekerja dengan pekerja magang, saya selalu memperhatikan bahwa yang terbaik adalah mereka yang ingin tahu di luar kuliah mereka. Mereka mungkin tahu bahwa ada sesuatu yang disebut pemrograman fungsional bahkan jika tidak ada guru mereka yang pernah menyebutkannya, dan sementara mereka mungkin tidak tahu bahasa fungsional, mereka masih bisa menjelaskan secara umum apa itu FP dan bagaimana perbedaannya dari yang lain. paradigma. Mereka mungkin tahu tentang Agile, atau tentang Unicode, atau tentang model partial-trust / sandbox, hanya karena mereka membaca blog dan menggunakan Stack Exchange, daripada sekadar menghadiri kuliah mereka.

Bahkan ketika mereka tidak memiliki mentor, mereka masih mempelajari semua hal yang tidak diceritakan di perguruan tinggi.

Saya berada dalam situasi yang sama: kami adalah tim kecil dan pekerjaan pengembangan produk inti kami sebagian besar merupakan perubahan bertahap pada basis kode yang berumur beberapa tahun.

Beberapa teknik yang saya gunakan untuk tetap up-to-date dan meningkatkan keterampilan saya.

Pada pekerjaan:

• Baca: buku, blog, materi PR. Saya mengikuti sejumlah umpan RSS. Ketika kesepakatan O'Reilly hari ini adalah tentang teknologi yang belum pernah saya dengar, saya membaca deskripsi buku itu. Jika teknologinya memiliki banyak kaitan dengan apa pun yang saya kerjakan, saya menghabiskan lima atau sepuluh menit untuk meneliti lebih dalam lagi, mirip dengan jawaban MainMa. Saya ulangi ini dengan beberapa umpan RSS yang berbeda.
• Bangun rencana pelatihan bersama manajemen Anda yang dapat didukung dengan sumber daya perusahaan (waktu dan / atau uang)
• Berlawanan dengan kecenderungan kebanyakan programmer, cobalah merangkul perubahan dan opsi desain baru. Perubahan demi perubahan itu tidak baik , tetapi saya percaya terlalu sering pengembang menghindari menggunakan desain atau kerangka kerja baru karena perubahan. Ini adalah langkah yang bagus untuk berjalan, dan jangan terburu-buru mengambil keputusan yang mengikat, tetapi awasi cara-cara baru dalam melakukan sesuatu. Beberapa perubahan dapat memiliki manfaat yang tidak terduga: pindah ke DVCS biarkan saya melakukan percobaan dengan basis kode kami lebih mudah dan mencoba teknologi baru di sana.
• Beberapa orang menyukai konferensi; Saya telah menemukan bahwa hasilnya kecil untuk waktu yang diinvestasikan.

Di luar pekerjaan:

Saya mendapati bahwa mengerjakan keterampilan saya di luar pekerjaan sehari-hari sangat penting. Kebebasan untuk bereksperimen, membuat kesalahan, dan mengejar minat membuat saya tetap terlibat dalam TI. Jika saya hanya memiliki proyek di tempat kerja dan perlu membatasi pembelajaran saya untuk apa yang langsung bermanfaat, saya akan cepat lelah.

• Terlibat dalam proyek non-kerja. Bagi saya, ini sedang mengembangkan situs web fungsional yang terkait dengan minat pribadi. Saya refactor secara bebas, dan secara aktif mencoba bereksperimen dengan berbagai teknologi. Berkontribusi ke Open Source juga akan membuat Anda terpapar kode orang lain. Ini juga akan memberi Anda materi yang baik untuk dibagikan untuk wawancara dengan perusahaan yang akan memiliki lebih banyak pengembang berpengalaman.
• Kamp Kode: Jika ada kamp kode di area Anda, hadiri. Karena ini bukan selama jam kerja dan gratis, Anda merasakan kebebasan untuk menghadiri sesi apa pun untuk topik yang menarik bagi Anda secara pribadi. Dibandingkan dengan konferensi umum, ini biasanya lokal dan mencakup berbagai bidang teknologi, jadi saya percaya ada nilai yang lebih terkonsentrasi.

Dan jangan lupa untuk mengunjungi SO atau Programmer.SE sesering mungkin.

Jawaban di sini mungkin akan sangat membantu, tetapi saya ingin menekankan sesuatu: tidak ada yang dapat menggantikan bekerja dengan seseorang yang lebih baik daripada Anda (untuk definisi yang lebih baik dan sewenang-wenang, pribadi) selama 8 jam sehari, 5 hari seminggu. Itu sudah pasti.

Jika Anda adalah tipe pengembang yang selalu ingin menjadi lebih baik, selalu ingin belajar, maka Anda harus pergi ke perusahaan lain pada akhirnya. Sebanyak itu tidak bisa dihindari, dan harus direncanakan.

Ketika Anda menemukan perusahaan yang tepat untuk Anda, Anda akan menemukan bahwa Anda dapat terus tumbuh di dalamnya, daripada tumbuh keluar darinya.

Pengembangan perangkat lunak adalah olahraga tim. Seperti olahraga, untuk bermain di level yang sangat tinggi, Anda harus bersama dan bersaing dengan orang lain yang melakukan hal yang sama. Cari peluang untuk bergerak.

Ingatlah bahwa latihan menjadi permanen, jadi jika Anda tidak terus-menerus bekerja menuju teknik dan pengetahuan yang lebih baik, jika Anda bekerja dalam isolasi tanpa kritik atau panutan, Anda mungkin menemukan bahwa keterampilan Anda tidak tumbuh.

Di seluruh dunia, segala sesuatunya menjadi lebih kompetitif, jadi harapkan ceruk Anda bersifat sementara, dan bersiaplah untuk jenis peluang yang memenuhi kriteria Anda untuk pekerjaan yang memuaskan, sementara pada saat yang sama, membawa Anda keluar dari zona nyaman Anda untuk bekerja dengan tim yang unggul.

Sebelum saya mendapatkan saran, saya harus mengatakan bahwa saya berada di posisi yang sangat mirip lebih dari setahun yang lalu.

Jika Anda menyelesaikan proyek, tetapi Anda merasa ada banyak ruang untuk diperbaiki, itu adalah hal yang baik.

Pada satu kesempatan saya tidak memiliki kemampuan teknis dan kepercayaan diri untuk menyelesaikan proyek. Seringkali saya akan membeli buku, saya akan membaca blog yang cukup teknis dan menemukan diri saya "keluar dari kedalaman saya". Saya pikir masalah terbesar bagi saya adalah fakta bahwa saya tidak memiliki paparan aplikasi perusahaan besar. Cukup sering saya akan melakukan sesuatu dengan baik, tetapi saya tidak akan memiliki orang di sisi saya untuk memvalidasi apa yang telah saya lakukan.

Ini mendemotivasi dan menantang, jadi saya melihat dari mana Anda berasal. Bagaimana saya mengatasi masalah ini? Saya meninggalkan sebuah perusahaan dan bergabung dengan sebuah rumah pengembangan perangkat lunak yang mapan, yang telah membantu saya mendapatkan banyak pengalaman dalam setahun terakhir.

Kecuali jika Anda ingin meninggalkan perusahaan, saya akan menyarankan buku-buku yang telah ditulis oleh pelopor industri kami. Saya akan mulai dengan The Pragmatic Programmer oleh Andrew Hunt. Buku ini berisi banyak analogi berguna yang sangat mudah diingat. Beberapa bab pertama buku ini telah mendorong saya untuk mengambil bahasa pemrograman yang sangat berbeda dengan bahasa yang kami gunakan di tempat kerja. Saya sudah mulai membaca literatur non-teknis - Saya sekarang percaya bahwa membaca novel dan fiksi ilmiah akan membuat saya menjadi programmer yang lebih baik. Menulis esai tidak jauh dari menulis kode bersih. Beberapa penulis baik dan beberapa buruk. Buku ini membuat saya peduli dengan apa yang saya tulis. Salah satu analoginya disebut "Windows Rusak". Anda meninggalkan mobil ditinggalkan di jalan selama berhari-hari dan tidak ada yang terjadi padanya. Setelah Anda memecahkan satu jendela, mobil mungkin akan hancur pada hari berikutnya. Kode tidak berbeda. Jika Anda melihat kode yang rusak atau ditulis dengan buruk, segera perbaiki, jangan biarkan begitu saja karena cepat atau lambat kode itu akan kembali untuk "menghantui" Anda. Setelah Anda mulai mengerjakan buku ini, Anda akan mengambil lusinan analogi serupa yang akan membuat Anda berpikir tentang kode dengan cara yang berbeda.

Saya kemudian menyarankan Anda beralih ke Clean Code oleh Robert C. Martin. Buku ini lebih praktis karena memaksa Anda untuk membaca kode yang buruk dan baik (bersih). Penulis menggunakan contoh kode dari salah satu proyek sumber terbuka. Anda mengatakan tidak ada orang yang membimbing Anda. Ada peluang sempurna untuk melihat kode orang lain, membandingkannya dengan kode Anda sendiri, dan melihat bagaimana Anda dapat memperbaikinya. Bagi saya membaca buku ini seperti membayangi seseorang yang mengerjakan suatu proyek. Buku ini juga membuat penekanan kuat pada hal tersulit yang paling mudah - pemisahan kekhawatiran. Penulis telah bertanya kepada pelopor industri kami apa yang mereka anggap sebagai kode "bersih". Setelah Anda membaca jawaban mereka, Anda dapat membandingkannya dengan pendapat Anda sendiri tentang apa itu kode bersih.

Terakhir, sudahkah Anda mempertimbangkan untuk mengerjakan proyek sumber terbuka? Anda akan berkolaborasi dengan pengembang lain yang mungkin lebih berpengalaman yang dapat meninjau kode Anda dan mengarahkan Anda ke arah yang benar.

Seperti yang telah saya katakan dalam jawaban asli saya, itu tidak akan terjadi sepanjang malam. Saya telah melakukan ini selama beberapa tahun sekarang dan hampir setiap hari saya mengetahui bahwa saya telah melakukan kesalahan.

Semoga berhasil!

Berlatih memecahkan masalah. Baca dan bekerjalah untuk memahami kode orang lain (github adalah sumber yang bagus untuk ini) dan serahkan peningkatannya. Melakukan pekerjaan konsultasi benar-benar dapat membantu Anda memperluas keahlian Anda.