Haruskah saya melanjutkan praktik pengkodean otodidak atau belajar bagaimana melakukan pengkodean secara profesional? [Tutup]

Akhir-akhir ini saya mendapatkan pekerjaan profesional, bergaul dengan programmer lain, dan berteman di industri. Satu-satunya hal adalah saya 100% belajar sendiri. Ini menyebabkan gaya saya sangat menyimpang dari gaya mereka yang terlatih dengan baik. Teknik dan pengaturan kode saya berbeda.

Ini campuran dari beberapa hal yang saya lakukan. Saya cenderung untuk menggabungkan beberapa paradigma pemrograman bersama. Seperti Fungsional dan OO. Saya condong ke sisi Fungsional lebih dari OO, tapi saya melihat penggunaan OO ketika sesuatu akan lebih masuk akal sebagai entitas abstrak. Seperti objek game. Selanjutnya saya juga pergi rute sederhana ketika melakukan sesuatu. Sebaliknya, sepertinya kadang-kadang kode yang saya lihat dari programmer profesional rumit untuk itu! Saya menggunakan banyak penutupan. Dan terakhir, saya bukan komentator terbaik. Saya merasa lebih mudah hanya membaca kode saya daripada membaca komentar. Dan kebanyakan kasus saya hanya berakhir membaca kode meskipun ada komentar. Ditambah lagi, saya telah diberitahu bahwa, karena betapa mudahnya saya menulis kode saya, sangat mudah untuk membacanya.

Saya mendengar programmer yang terlatih secara profesional terus-menerus tentang hal-hal seperti tes unit. Sesuatu yang belum pernah saya gunakan sebelumnya, jadi saya bahkan tidak tahu apa pun itu atau bagaimana cara kerjanya. Banyak dan banyak garis bawah "_", yang sebenarnya bukan seleraku. Sebagian besar teknik yang saya gunakan langsung dari saya, atau beberapa buku yang pernah saya baca. Tidak tahu apa-apa tentang MVC, saya sudah mendengar banyak hal tentang hal-hal seperti backbone.js. Saya pikir ini adalah cara untuk mengatur aplikasi. Tapi itu membingungkan saya karena sekarang saya sudah membuat struktur organisasi saya sendiri.

Agak menyebalkan. Saya tidak bisa menggunakan aplikasi template sama sekali ketika mempelajari sesuatu yang baru seperti dengan Ubuntu dengan cepat. Saya mengalami kesulitan memahami kode yang dapat saya katakan adalah dari seseorang yang terlatih. Pemrograman OO lengkap benar-benar meninggalkan rasa tidak enak di mulut saya, namun tampaknya itulah yang SEMUA ORANG lain gunakan dengan ketat.

Itu membuat saya tidak begitu percaya diri dalam melihat kode saya, atau bertanya-tanya apakah saya akan menimbulkan percikan api ketika bergabung dengan perusahaan atau mungkin berkontribusi pada proyek open source. Bahkan saya agak takut pada kenyataan bahwa orang-orang pada akhirnya akan memeriksa kode saya. Apakah ini sesuatu yang normal yang dialami oleh setiap programmer atau haruskah saya benar-benar ingin mengubah teknik saya?

Bahkan saya agak takut pada kenyataan bahwa orang-orang pada akhirnya akan memeriksa kode saya.

Baik. Sadar bahwa orang akan melihat kode Anda akan membuat Anda berusaha lebih keras.

Pemrograman telah menjadi bidang yang sangat besar. Ada puluhan topik, alat, ceruk, dan spesialisasi, beberapa di antaranya adalah karier penuh untuk diri mereka sendiri. Ada banyak hal untuk dipelajari dan diketahui, dan ketika Anda bekerja dengan programmer lain, akan selalu ada hal-hal yang Anda tahu tidak mereka miliki dan hal-hal yang mereka tahu tidak Anda ketahui. Ini hal yang baik.

Jika Anda khawatir bahwa pengalaman Anda tidak lengkap, ada banyak langkah yang dapat Anda ambil untuk mengubahnya melalui pendidikan formal dan kolaborasi dengan para ahli yang terlatih. Tapi sepertinya Anda takut ada beberapa tonggak yang dapat diukur setelah mana orang mengatakan "Oke, sekarang saya sudah menguasainya, saya resmi seorang programmer." Tidak ada tonggak sejarah seperti itu. Saya pasti memiliki saat-saat ketika saya berpikir "ya, sekarang saya mendapatkan suatu tempat" setelah saya mempelajari sesuatu yang baru, tetapi tidak ada daftar hal-hal ajaib yang harus Anda ketahui dan lakukan untuk menyebut diri Anda seorang programmer.

