Apakah mengembangkan perangkat lunak meningkatkan IQ?

Ya, perangkat lunak pemrograman dapat meningkatkan sebagian IQ Anda, karena secara langsung bermanfaat bagi kecerdasan logis-matematis dan kreatif, yang dievaluasi dalam tes IQ.

Namun, penting untuk diingat bahwa mengembangkan perangkat lunak akan mendukung kemampuan kognitif kita selama mereka dibina dalam lingkungan yang praktik yang baik dan pembelajaran berkelanjutan.

• 1.- Praktik Pengembangan Perangkat Lunak yang Baik yang Mempengaruhi Cara Berpikir Anda
• 1.1.- Simplicity
• 1.1.1.- Mengapa komputer crash terus menerus?
• 1.1.2.- Apa itu programmer yang buruk?
• 1.1.3.- Bagaimana menjadi programmer yang baik?
• 1.1.4.- Apakah lebih sulit untuk memprogram dengan cara yang disederhanakan?
• 1.2.- Tes
• 1.2.1.- Kesalahan komputer terjadi karena tidak adanya atau salah penggunaan tes perangkat lunak
• 1.2.1.1.- Kegagalan radar pendeteksi rudal
• 1.2.1.2.- Penghancuran Mariner I
• 1.2.1.3.- Therac-25, akselerator linier radioterapi
• 1.2.1.4.- Kapal Yorktown (CG-48) dan pembagiannya dengan nol
• 1.2.1.5.- Prosesor Intel Pentium dengan kesalahan split
• 1.2.2.- Contoh perangkat lunak yang mendekati kesempurnaan
• 1.2.3.- Bagaimana lanskap pengujian perangkat lunak saat ini?
• 1.2.3.1.- Kesalahan dan Inkonsistensi Pengujian Perangkat Lunak Hari Ini
• 1.2.3.2.- Pengembangan formal sebagai solusi yang diusulkan untuk pengujian perangkat lunak yang tidak konsisten
• 2.- Bagaimana pembelajaran berkelanjutan bermanfaat bagi otak kita?
• 2.1.- Kecerdasan didasarkan pada efisiensi saraf - Erhan Genç
• 2.2.- Bagaimana pemrograman memengaruhi kemampuan mental kita?
• 2.2.1.- Alat yang kita gunakan untuk memprogram mempengaruhi model mental kita
• 2.2.1.1.- Mengapa sektor IT menjadi salah satu yang paling direkomendasikan di tahun 2021?
• 2.2.2.- Itu sehat untuk otak
• 2.2.3.- Saat memprogram, Anda merangsang hingga 5 area otak Anda.

Praktik Pengembangan Perangkat Lunak yang Baik yang Mempengaruhi Cara Berpikir Anda

Ketika kami sudah memiliki pengalaman mengembangkan proyek perangkat lunak, kami telah membangun model mental tentang proyek perangkat lunak yang ideal. Tetapi, cara mana yang harus ditempuh untuk mengembangkan proyek perangkat lunak dengan benar?

Mungkin kelihatannya tidak terlalu rumit, karena saat ini kita bisa menemukan banyak informasi di internet tentang metodologi untuk pengembangan proyek, seperti SCRUM atau Extreme Programming. Keduanya memberi kami pedoman yang harus kami ikuti selama siklus pengembangan proyek, untuk menjamin organisasi, observasi, estimasi waktu dan/atau kerjasama tim.

Dari sudut pandang kami:

Menjadi terorganisir (menjadi sangat produktif) bisa jauh lebih sulit daripada belajar memprogram (bagi yang baru memulai), atau menguasai teknologi baru, karena yang paling sulit adalah mengembangkan proyek secara terstruktur, tepat dan di atas segalanya, cara mudah untuk membaca.

Albert Einstein pernah berkata:

Jika Anda tidak dapat menjelaskannya secara sederhana, Anda belum cukup memahaminya. Albert Einstein

Ini berlaku untuk bidang pembelajaran apa pun, misalnya, khususnya dalam pengembangan perangkat lunak, jika kami tidak dapat menyederhanakan kode kami, dan mengaturnya sedemikian rupa sehingga pihak ketiga dapat memahami proyek kami, kita tidak melakukannya dengan baik.

Dalam pengertian ini, melalui latihan, kita harus mencapai membentuk cara kita berpikir dan melakukan sesuatu. Selain itu, pertimbangkan pedoman dan pedoman yang disediakan oleh kerangka kerja yang berbeda, metodologi dan/atau rekomendasi para ahli yang diterapkan pada proyek kami. Namun, tidak disarankan atau tidak efisien untuk mengikuti pedoman seperti itu pada surat itu, karena kita harus fleksibel dan tidak kaku.