Saya tahu banyak hal tentang pemrograman, saya telah menggunakan selusin bahasa di banyak proyek, namun subset dari pengetahuan pemrograman yang bisa saya sebut sendiri adalah kecil. Dan saya suka itu. Terus terang, seorang programmer bukanlah sesuatu yang Anda. Seorang programmer adalah sesuatu yang terus-menerus Anda pelajari.

Ambil inventaris kejujuran keterampilan Anda, kekuatan dan kelemahan Anda. Dapatkan umpan balik dari orang-orang dengan pengalaman lebih dari Anda. Cari posisi yang sesuai dengan posisi Anda saat ini - tetapi jangan takut untuk mencari pekerjaan yang sedikit di luar penguasaan Anda saat ini. Jika Anda hanya mengambil pekerjaan yang sudah Anda ketahui segalanya, Anda tidak akan pernah belajar di tempat kerja.

Ketika Anda mulai mengembangkan aplikasi bekerja sama dengan pengembang lain, beberapa kelemahan gaya pribadi ini akan menghalangi.

Jika Anda mulai bekerja di toko yang menggunakan garis bawah, Anda akan menggunakan garis bawah. Semua orang, terlepas dari latar belakang mereka sebelumnya, mengikuti standar toko untuk gaya pengkodean.

Kecuali jika gaya pengkodean Anda sangat jelas, Anda sebaiknya membiasakan diri dengan komentar yang jelas dan singkat yang menjelaskan cara kerja kode Anda, sehingga pengembang lain dapat mengikutinya.

Jika Anda tidak tahu apa-apa tentang unit test, beli buku yang bagus. Ada banyak buku bagus tentang pengujian unit di luar sana. Sama dengan MVC.

Pengembang perangkat lunak profesional tahu cara bermain bagus dengan orang lain, tanpa membuang sampah sembarangan. Yang terbaik tahu cara membaca dan menulis kode terlepas dari gaya.

Pemrograman memiliki komponen seni dan komponen disiplin untuk itu. Komponen seni dalam memikirkan pendekatan terbaik dan menerapkannya; disiplinnya adalah memastikan bahwa Anda melakukannya dengan benar, dan bahwa orang lain dapat memahami kode Anda dan meningkatkannya bila perlu.

Komponen seni itu menyenangkan: Anda melakukannya karena Anda menikmatinya. Secara alami, itu adalah bagian yang Anda ajarkan pada diri sendiri terlebih dahulu.

Komponen disiplin lebih merupakan gangguan: Anda melakukannya karena kebutuhan. Namun, ini adalah komponen penting dalam bekerja dalam tim: Anda tidak dapat melepaskan diri dari melakukannya, setidaknya sampai taraf tertentu. Setelah kode Anda terintegrasi dengan rekan setim Anda, kelenturan Anda untuk "mengubah segalanya sesuka hati" akan mereda. Namun Anda memerlukan kemampuan untuk mengubah kode Anda dengan percaya diri sebagai respons terhadap perubahan persyaratan, atau untuk mengatasi bug. Di sinilah berbagai tes "membosankan" masuk: dengan banyak tes di tempat, mudah untuk memeriksa apakah perubahan terbaru Anda merusak atau tidak.

Gaya kode juga penting, karena mengikuti gaya umum membuat kode lebih mudah dibaca untuk semua orang. Di perusahaan yang lebih besar, Anda akan menemukan pekerjaan malam yang menguji kepatuhan dengan standar pengkodean secara otomatis, dan mengirimi Anda email peringatan buruk ketika Anda menyimpang.

Kembali ke pertanyaan Anda, berkonsentrasi pada komponen seni adalah tahap awal alami pengembangan programmer. Butuh waktu beberapa tahun untuk bekerja di industri ini sebelum Anda mulai menghargai komponen disiplin. Anda tidak perlu secara aktif mencari untuk "mengubah teknik Anda", meskipun: mereka akan berubah secara alami dalam proses bekerja dalam tim.

Untuk pertanyaan Anda, ya Anda harus selalu mencari untuk mengubah teknik Anda, untuk merangkul proyek unik dan teknologi yang muncul.

@ assumpows's point of "Terus terang, seorang programmer bukanlah sesuatu yang Anda. Seorang programmer adalah sesuatu yang Anda terus belajar untuk menjadi." benar-benar menjadi segalanya dan mengakhiri semua pengkodean.

Sangat menyenangkan bahwa Anda memperhatikan area di mana Anda melakukan sesuatu yang berbeda dari yang lain, terutama ketika Anda melihatnya sebagai standar. Anda telah melihat Unit Testing dan MVC - dan sekarang langkah selanjutnya Anda harus mempelajarinya. Lihat bagaimana mereka bekerja, apa yang Anda butuhkan untuk mengimplementasikannya dan coba dan rasakan kapan itu merupakan desain yang baik untuk mengimplementasikannya.

Ini adalah bidang yang terus berkembang dengan bahasa dan pola baru naik dan turun. Jika Anda merasa nyaman dengan aspek pengkodean, mulailah memeriksa bagian desain. Pelajari apa yang membuatnya baik dan kapan menggunakannya.

Tentu saja bergabung dengan tim adalah manfaat besar - Anda selalu membutuhkan mata lain untuk melihat kode Anda untuk mengetahui area yang Anda buru-buru atau tidak memikirkan implikasi penuh.

Anda tidak perlu menjadi komentator yang lebih besar. Tetapi Anda harus menjadi pengawas yang baik (ya, mulailah menggunakan semacam VCS - saya sarankan Git).

Gaya adalah hal yang SELALU berevolusi. Jangan khawatir tentang itu. Anda akan belajar kode apa yang dapat digunakan kembali dan apa yang tidak. Tetapi Anda harus berlatih dan mendapatkan bantuan untuk itu.

Coba bantu dalam beberapa proyek Open Source di Github. Beberapa orang benar-benar baik di sana, dan akan mencoba membantu Anda. Ini tip terbaik yang bisa saya berikan kepada Anda.

Bahkan saya agak takut pada kenyataan bahwa orang-orang pada akhirnya akan memeriksa kode saya. Apakah ini sesuatu yang normal yang dialami oleh setiap programmer atau haruskah saya benar-benar ingin mengubah teknik saya?

Bagaimana Anda tahu apa yang harus diubah tanpa umpan balik dari programmer yang lebih berpengalaman?

Meminta orang lain meninjau pekerjaan Anda dapat menjadi hal yang menakutkan, terutama beberapa kali pertama, tetapi ini adalah cara terbaik untuk mendapatkan kritik konstruktif yang Anda butuhkan untuk meningkatkan keterampilan Anda. Ada situs SE untuk ulasan kode yang mungkin bermanfaat bagi Anda. Meminta teman yang pintar untuk melihat kode Anda adalah cara lain yang baik untuk mendapatkan umpan balik.

Yang paling penting adalah mengembangkan fleksibilitas. Semakin Anda terbiasa dengan konsep dasar, semakin responsif Anda dalam bahasa apa pun, pendekatan pemrograman, gaya, atau lingkungan.

Penguasaan kurang tentang belajar setiap hal yang ada untuk belajar, dan lebih banyak tentang belajar / bagaimana / untuk menyelesaikan masalah, dalam berbagai situasi.

Dan resep terbaik untuk itu adalah latihan. Anda harus selalu memiliki proyek; jika Anda berada di antara pertunjukan berbayar, ambil mainan pribadi. Waktu luang satu akhir pekan? Bekerja melalui 'hello world' untuk bahasa atau platform yang belum pernah Anda gunakan sebelumnya. Cari cara untuk belajar banyak sekaligus. Misalnya, buat sesuatu di Google App Engine, dan Anda akan belajar sekaligus tentang database Python, BigTable, dan berorientasi kolom. Anda akan mendapatkan dosis gaya Google "profesional" yang bagus juga.

Seorang jenderal yang baik tahu bagaimana menerapkan taktik yang dipelajari dan mengumpulkan pengalaman di berbagai medan. Sepertinya Anda memiliki beberapa taktik dan pengalaman, tetapi Anda harus menghadapi medan yang tidak dikenal. Itu mungkin satu-satunya cara terbaik untuk memastikan apa yang Anda ketahui dan apa yang perlu Anda pelajari selanjutnya.