Selanjutnya, saya akan menjelaskan 2 praktik pengembangan perangkat lunak yang baik yang harus kamu perhitungkan ketika menjalankan proyek Anda dan saya yakin pada akhirnya akan mengubah cara berpikir Anda.

Kesederhanaan

Buat kode Anda sesederhana mungkin!

Bukan berita untuk mengatakan itu salah satu masalah terbesar dalam komputasi adalah kompleksitas. Karena itu, kesederhanaan mungkin adalah kualitas yang paling penting dan dihargai di dunia perangkat lunak.

Seiring waktu, komputer telah menjadi sangat diperlukan dalam kehidupan kita, dan telah menyebabkan perubahan yang sangat penting dalam masyarakat. Singkatnya, komputer berguna karena memungkinkan kita melakukan lebih banyak dengan lebih sedikit, yaitu melakukan banyak tugas dengan menggunakan lebih sedikit sumber daya manusia.

Mari kita bayangkan bahwa seseorang ingin melakukan semua operasi yang dilakukan komputer selama setahun. Mungkin, itu akan memakan waktu bertahun-tahun yang tersisa dari hidupnya, dan itulah nilai sebenarnya dari sebuah komputer adalah kecepatan dan akurasinya. Dan itu bagus!

Namun, itu tidak bisa begitu sempurna, karena komputer memiliki kelemahan utama: mereka selalu memiliki kekurangan. Mungkin kita belum mengetahui berapa kali mereka biasanya memiliki cacat perangkat lunak. Jika sesuatu yang sering digunakan sama rusaknya dengan komputer, saya yakin kita akan menyingkirkannya sekarang.

Sebagian besar, jika tidak semua, orang yang saya kenal mengalami setidaknya 1 kerusakan per minggu, jika tidak lebih. Saya dapat mengatakan bahwa setidaknya sekali seminggu saya telah mengalami semacam kegagalan atau saya mengetahui bahwa seorang teman atau Rekan kerja telah mengalami hal yang sama, yaitu selama kurang lebih 10 tahun.

Jika kita hitung, ada 480 bentuk kerusakan yang berbeda hanya dalam pengalaman saya. Dan itu tidak keren.

Mengapa komputer crash terus menerus?

Ketika datang ke perangkat lunak, hanya ada satu alasan: programmer yang buruk.

Sekitar 5 tahun yang lalu saya curiga bahwa alasannya adalah programmer yang buruk; Namun, saya tidak terlalu yakin. Sekarang, dengan beberapa tahun pengalaman di bidang IT dan telah berkonsultasi dengan banyak ahli melalui publikasi mereka, saya tidak lagi ragu.

Saya sepenuhnya dapat mengatakan bahwa programmer yang buruk harus disalahkan atas kegagalan komputer yang tak terhitung jumlahnya.

Apa itu programmer yang buruk?

Tampaknya agak tidak adil untuk menyalahkan programmer perangkat lunak, terlebih lagi ketika sebagian besar orang yang saya kenal berdedikasi untuk pengembangan perangkat lunak tingkat tinggi adalah para profesional yang memiliki pemikiran logis yang cukup berkembang.

Jika sebagian besar programmer adalah orang yang cukup logis, mengapa ada perangkat lunak dengan begitu banyak bug? Alasan utama kesalahan komputer adalah KOMPLEKSITAS.

Membangun komputer mungkin adalah proses paling rumit yang saya ketahui, karena untuk setiap detik yang berlalu, jutaan tugas dapat dieksekusi. Selain itu, ia memiliki ribuan bagian yang harus bekerja secara sinkron. Sistem operasi yang digunakan komputer sendiri terdiri dari puluhan juta baris kode. Hanya Windows 10 yang memiliki lebih dari 4 juta file dan lebih dari setengah juta folder. Buktinya adalah tangkapan berikut ini:

Untuk memberi Anda ide yang lebih lengkap, di bawah ini saya merinci jumlah baris kode per sistem operasi:

Sistem operasi	Baris kode
Linux 3.1 Kernel	15 jutaan
Windows XP	40 jutaan
Windows 7	40 jutaan
Windows Vista	50 jutaan
Debian 5.0 (base code)	67 jutaan
Mac OS X «Lion»	85 jutaan

Saya meninggalkan Anda informasi tambahan:

Facebook memiliki sekitar 61 juta baris kode dan Google memiliki sekitar 2 miliar baris kode. Tentu saja, banyaknya layanan yang ditawarkan oleh Google membenarkannya.

Perangkat lunak tempat komputer bekerja sangat kompleks sehingga mungkin tidak ada orang yang dapat memahami kodenya secara keseluruhan.

Oleh karena itu, pemrograman harus ada dalam lingkungan di mana ia berusaha untuk mengurangi kompleksitas dan dengan demikian mencapai kesederhanaan. Dengan cara ini, kami memastikan bahwa setiap programmer tanpa bakat luar biasa memiliki kemampuan untuk terus mengerjakan suatu aplikasi. Jika tidak, kode tersebut dapat mencapai tingkat kerumitan yang sedemikian tinggi sehingga hampir tidak mungkin untuk mengerjakannya.

Singkatnya, itulah yang dimaksud dengan pemrograman: "Kurangi kerumitan menjadi kesederhanaan."

Bagaimana menjadi programmer yang baik?

Seorang programmer yang baik menciptakan hal-hal yang mudah dipahami, dipelihara, dan mudah ditemukan bug. Tapi, jangan bingung kesederhanaan dengan lebih sedikit baris kode atau tidak lagi menggunakan teknologi modern. Terkadang menyederhanakan kode Anda dapat meningkatkan baris kode Anda, pastikan untuk selalu mendokumentasikannya.

Secara umum, teknologi yang lebih maju atau modern secara alami cenderung ke arah kesederhanaan. Anda hanya perlu mempelajari cara menggunakannya dengan benar, yang seringkali merupakan tantangan.

Apakah lebih sulit untuk memprogram dengan cara yang disederhanakan?

Secara umum, kami berpikir bahwa pemrograman dengan cara yang disederhanakan akan membutuhkan lebih banyak waktu daripada melakukannya dengan cepat. Misalnya, ketika kita harus menyelesaikan beberapa tugas pekerjaan kita, biasanya kita berusaha melakukannya dengan cepat, tanpa berhenti untuk berpikir dan merencanakan. Kami tidak bisa lebih salah!

Lebih efisien menghabiskan lebih banyak waktu memikirkan masalah untuk mencari pemahaman yang maksimal dan dengan cara ini dapat mengusulkan solusi yang disederhanakan, daripada mulai menulis solusi dengan cepat dan kemudian berhenti untuk menyadari bahwa implementasi menjadi kompleks yang tidak perlu.

Anda hanya perlu melihat sekeliling Anda dan menyadari masalah besar yang menjadi KOMPLEKSITAS dalam program perangkat lunak.

Ada banyak aplikasi yang menjadi mandek ketika mencoba menambahkan fungsionalitas baru ke yang mengerikan, monster besar dan kompleks dari kode yang telah mereka buat.

Jika Anda ingin tahu lebih banyak tentang dasar-dasar dan cara-cara pemrograman yang disederhanakan, saya sarankan membaca buku berikut. Aku menyukainya!

Tes

Selalu jalankan tes. Mereka tidak opsional!

Pada kenyataannya, mereka seharusnya tidak pernah menjadi pilihan, namun, banyak programmer masih mengembangkan aplikasi tanpa menggunakan semua jenis pengujian perangkat lunak, karena kesalahan kode dilaporkan oleh pelanggan akhir. Ini biasanya terjadi pada freelancer rata-rata.

Pemrograman tanpa pengujian seperti mengemudi tanpa sabuk pengaman atau melakukan aksi trapeze tanpa jaring pengaman. Saat ini, praktik yang baik untuk selalu menguji perangkat lunak masih harus diadopsi.

Mari kita tinjau beberapa anteseden yang terjadi karena tidak adanya atau salah penggunaan tes perangkat lunak yang telah menyebabkan kerugian ekonomi jutaan dolar dan dalam beberapa kasus telah merenggut nyawa puluhan orang.

Kesalahan komputer terjadi karena tidak adanya atau salah penggunaan tes perangkat lunak

Saya yakin bahwa peristiwa yang disebutkan di bawah ini akan membuat Anda merenungkan dan memberikan lebih banyak kepentingan untuk pengujian perangkat lunak.

Kegagalan radar pendeteksi rudal.

Itu terjadi pada tahun 1983 ketika sistem peringatan deteksi rudal Uni Soviet melaporkan bahwa Amerika Serikat telah meluncurkan 5 rudal dan mereka sedang berlangsung.

Untungnya, orang yang bertanggung jawab berdasarkan intuisi dan / atau kriteria tidak memerintahkan serangan langsung sebagai tanggapan, karena mereka menganggap serangan itu aneh karena di luar konteks dan juga karena jumlah rudal, karena mereka bukan yang biasa digunakan untuk serangan mendadak.