Dan jika gaya "profesional" adalah yang Anda cari, lakukan beberapa proyek "profesional". Temukan proyek open-source yang Anda sukai, tetapkan sendiri perubahan yang harus dilakukan, dan atur. Bersiaplah untuk pengulas jackass, tetapi ingat bahwa sebagian besar orang di bidang ini tidak mendapatkan tempat mereka memiliki keterampilan sosial yang lancar. Intinya adalah untuk mengekspos diri Anda sebanyak mungkin yang Anda inginkan. Dan Anda harus membangun diri Anda dengan cukup baik untuk melakukannya sendiri. Tidak ada kelas yang bisa mengajarkan Anda. Faktanya, ada terlalu banyak pembelajaran di kelas yang terjadi hari ini, dan tidak cukup kompetensi dunia nyata.

Itu membuat saya tidak begitu percaya diri dalam melihat kode saya, atau bertanya-tanya apakah saya akan menimbulkan percikan api ketika bergabung dengan perusahaan atau mungkin berkontribusi pada proyek open source. Bahkan saya agak takut pada kenyataan bahwa orang-orang pada akhirnya akan memeriksa kode saya. Apakah ini sesuatu yang normal yang dialami oleh setiap programmer atau haruskah saya benar-benar ingin mengubah teknik saya?

Menurut pendapat saya, tidak perlu khawatir tentang apa yang orang lain pikirkan tentang kode Anda jika Anda fokus pada ukuran obyektif kualitasnya. Apakah itu

• Benar?
• Bisa dimengerti
• Dapat dipelihara?
• Efisien?

Sebagai prinsip pertama, itu harus selalu menjadi tujuan Anda untuk fokus pada kualitas objektif, daripada pendapat orang lain. Berfokus pada pendapat orang lain adalah jalan menuju biasa-biasa saja, dan, seperti yang Anda alami, kecemasan.

Satu-satunya alasan untuk peduli dengan pendapat orang lain adalah untuk dapat berintegrasi dengan baik secara sosial (atau dalam lingkungan kerja) dengan mereka. Jika Anda memiliki tujuan utama dalam meningkatkan kualitas obyektif dari pekerjaan Anda, maka tidak perlu merasa takut dengan reaksi orang lain - mereka hanya peluang untuk belajar atau, paling buruk, detail praktis untuk berurusan dengan .

Jujurlah pada diri sendiri !! Terus belajar dan nikmati apa yang Anda lakukan.

Anda mengingatkan saya pada diri saya setelah kuliah untuk menjadi Insinyur Perangkat Lunak. Jika Anda ingin menjadi seorang programmer saya akan mengatakan mengambil posisi. Anda akan perlu mengomentari kode Anda, menulis tes unit, memahami, sepenuhnya, kode berorientasi objek. Tetapi saat ini Anda tidak memiliki alasan kuat untuk melakukannya. Selama Anda hanya mengerjakan proyek kecil pribadi. Di mana Anda tidak perlu menjawab siapa pun kecuali diri Anda sendiri. Anda tidak akan tumbuh lebih jauh sebagai pengembang.

Dengan mengambil proyek besar yang banyak orang kerjakan dan harus menjawab pertanyaan manajemen seperti "Apakah bug rilis ini gratis? Karena kita akan merilisnya kepada pelanggan." Anda akan tumbuh sebagai programmer / engineer. Anda akan mendapatkan ketukan keras. Anda mungkin menemukan hal-hal yang Anda sebutkan lebih berharga dan Anda mungkin menemukan hal-hal baru yang belum pernah dimiliki sebelumnya. Kamu akan tumbuh.

Bahkan perguruan tinggi saya gagal mengajari saya hal-hal ini meskipun mereka berusaha.

Untuk Pengujian Unit, cari Pengembangan Berbasis Tes.

Untuk Mengomentari pikirkan kode yang telah Anda tulis setelah Anda pergi. Dan waktu orang lain akan menghabiskan reverse engineering-nya.

Untuk Bahasa Berorientasi Objek. Setidaknya pahami itu. Ini adalah alat yang dapat Anda gunakan untuk menyelesaikan masalah dengan cara yang lebih mudah dibaca.

Semoga Sukses: D