Beberapa jam kemudian, dipastikan bahwa semuanya disebabkan oleh kesalahan sistem radar rudal. Kesalahan agak sulit dideteksi pada saat itu, karena sistem mengacaukan pantulan matahari di awan dalam posisi tertentu dengan rudal. Untuk sedikit dan akhirnya memulai Perang Dunia Ketiga. Namun, itu mungkin telah dihindari setelah melakukan pekerjaan menyeluruh:

• Studi lingkungan di mana sistem peringatan akan dikerahkan
, dan
• injeksi semua jenis variabel input yang dapat mempengaruhi sistem.

Keduanya adalah praktik yang merupakan bagian dari pengujian perangkat lunak.

Penghancuran Mariner I

Terjadi pada tahun 1962 dan menyebabkan kerugian sekitar $18,5 juta, Mariner I adalah misi pertama dalam program Mariner yang mencoba terbang di atas Venus, sayangnya tidak berhasil.

293 detik setelah lepas landas, a bug perangkat lunak ditemukan. Bug ini mengalihkan lintasannya. Beberapa detik kemudian sebuah perintah harus dikirim untuk menghancurkannya, dan dengan demikian mencegah kejatuhannya dari menyebabkan kerusakan lebih lanjut.

Kesalahan itu kemudian ditentukan: Rumus dalam kode yang diprogram secara tidak benar.

Therac-25, akselerator linier radioterapi

Anda akan bertanya pada diri sendiri, apa itu akselerator linier radioterapi? Akselerator linier adalah mesin yang memancarkan sinar X-ray yang ditujukan ke tumor dari sudut yang berbeda. Hal yang hebat adalah bahwa perangkat ini dapat menyesuaikan sinar-X agar sesuai dengan bentuk tumor tanpa mempengaruhi area sekitarnya.

Antara Juni 1985 dan Januari 1987, Therac-25 diproduksi oleh AECL (Atomic Energy of Canada Limited) adalah peserta dalam setidaknya 6 kecelakaan dan 3 kematian karena menerima overdosis radiasi.

Setelah penyelidikan, disimpulkan bahwa penyebab utama kecelakaan Therac-25 adalah sebagai berikut::

• Praktik pengembangan perangkat lunak yang buruk.
• Analisis kebutuhan yang buruk.
• Desain perangkat lunak yang buruk.

Dan jika itu tidak cukup, perangkat lunak yang menjalankan Therac-25 dikembangkan dengan cara yang hampir tidak mungkin untuk mengidentifikasi dan memperbaiki bug atau kesalahan secara otomatis.

Penyebab lain yang ditemukan:

• AECL tidak pernah mengirim entitas independen untuk meninjau kode sumber.
• Tidak ada fungsionalitas yang terkait dengan manajemen risiko yang dipertimbangkan dalam desain.
• Sistem tidak mengizinkan untuk memverifikasi pengoperasian sensor yang benar.
• Ada variabel bendera yang mengubah nilainya alih-alih memegang nilai konstan.
• Variabel "class3" meluap.
• Diantara yang lain.

Kapal Yorktown (CG-48) dan pembagiannya dengan nol

Percaya atau tidak, Kapal Yorktown, kapal perang yang memenangkan banyak penghargaan untuk keunggulannya dalam pertempuran dan terutama untuk peralatan teknologinya, akhirnya ditarik karena kesalahan perangkat lunak.

Pada bulan September 1997, seorang anggota kru memasukkan nol di bidang basis data yang menyebabkan sistem menjalankan pembagian dengan nol secara internal, yang menyebabkan bug, akhirnya menghasilkan buffer overflow dan akhirnya kegagalan pada sistem propulsi kapal.

Prosesor Intel Pentium dengan kesalahan split

Pada tahun 1993, Intel merilis prosesor baru dengan salah perhitungan. Meskipun mereka sangat sulit untuk diperhatikan, karena untuk dapat melihat kesalahan Anda harus menjalankan operasi yang membutuhkan hasil yang cukup tepat.

Meskipun demikian, Intel mengalami kerugian sekitar $ 350 juta, belum termasuk kerusakan pada citranya yang hampir tidak dapat diukur.

5 kasus yang baru saja saya sebutkan kepada Anda hanyalah beberapa dari kesalahan komputer yang tak terhitung jumlahnya yang sayangnya mengorbankan nyawa manusia dan merupakan bukti nyata kebutuhan untuk menulis perangkat lunak yang benar.

Insinyur perangkat lunak, serta insinyur struktural atau insinyur sipil, harus dapat menunjukkan dengan metode, keandalan dan pemenuhan fungsi yang diperlukan.