Singkatnya, cara terbaik untuk belajar umumnya untuk bergaul dengan seseorang yang Anda bisa belajar dari . Jika Anda merasa keterampilan Anda tidak maksimal, bergaul dengan orang-orang yang lebih baik daripada Anda adalah yang terbaik yang dapat Anda lakukan. Tentunya jauh lebih baik daripada menarik diri dan mengisolasi diri lebih jauh.

Namun, saya pikir Anda sedang melukis gambar yang sangat sederhana dan menyesatkan. Jauh dari semua programmer "yang diajarkan secara profesional" benar-benar ada gunanya. Hanya karena mereka melakukan sesuatu tidak selalu berarti itu adalah hal yang benar untuk dilakukan.

Dan banyak (tetapi tidak semua) dari apa yang Anda katakan benar-benar terdengar seperti Andalah yang bisa mengajari mereka satu atau dua trik.

Saya condong ke sisi Fungsional lebih dari OO, tapi saya melihat penggunaan OO ketika sesuatu akan lebih masuk akal sebagai entitas abstrak.

Kedengarannya bagus bagi saya. Coders terbaik adalah mereka yang menggunakan alat yang tepat untuk pekerjaan itu. Saya selalu memilih seseorang yang tahu kedua paradigma, dan menggunakan masing-masing dari mereka di mana masuk akal dibandingkan seseorang yang secara religius hanya menggunakan satu paradigma.

Selanjutnya saya juga pergi rute sederhana ketika melakukan sesuatu. Sebaliknya, sepertinya kadang-kadang kode yang saya lihat dari programmer profesional rumit untuk itu!

Sekali lagi, kesederhanaan itu baik . Jangan membuat kode Anda yang kompleks sampai perlu menjadi kompleks. Beberapa orang yang cenderung membuat hal-hal yang kompleks dari beberapa ide sesat elegan, atau karena "kita akan membutuhkan fungsi tambahan ini nanti". Secara umum, lebih baik melakukan hal paling sederhana yang menyelesaikan masalah Anda.

Saya menggunakan banyak penutupan. Baik. Itu sebabnya mereka ada di sana. Mereka benar-benar menakuti beberapa orang yang terjebak dalam model kuasi-OOP yang sudah ketinggalan zaman dan Jawa, tetapi sungguh, itulah masalah mereka.

Dan terakhir, saya bukan komentator terbaik.

Apa yang harus dikomentari, dan bagaimana, sangat subjektif. Tidak ada "benar" atau "salah" yang nyata di sana, tetapi ketika mengerjakan sebuah tim, penting untuk menulis kode yang dapat dipahami oleh seluruh tim, dan bukan hanya pembuat kode. Dan terkadang, kompromi harus dilakukan agar sesuai dengan gaya pengkodean tim. Itu tidak berarti bahwa Anda harus menulis lebih banyak komentar, itu hanya berarti bahwa itu adalah sesuatu yang harus Anda dan tim Anda setujui.

Saya mendengar programmer yang terlatih secara profesional terus-menerus tentang hal-hal seperti tes unit. Sesuatu yang belum pernah saya gunakan sebelumnya, jadi saya bahkan tidak tahu sama sekali tentang apa itu mereka atau bagaimana mereka bekerja.

Nah, tanya mereka. :) Menguji kode Anda sangat penting, dan unit test adalah alat yang populer dan berguna untuk ini.

Banyak dan banyak garis bawah "_", yang sebenarnya bukan seleraku.

Seperti komentar, itu subjektif, dan tergantung pada bahasanya. Dalam C dan C ++, lowercase_with_underscoresadalah konvensi penamaan yang cukup umum. Dalam banyak bahasa lain, Anda sebenarnya tidak akan pernah melihat garis bawah. Tetapi pada akhirnya, itu benar-benar tidak penting. Apakah suatu fungsi dipanggil write_to_logatau WriteToLogtidak, sebenarnya akan membuat perbedaan. Seseorang harus hanya menghisapnya dan menyesuaikan diri dengan apa yang telah disepakati tim di sana.

Tidak tahu apa-apa tentang MVC, saya sudah mendengar banyak hal tentang hal-hal seperti backbone.js. Saya pikir ini adalah cara untuk mengatur aplikasi. Tapi itu membingungkan saya karena sekarang saya sudah membuat struktur organisasi saya sendiri.

Seperti halnya tes unit, jangan pernah berhenti belajar. Anda bekerja bersama orang-orang yang tahu hal-hal yang tidak Anda ketahui, dan yang berasal dari latar belakang yang berbeda dari Anda. Belajar satu sama lain. Jelas ada hal-hal yang dapat Anda ajarkan kepada mereka, tetapi ada juga hal-hal yang tidak Anda ketahui, atau belum pernah Anda dengar, yang dapat mereka ajarkan kepada Anda. Itu tidak berarti Anda (atau mereka) adalah programmer yang buruk. Ini berarti bahwa seorang programmer yang baik adalah orang yang berusaha untuk meningkatkan, dan belajar dari orang lain.

Pemrograman OO lengkap benar-benar meninggalkan rasa tidak enak di mulut saya

Sama di sini, dan saya adalah apa yang Anda sebut "terlatih secara profesional" (gelar CS). Orang-orang yang telah diajarkan pemrograman berbeda seperti halnya orang-orang yang belajar sendiri. Sepertinya Anda bekerja dengan beberapa orang yang benar-benar perlu mempelajari beberapa trik baru.

Bahkan saya agak takut pada kenyataan bahwa orang-orang pada akhirnya akan memeriksa kode saya. Apakah ini sesuatu yang normal yang dialami oleh setiap programmer atau haruskah saya benar-benar ingin mengubah teknik saya?

Kedua. Tentu saja menakutkan untuk membuat orang lain melihat (dan menilai) apa yang telah Anda buat. Tapi ini juga sangat mendidik. Mereka dapat memberi tahu Anda apa yang telah mereka lakukan sebaliknya, atau mengapa mereka melakukannya sebaliknya. Mereka dapat membantu Anda meningkat, dan mereka mungkin juga belajar sesuatu sendiri. Tunjukkan pada mereka kode yang memecahkan masalah lebih baik daripada solusi "pilihan" mereka, dan mudah-mudahan mereka akan pergi "oh, itu rapi. Bagaimana Anda tahu untuk melakukan itu? Apa yang Anda sebut ini? Saya harus menggunakan teknik ini sendiri "

Ini bukan jawaban lengkap, Anda sudah mendapatkan beberapa yang bagus. Namun, ada beberapa poin yang bagi saya terlihat agak membingungkan dan belum diatasi.

Ini campuran dari beberapa hal yang saya lakukan. Saya cenderung memadukan beberapa paradigma pemrograman menjadi satu. Seperti Fungsional dan OO. Saya condong ke sisi Fungsional lebih dari OO, tapi saya melihat penggunaan OO ketika sesuatu akan lebih masuk akal sebagai entitas abstrak. Seperti objek game.

Bagi saya sepertinya Anda membingungkan deklaratif vs pemrograman imperatif , daripada pemrograman Fungsional Vs Object Oriented. Jika Anda bermaksud bahwa Anda condong ke arah pemrograman deklaratif dan jauh dari keharusan maka itu adalah hal yang baik. Deklaratif berupaya menghilangkan efek samping, yang seharusnya membuat kode Anda lebih mudah dipahami.

Bahasa pemrograman modern sering mendukung model pemrograman deklaratif. Misalnya, dalam C #, menggunakan Linq menghasilkan gaya deklaratif, karena Anda tidak mengatakan bagaimana mendapatkan apa yang Anda inginkan; Anda hanya mengatakan apa yang Anda inginkan.

Pemrograman OO lengkap benar-benar meninggalkan rasa tidak enak di mulut saya, namun sepertinya itulah yang SEMUA ORANG lain gunakan dengan ketat.

Bahasa modern sering merupakan bahasa multi-paradigma. Jarang ada orang yang menggunakan bahasa "murni". Banyak bahasa Fungsional mendukung objek dan efek samping. Bahasa yang dianggap berorientasi objek sering tidak memaksakan kendala bahwa segala sesuatu adalah objek.

Apa yang Anda maksud dengan OO lengkap? Saya tidak pernah bekerja pada kode OO "murni". Mungkin Anda bisa memberi kami beberapa hal spesifik yang tidak Anda sukai. Ilustrasi dari proyek sumber terbuka mungkin bisa membantu.

Pemrograman OO memberi kita banyak fitur untuk mendukung hal-hal seperti: abstraksi data, enkapsulasi, pengiriman pesan, modularitas, polimorfisme, dan pewarisan. Jika saya melihat basis kode yang tidak memanfaatkan itu, itu akan meninggalkan rasa tidak enak di mulut saya.