Seperti yang mungkin Anda perhatikan, pengujian adalah bagian mendasar dari proyek apa pun. Mereka tidak opsional!

Menurut Ilene Burnstein dalam bukunya: “Pengujian Perangkat Lunak Praktis”, pengujian perangkat lunak memiliki 3 proses utama:

• Pengembangan kasus uji
• Eksekusi kasus uji
• Analisis hasil

Jika Anda tidak meluangkan waktu untuk membuat kasus pengujian, Anda tidak melakukannya dengan benar. Penting untuk membangun kasus uji dengan berbagai skenario yang mensimulasikan sebanyak mungkin kasus. Untuk nasib buruk kami, tidak mungkin untuk mensimulasikan 100% dari skenario.

Baik kata Edsger Dijkstra:

Tes dapat menunjukkan adanya kesalahan dalam suatu program, tetapi bukan ketidakhadirannya Edsger Dijkstra (Hadiah Turing pada tahun 1972)

Tetapi seperti halnya banyak kasus kesalahan komputer yang disebabkan oleh pelaksanaan tes yang salah, ada juga kisah sukses yang layak mendapatkan hadiah.

Contoh perangkat lunak yang mendekati kesempurnaan

Saat ini dimungkinkan untuk mengembangkan perangkat lunak yang dapat diandalkan seperti produk lainnya, terlebih lagi dengan peningkatan kapasitas otomatisasi.

Jalur 14 metro Paris sepenuhnya otomatis. Kereta tidak memiliki pengemudi dan dijalankan oleh perangkat lunak. Jalur kereta api ini mulai beroperasi pada tahun 1998.

Meskipun benar, kesempurnaannya tidak dapat dijamin, puluhan tahun telah berlalu dan tidak ada kesalahan yang terdeteksi, berkat pekerjaan pengujian yang menyeluruh, yang akhirnya mengeksekusi sekitar 86 ribu instruksi dalam proses pengujian.

Secara umum, proses pengujian yang ketat yang dapat menjamin perangkat lunak tanpa cacat diperlukan di beberapa negara hanya untuk sistem yang dapat menyebabkan kerugian manusia.

Sebagian besar perusahaan perangkat lunak menolak untuk menerapkan proses pengujian yang ketat seperti itu karena biayanya yang tinggi bahwa ini menyiratkan dan juga karena sulit untuk menemukan profesional yang berdedikasi untuk pengujian dengan pelatihan dan pengalaman yang memadai untuk tugas seperti itu, karena implementasi proses pengujian Perangkat Lunak dapat menghabiskan biaya yang sama atau lebih dari pengembangan perangkat lunak itu sendiri.

Tentu saja, "Anda tidak belajar sampai giliran Anda", seperti halnya INTEL, yang harus merugi sekitar $350 juta karena kesalahan perhitungan pada software prosesornya. Kesalahan yang membawanya menjadi salah satu perusahaan IT dengan anggaran tertinggi untuk riset pengujian software.

Bagaimana lanskap pengujian perangkat lunak saat ini?

Jalan untuk mengembangkan proyek perangkat lunak terdiri dari 3 tahap yang terdefinisi dengan baik:

• spesifikasi
• Desain dan pengkodean
• Validasi

Pada tahap validasi, para insinyur yang bertanggung jawab memastikan bahwa perangkat lunak sesuai dengan apa yang direncanakan dalam spesifikasi, cara mereka melakukannya adalah dengan "pengujian".

Setelah perangkat lunak divalidasi, diasumsikan bahwa ia memenuhi semua spesifikasi dan siklus validasi diulang untuk terakhir kalinya untuk memverifikasi validasi yang benar.

Apa yang dijelaskan di atas memiliki masalah besar inkonsistensi, saya akan menjelaskannya kepada Anda di bawah ini:

Kesalahan dan Inkonsistensi Pengujian Perangkat Lunak Hari Ini

Masalah paling penting dengan "pengujian" metode validasi saat ini adalah tidak memastikan bahwa perangkat lunak sesuai dengan apa yang ditunjukkan dalam spesifikasi. Hal ini karena penyusunan spesifikasi dilakukan dalam bahasa alami, dengan istilah yang akan selalu cenderung pada interpretasi individu, yang menghasilkan ambiguitas yang pasti akan diperhatikan di akhir proyek.

Masalah kedua adalah Anda tidak pernah bisa menguji setiap kemungkinan kasus. Misalkan kita memiliki perangkat lunak kecil yang:

• menerima nomor apa pun sebagai input,
• tambahkan 10 dan
• mengembalikan nilai jumlah sebagai hasilnya.

Tidak mungkin untuk menguji semua kasus yang mungkin karena data input tidak terbatas. Itulah sebabnya pengujian perangkat lunak hanya dijalankan pada sampel kasus yang dipilih, yang terkadang merupakan sampel yang sangat kecil. Alasan untuk praktik buruk ini dibenarkan oleh kendala keuangan dan waktu. Kesimpulannya, kami tidak dapat mengatakan bahwa suatu perangkat lunak benar setelah menyelesaikan fase pengujian, karena tidak ada cukup bukti untuk klaim tersebut.

Jika kita mencoba bersikap logis (sebagaimana seharusnya jika kita berdedikasi pada bidang komputasi), dengan menegaskan bahwa suatu perangkat lunak benar setelah menyelesaikan fase pengujian dan tidak menemukan kesalahan apa pun, kami mengalami apa yang disebut: “Kekeliruan panggilan untuk ketidaktahuan”.

Dalam logika, sebuah argumen ad bodohiam, atau argumentum ad bodohiam, juga dikenal sebagai ajakan untuk kebodohan, adalah kekeliruan yang terdiri dari mempertahankan kebenaran (atau kepalsuan) dari proposisi yang mengklaim bahwa tidak ada bukti yang bertentangan, atau mengklaim ketidakmampuan atau penolakan lawan untuk memberikan bukti yang meyakinkan sebaliknya. Ketidaksabaran dengan ambiguitas ini sering dikritik dengan ungkapan: "tidak adanya bukti bukanlah bukti ketidakhadiran" yaitu, kekeliruan ini dilakukan ketika kebenaran atau kepalsuan suatu proposisi disimpulkan berdasarkan ketidaktahuan yang ada tentangnya. Kekeliruan panggilan untuk ketidaktahuan

Seperti yang mungkin Anda perhatikan, kami membuat banyak kesalahan saat menerapkan pengujian perangkat lunak dengan cara konvensional dan berkali-kali kami tidak mengetahui biaya yang ditimbulkannya.

Sekedar memberi gambaran:

• Metode konvensional pengujian perangkat lunak melibatkan mendeteksi cacat pada perangkat lunak.
• Selanjutnya, fase debugging dimasukkan, yaitu meninjau kode untuk memahami penyebab kegagalan dan akhirnya memperbaiki cacat perangkat lunak.
• Bekerja dengan cara ini, rata-rata, programmer menghabiskan 49,9% dari waktu mereka untuk men-debug kesalahan mereka sendiri.
• Ini menyiratkan pengeluaran dunia sebesar 156 miliar dolar per tahun.

Pengembangan formal sebagai solusi yang diusulkan untuk pengujian perangkat lunak yang tidak konsisten

Seperti yang telah kita lihat, salah satu masalah utama adalah ambiguitas spesifikasi yang, jika diungkapkan dalam bahasa alami, kurang akurat dan logika matematika yang masuk akal. Salah satu solusinya adalah menggunakan bahasa formal, di mana tidak ada ruang untuk ambiguitas.

Dengan menggunakan metode formal untuk pengembangan proyek perangkat lunak kami, kepastian sifat dan/atau fungsionalitas perangkat lunak dijamin melalui deduksi, dengan kata lain, melalui matematika (p -> q).

Metode formal ini membutuhkan lebih banyak waktu dan anggaran untuk persiapannya, karena lebih banyak presisi diperlukan dalam elaborasi spesifikasi, yang pada gilirannya harus dibersihkan dari ambiguitas sehingga ketika membuat kode dapat menunjukkan keandalannya berdasarkan spesifikasinya.

Tampaknya cukup jauh dari kenyataan untuk mencapai batas permintaan untuk membuat perangkat lunak berkualitas. Namun, saat ini ada perusahaan yang mendasarkan sistem mereka pada pengembangan formal, biasanya dengan perusahaan yang didedikasikan untuk area kritis di mana kesalahan kecil dapat berarti hilangnya nyawa manusia secara instan.

Namun, dalam skala kecil, tingkat permintaan seperti itu tidak menguntungkan; minimal kita harus mematuhi tes konvensional.

Di bawah ini saya membagikan serangkaian publikasi praktik baik yang tidak boleh Anda lewatkan jika Anda ingin mengembangkan proyek yang berkualitas.

Bagaimana pembelajaran berkelanjutan bermanfaat bagi otak kita?

Belajar itu seperti bahan bakar untuk otak kita.

Di perguruan tinggi atau universitas kami telah berkorban terus belajar dan tidak ada yang cukup, karena setiap menit yang berlalu informasi baru keluar terlepas dari karir yang telah Anda pelajari.