Jawaban singkat: ya.

Mengajar diri sendiri hampir semuanya baik.
Saring dengan akal sehat, saran bagus.

WRT belajar pemrograman profesional, ya.
Apa yang ada dalam pikiranmu?
Konferensi, seminar, sertifikasi, gelar?
Masing-masing memiliki biaya / manfaat.
Ketika ROI baik, jika Anda memiliki sumber daya, lakukanlah.

Timbang saran pada derajat dengan mempertimbangkan sumber: orang dengan / tanpa mereka memiliki kepentingan pribadi.
Bicaralah dengan setengah lusin masing-masing.

Apakah akademisi terisolasi dari industri? Sering.
Apakah gelar itu tidak berharga? Dari segi dolar, sulit untuk diperdebatkan.
Lulusan hampir selalu menghasilkan lebih banyak uang, tetapi hati-hati dengan pinjaman perguruan tinggi.

Pengetahuan-bijaksana? Mungkin.
Jika Anda membenci sekolah, Anda tidak akan mendapatkan lebih banyak dari yang Anda dapatkan.

Jika Anda merasa gelar adalah tujuan yang layak bagi Anda, itu mungkin saja.

Gali lebih dalam dan cari tahu tentang program studi, biaya, lingkungan. Pastikan Anda memiliki minat, komitmen, waktu, dan sumber daya. Anda mungkin pergi ke sekolah selama tiga belas tahun, jadi apa empat lainnya? Mereka akan menjadi yang paling mahal, dan orang utama yang akan Anda andalkan untuk membuat mereka yang paling berharga adalah Anda.

Biaya bisa sangat menakutkan, tetapi mereka hanya menceritakan sebagian dari cerita karena ada banyak hibah dan beasiswa untuk jasa, kebutuhan, dan seratus alasan lainnya.

Jika Anda pergi, pilih ahli dan tunas pintar.

Pertanyaan Kedua - Bisakah saya menggunakan gaya saya sendiri?

Anda punya dua pertanyaan.

Yang pertama ada di judul Anda. Silakan lihat jawaban saya sebelumnya.

Yang kedua dirinci dalam sekitar lima paragraf di mana Anda mencirikan bagaimana gaya Anda berbeda dari gaya profesional dengan poin-poin di bawah ini:

• 100% belajar sendiri.
• Berbeda dalam teknik dan organisasi.
• Perpaduan fungsional dan berorientasi objek.
• Tidak terlalu rumit.
• Banyak penutupan.
• Beberapa komentar.
• Tidak ada tes unit.
• Sedikit garis bawah.
• Tidak ada MVC.
• Tidak ada backbone.js.
• Tidak ada aplikasi templat.

Ringkasnya, saya pikir Anda bertanya apakah boleh menggunakan pendekatan Frank Sinatra - "Saya melakukannya dengan cara saya." Saya merasakan ambivalensi ketika Anda memanggil kode profesional orang lain, tetapi Anda tidak setuju dengannya. Gaya adalah masalah pribadi yang lengket, dan perdebatan tentang apa kode yang baik itu tidak ada habisnya dan sering kali buang-buang waktu. Beberapa masalah mungkin lebih mudah jika grup Anda menggunakan konvensi pengkodean tertulis. Silakan periksa:

http://en.wikipedia.org/wiki/Coding_conventions

Ada etiket untuk membunuh kode orang lain, dan itu adalah hal lain yang harus Anda kerjakan dengan tim Anda. Kenakan kulit Anda yang tebal dan harap kulitnya tidak terlalu brutal, tetapi apa pun yang Anda lakukan, jangan pergi berperang.

Anda berkomentar tentang kecemasan tentang orang lain melihat kode Anda. Bersiaplah karena mereka tidak hanya akan melihatnya, tetapi mereka akan menulis ulang dan memberi tahu Anda apa yang salah dengan gaya Anda. Rekan kerja Anda mungkin fleksibel atau kaku. Apa pun yang terjadi, saya sarankan Anda tidak menulis ulang kode mereka untuk gaya atau membuat setiap poin gaya negosiasi.