Akan selalu ada hal baru untuk dipelajari.

Sesuatu yang perlu diingat adalah bahwa ketika kita belajar, otak kita dipengaruhi oleh perubahan struktur saraf.

Penelitian modern telah menunjukkan bahwa otak memiliki kemampuan untuk berubah dan berubah bentuk secara permanen (keliatan), dan tidak hanya pada anak-anak tetapi juga pada orang dewasa.

Perubahan di otak ini dapat disebabkan oleh: praktik yang baik dari pembelajaran berkelanjutan, merestrukturisasi koneksi sinaptik dan terkadang membuat yang baru.

Dahulu diyakini bahwa semakin besar atau berat otak seseorang, semakin cerdas otaknya. Namun, penelitian terbaru telah menentukan bahwa orang dengan IQ lebih tinggi memiliki jaringan saraf yang kurang padat tetapi pada saat yang sama jauh lebih terorganisir.

Untuk penelitian ini, IQ telah dihitung pada faktor-faktor berikut:

• Kapasitas analisis
• Kapasitas refleksi
• Penyelesaian masalah

Berikut adalah sedikit informasi lebih lanjut tentang penelitian yang dimaksud:

Kecerdasan didasarkan pada efisiensi saraf - Erhan Genç

Tim yang dipimpin oleh Erhan Genç menganalisis otak 259 pria dan wanita berusia antara 18 dan 40 tahun, dan dalam keadaan sehat, untuk mengukur dendrit di korteks serebral, yaitu perpanjangan sel saraf yang digunakan Sel untuk berkomunikasi satu sama lain dalam kinerja kecerdasan.

Sebelum penelitian, semua peserta menjalani tes IQ. Setelah mempelajari dendrit, ditentukan bahwa semakin tinggi IQ, semakin sedikit dendrit yang ada di korteks serebral.

Dengan kata lain, disimpulkan bahwa orang yang lebih pintar tidak hanya memiliki lebih banyak neuron tetapi juga memiliki lebih sedikit koneksi dendritik antar neuron. pada saat kognisi. Yang berarti mereka memiliki jaringan saraf yang kurang padat.

Studi divalidasi dengan sampel 500 orang dan kesimpulan yang sama tercapai.

Erhan Genç, penulis utama studi ini menyimpulkan:

Otak cerdas dicirikan oleh jaringan saraf yang tipis namun sangat efisien. Ini membantu mencapai tingkat pemikiran yang tinggi sambil meminimalkan aktivitas saraf. Erhan Genç

Bagaimana pemrograman memengaruhi kemampuan mental kita?

Seperti yang sudah saya sebutkan di paragraf sebelumnya, pemrograman mempengaruhi cara berpikir orang yang mempraktekkannya, dalam arti itu secara langsung mempengaruhi kita kemampuan mental.

Tapi dengan cara apa ia melakukannya? Ayo lihat.

Seorang programmer berpikir sangat berbeda dari yang lain, karena pada umumnya mereka cenderung lebih logis dan lebih rasional daripada rata-rata, walaupun belum tentu.

Karena kami memutuskan untuk belajar memprogram, kami harus memilih bahasa mana untuk memulai. Meskipun pilihan seperti itu tidak sepenuhnya benar, karena, secara umum, sebagian besar dari mereka yang mendedikasikan diri untuk dunia pengembangan perangkat lunak memilih bahasa pertama kami tanpa pengalaman atau telah mengalami dan praktis dipaksa untuk memulai dengan bahasa pemrograman yang dipaksakan. oleh seorang guru, baik di perguruan tinggi dan/atau universitas.

Namun, batasan seperti itu semakin jarang karena banyaknya informasi yang dapat kita temukan di internet dan insentif yang tinggi dan promosi pembelajaran otodidak.

Paradigma bahasa pemrograman telah membentuk banyak pikiran, dalam beberapa kasus dengan lebih banyak batasan daripada yang lain tergantung pada bahasa yang digunakan untuk memulai. Dengan ini saya tidak bermaksud bahwa bahasa pertama Anda mendefinisikan kesuksesan atau kegagalan Anda, tetapi maksud saya paradigma yang digunakan untuk memulai di dunia pemrograman menyisipkan pola dalam pemikiran kita.

Saya akan menyebutkan Anda di bawah ini 3 cara pemrograman memengaruhi otak Anda:

1. Alat yang kita gunakan untuk memprogram mempengaruhi model mental kita

Bahasa pemrograman yang kami mulai tidak lebih dari sebuah alat, yang disertai dengan paradigma dan idiom yang secara langsung mempengaruhi cara berpikir Anda. Bukan untuk apa-apa, Edsger

Dijkstra, salah satu pelopor berdirinya program terdistribusi mengatakan:

Alat yang kami gunakan memiliki pengaruh besar (dan licik) pada kami kebiasaan berpikir dan, oleh karena itu, dalam kami kemampuan berpikir. Edsger Dijkstra

Sekarang Anda tahu betapa pentingnya bahasa pemrograman yang kita mulai dan secara umum semua set alat yang kita gunakan saat pemrograman, saya menyarankan Anda bahwa hal pertama yang Anda pertimbangkan ketika memilih bahasa pemrograman pertama Anda adalah kenyamanan Anda.

Jika Anda baru memulai, jangan terbawa oleh uang. Memang benar ada bahasa pemrograman yang bayarannya lebih baik daripada yang lain, tetapi uang tidak boleh menjadi tujuan Anda. Jika demikian, saya dapat menyarankan Anda untuk memulai pemrograman dengan COBOL, PASCAL, FORTRAN, bahasa yang memiliki dokumentasi yang sangat sedikit dan saat ini sangat sedikit yang mempraktekkannya, itulah sebabnya mereka dibayar dengan sangat baik di tempat yang diperlukan.

Pada kenyataannya, mendedikasikan diri Anda untuk pengembangan perangkat lunak tidak hanya membawa manfaat bagi kebiasaan berpikir dan keterampilan kognitif Anda, tetapi juga dapat memastikan masa depan ekonomi yang lebih stabil, karena ini adalah sektor yang dibayar dengan sangat baik yang saat ini sedang berkembang.

Hari ini adalah waktu terbaik untuk memulai. Mari kita lihat alasannya:

Mengapa sektor IT menjadi salah satu yang paling direkomendasikan di tahun 2021?

Menurut Komisi Ekonomi untuk Amerika Latin dan Karibia (ECLAC), negara-negara Amerika Latin akan mulai tumbuh setelah resesi ekonomi tahun 2020.

Pertumbuhan sebesar 3,7% diperkirakan untuk tahun 2021, di mana protagonis utama adalah mereka yang berdedikasi pada dunia digital.

2. Itu sehat untuk otak

Seperti yang telah kami sebutkan, belajar memiliki efek positif pada otak. Dalam pengertian ini, pemrograman dianggap sebagai latihan mental yang secara langsung menguntungkan otak.

Mari kita tinjau beberapa latar belakang yang menegaskan manfaat pemrograman untuk kesehatan otak:

Pada tahun 1991 sebuah penyelidikan mempelajari efek pemrograman komputer pada hasil kognitif dan menentukan bahwa: siswa di bidang terkait pemrograman mendapat skor 16 poin persentil lebih tinggi dari rata-rata pada tes IQ.

Studi lain yang lebih besar pada tahun 1999 akhirnya mengkonfirmasi bahwa aktivitas yang melibatkan intelektual berfungsi untuk melindungi individu dari penurunan kognitif.

Kemudian pada tahun 2009, sebuah penelitian menemukan bahwa orang yang terlibat dalam kegiatan yang merangsang otak di tahun-tahun berikutnya dapat menurunkan risiko mereka dan bahkan menunda timbulnya Alzheimer dan jenis demensia lainnya.

3. Saat memprogram, Anda merangsang hingga 5 area otak Anda

Pada tahun 2014 sebuah penelitian berjudul “Memahami Pemahaman Kode Sumber dengan Pencitraan Resonansi Magnetik Fungsional” menggunakan pemindaian pencitraan resonansi magnetik fungsional untuk mengamati aktivitas otak saat pemrogram mencoba bekerja dan memahami bit kode.

Disimpulkan bahwa 5 area otak terlibat:

• BA 6: Gyrus frontal tengah (Perhatian, bahasa, memori kerja)
• BA 21: Rata-rata temporal gyrus (pengambilan memori semantik)
• BA 40: Lobus parietal bawah (memori kerja)
• BA 44: Gyrus frontal inferior (memori kerja)
• BA 47: Gyrus frontal inferior (Bahasa, memori kerja)

Kita harus ingat bahwa peserta harus meninjau cuplikan kode 20 baris, yang bukan merupakan tantangan besar. Dan itulah sebabnya tidak ada aktivitas yang terdeteksi di area otak yang terkait dengan perhitungan matematis.

Apa yang bisa diperhatikan adalah intervensi yang tinggi dari bagian otak yang biasanya berhubungan dengan pemrosesan bahasa, memori dan perhatian.

Pemrograman adalah hal yang paling dekat dengan memiliki kekuatan super. Drew Houston, CEO Dropbox