Alasan untuk memiliki kode yang seragam (dan pelatihan yang seragam) adalah untuk meningkatkan kecepatan dan produktivitas pengembangan, dan di suatu tempat, melembagakan pembelajaran praktik terbaik. Masalah seperti camelCase atau use_underbars bisa terlihat sepele dan remeh, tetapi ada manfaatnya untuk konsistensi.

Harap terbuka untuk pengujian unit dan pengembangan yang didorong oleh pengujian. Ketika Anda sendirian, bukan bagian dari melakukan proyek untuk mendapatkan bayaran, itu lebih seperti hobi. Barang-barang Anda tidak perlu cocok dengan apa yang dilakukan orang lain. Jika kode Anda rusak, bukan masalah besar. Tetapi ketika Anda terlibat dengan tim, kode yang Anda tulis dapat mempengaruhi seluruh tim, terutama jika sampai ke pelanggan.

Demikian pula, jika tim Anda menggunakan MVC, harap pelajari tentangnya, semoga dari sumber yang sama yang mereka rujuk. Metode program penataan dapat membuat perbedaan besar seperti yang telah ditunjukkan oleh eksperimen. Sekali lagi, ambil contoh dan kepemimpinan dari tim Anda.

Jika tim Anda menggunakan backbone.js, Anda juga menggunakannya. Tim Anda seperti bebek yang terbang dalam formasi. Berbaris bersama membantu mereka mengeluarkan lebih sedikit energi, membuat mereka lebih aman, dan membantu mereka mencapai tujuan yang lebih efektif. Analogi ini rusak jika Anda mendorongnya terlalu banyak, tetapi ada keuntungan besar menggunakan alat, teknik, dan penyejajaran di belakang keputusan tim.

Saran yang diberikan cukup berguna, tetapi saya mencoba mengingat bahwa tujuan utama saya adalah membuat 'perangkat lunak yang berfungsi' yang berguna bagi pengguna saya. Audiens saya biasanya BUKAN sekelompok pemrogram - mereka adalah pebisnis yang bersedia membayar uang untuk solusi otomatis (Pengguna tidak peduli tentang OO Metodologi, Kerangka Kerja, Tes Unit, komentar kode, dll. Jadi jangan terlalu menutup telepon.)

Saya telah menemukan cita-cita Agile Manifesto berguna dalam karir saya (www.agilemanifesto.org)

• Individu dan interaksi atas proses dan alat
• Bekerja dengan perangkat lunak melalui dokumentasi yang komprehensif
• Kolaborasi pelanggan atas negosiasi kontrak
• Menanggapi perubahan setelah mengikuti rencana

Saya sepenuhnya berhubungan dengan pertanyaan ini. Saya memiliki perasaan yang persis sama dan latar belakang yang sangat mirip (tetapi tidak persis sama). Saya seharusnya dilatih secara profesional (atau lebih tepatnya secara akademis) jadi saya seharusnya tahu tentang pemrograman OO dll. Pemrograman bukan topik utama saya tetapi saya harus melakukannya. Saya belajar OO di beberapa mata kuliah saya dan sama sekali tidak mengerti alasan d'etre. Infact, satu-satunya saat saya memahami OO adalah ketika saya melakukan pekerjaan komersial dan dipaksa oleh dua mentor hebat.

Saya yakin profesor saya sama-sama brilian, tetapi Anda melihat manfaat nyata dalam prakteknya di lingkungan komersial vs pemrograman fungsional tetapi Anda tidak memiliki kesempatan untuk melihatnya dalam kursus yang dirancang untuk berjalan dan mengajar dan berakhir dalam beberapa bulan. . Saya belum memiliki kesempatan untuk bekerja pada struktur berbasis MVC tapi saya yakin itu akan sama yaitu saya ingin dapat mengambil konsep-konsep yang bekerja dari sebuah buku tetapi saya akan mengerti manfaatnya ketika saya melihatnya digunakan dalam sebuah lingkungan komersial. Dan saya sangat setuju dengan Anda, mengapa menggunakan OO dan MVC dan struktur rumit lainnya jika Anda dapat menyelesaikan masalah melalui cara yang lebih sederhana. Saran saya adalah jangan malu bekerja karena itu akan membuat Anda menghadapi situasi yang berbeda dan memungkinkan Anda untuk memahami hal-hal yang sama dalam cahaya yang berbeda.

Tentu saya belajar sintaks dan konsep dalam latar belakang akademis saya tetapi di dunia komersial di mana saya mulai belajar program.