├── README.md ├── android-development-guide.md ├── android-recommended-library.md ├── api-standard.md ├── daily-coordination.md ├── fabric-guide.md ├── ios-development-style-guide.md ├── mobile-development.md ├── programming-concepts.md ├── pull-request-workflow.md ├── quality-assurance.md ├── redmine-scrum.md ├── software-analysis.md └── web-development.md /README.md: -------------------------------------------------------------------------------- 1 | # Flipbox Tech Handbook 2 | -- 3 | 4 | ![Flipbox](https://puu.sh/xvxN7/17e722b4f6.png) 5 | 6 | Dokumen ini berisi penjelasan mengenai tata cara kerja, perangkat yang digunakan dan hal hal lain yang relevan dengan pekerjaan sehari hari yang dilakukan oleh tim pengembang di Flipbox. 7 | 8 | Dokumen ini terbagi ke dalam beberapa bagian utama 9 | 10 | - [Panduan dan konsep dasar _Programming_](https://github.com/flipboxstudio/tech-handbook/blob/develop/programming-concepts.md) 11 | 12 | Bagian ini berisi rangkuman dan referensi dasar dasar pemrograman yang wajib dipahami oleh seluruh tim teknis Flipbox. 13 | 14 | - [Penggunaan Redmine & tata cara SCRUM](https://github.com/flipboxstudio/tech-handbook/blob/develop/redmine-scrum.md) 15 | 16 | Bagian ini berisi tentang proses SCRUM yang berjalan di Flipbox, dan penerapannya di sistem kolaborasi yang digunakan ( Redmine ) 17 | 18 | - [Kolaborasi & Review menggunakan _Pull Request_](https://github.com/flipboxstudio/tech-handbook/blob/develop/pull-request-workflow.md) 19 | 20 | Bagian ini berisi tentang proses _Pull Request_ yang berjalan di Flipbox, tata cara dan kesepakatan yang berlaku. 21 | 22 | - [Panduan untuk _Web Developer_](https://github.com/flipboxstudio/tech-handbook/blob/develop/web-development.md) 23 | 24 | Bagian ini berisikan panduan untuk membuat kode baik, penjelasan arsitektur dan pustaka yang ada dan/atau digunakan di Flipbox. 25 | 26 | - [Panduan untuk _Mobile Developer_](https://github.com/flipboxstudio/tech-handbook/blob/develop/mobile-development.md) 27 | 28 | Bagian ini berisikan panduan untuk membuat kode baik, penjelasan arsitektur dan pustaka yang ada dan/atau digunakan di Flipbox. 29 | 30 | - [Panduan untuk _Quality Assurance_](https://github.com/flipboxstudio/tech-handbook/blob/develop/quality-assurance.md) 31 | 32 | Bagian ini berisikan panduan untuk melakukan testing dengan baik, deskripsi dokumen, proses dan kesepakatan yang berlaku di Flipbox. 33 | 34 | - [Panduan untuk _System Analyst_](https://github.com/flipboxstudio/tech-handbook/blob/develop/software-analysis.md) 35 | 36 | Bagian ini berisi tentang deskripsi dokumen analisis yang ada di Flipbox, proses dan kesepakatan yang berlaku di Flipbox. 37 | 38 | - [Koordinasi Harian : Izin ketidakhadiran, bekerja dari rumah dll](https://github.com/flipboxstudio/tech-handbook/blob/develop/daily-coordination.md) 39 | 40 | Bagian ini berisikan tata cara dan ketentuan izin, bekerja dari rumah ( WFH ) dan koordinas lain terkait kegiatan pengembangan di hari kerja. 41 | 42 | - [SAKA Employee Guideline](https://docs.google.com/document/d/1Xy8OcrtMUdJCehURhJr0Gdl0q6t_RkMpwDq6BS60U5s/edit#heading=h.nuwsz7jkx0ja) 43 | 44 | Tautan luar. Berisikan ketentuan umum untuk karyawan PT SAKA DIGITAL ARSANA ( Flipbox ) 45 | -------------------------------------------------------------------------------- /android-development-guide.md: -------------------------------------------------------------------------------- 1 | # Panduan Android Development (*MVVM Starter*) 2 | Berikut merupakan panduan dalam mengembangkan proyek android menggunakan [MVVM Starter](https://github.com/flipboxstudio/mvvm-starter). 3 | #### Konten: 4 | 1. Environment 5 | 2. Recommended Library 6 | 3. Packaging & Naming 7 | 4. App Flow 8 | --- 9 | ## 1. Environment 10 | Default environment & utility tools: 11 | - Android Studio 12 | - Minimal versi sdk 18 13 | - Target versi sdk 25 14 | - Zeplin 15 | - Marvel 16 | --- 17 | ## 2. Recommended Library 18 | Selain default library yang digunakan di mvvm starter, [Kumpulan library](https://github.com/flipboxstudio/tech-handbook/blob/develop/android-recommended-library.md) berikut mungkin akan digunakan tergantung dari desain & kebutuhan proyek. 19 | 20 | --- 21 | 22 | ## 3. Packaging & naming 23 | ### Packaging 24 | Berikut merupakan default package dalam mvvm starter. 25 | ``` 26 | Application file 27 | data/ 28 | - /events/ 29 | - /local/ 30 | - /contracts/ 31 | - /remote/ 32 | - /contracts/ 33 | - /retrofit/ 34 | models/ 35 | utils/ 36 | - /constants/ 37 | viewmodels/ 38 | - /inputs/ 39 | - /outputs/ 40 | view/ 41 | - /activities/ 42 | - /adapters/ 43 | - /customviews/ 44 | - /fragments/ 45 | ``` 46 | Package yang digunakan terdiri dari 4 package utama yakni: 47 | - **data**: berisi file yang berhubungan dengan proses pengambilan data (local/remote) 48 | - **models**: berisi file model (custom object) yang digunakan dalam proyek. 49 | - **utils**: berisi file utility penunjang proses. 50 | - **viewmodels**: berisi file view model yang digunakan sebagai penunjang data binding dalam proyek. 51 | - **view**: berisi file yang berhubungan dengan proses pengolahan, menampilkan data, & mengontrol alur aplikasi. 52 | 53 | Terdapat beberapa sub package yang digunakan dan masing-masing memiliki fungsi tersendiri, yakni: 54 | - **data/events**: berisi file yang digunakan sebagai event. 55 | - **data/local/**: berisi file yang digunakan untuk mengakses konten storage local. 56 | - **data/local/contracts/**: berisi file interface untuk mengakses storage local. 57 | - **data/remote/**: berisi file yang digunakan untuk mengakses konten di storage remote/server. 58 | - **data/remote/contracts/**: berisi file interface untuk mengakses storage remote/server. 59 | - **data/remote/retrofit/**: berisi file retrofit untuk network utility. 60 | - **utils/constants/**: berisi file yang menampung variable static untuk digunakan dalam proyek. 61 | - **viewmodels/inputs/**: berisi file interface setter/input untuk view model. 62 | - **viewmodels/outputs/**: berisi file interface getter/output untuk view model. 63 | - **view/activities/**: berisi file activity yang digunakan dalam proyek. 64 | - **view/adapters/**: berisi file adapter yang digunakan dalam proyek. 65 | - **view/customviews/**: berisi file object view yang dikustomisasi untuk keperluan proyek. 66 | - **view/fragments/**: berisi file fragment yang digunakan dalam proyek. 67 | 68 | ### Naming 69 | Masing - masing package memiliki aturan dalam penamaan file yang ada didalamnya untuk memudahkan identifikasi & kegunaan, yakni: 70 | - **data/**: `DataManager.java` (ex: `SyncDataManager.java`. 71 | - **data/events**: `Event.java` (ex: `LoginSuccessEvent.java`). 72 | - **data/local/**: `Storage.java` (ex: `AddressStorage.java`). 73 | - **data/local/contracts/**: `Contract.java` & penamaan metode crud ialah (Add, Get, Edit, Remove) (ex: `UserContract.java`). 74 | - **data/remote/**: `API.java` (ex: `AddressAPI.java`). 75 | - **data/remote/contracts/**: `Contract` & penamaan metode crud ialah (Create, Read, Update, Delete) (ex: `AddressContract.java`). 76 | - **viewmodels/**: `VM.java` (ex: `ProfileVM.java`). 77 | - **viewmodels/inputs/**: `Input.java` (ex: `OrderInput.java`). 78 | - **viewmodels/outputs/**: `Output.java` (ex: `OrderOutput.java`). 79 | - **view/activities/**: `Activity.java` (ex: `ProfileActivity.java`). 80 | - **view/adapters/**: `Adapter.java` (ex: `NewsListViewAdapter.java`). 81 | - **view/customviews/**: `Custom.java` (ex: `CustomTextView.java`). 82 | - **view/fragments/**: `Fragment.java` (ex: `LoginFragment.java`). 83 | 84 | Selain itu, dalam proyek terdapat file resource, berikut aturan penamaan untuk masing-masing file di resource. 85 | - **activity**: `activity_.xml` (ex: `activity_profile.xml`). 86 | - **fragment**: `fragment_.xml` (ex: `fragment_login.xml`). 87 | - **list item**: `cell__.xml` (ex: `cell_news_list.xml`). 88 | - **menu**: `menu_.xml` (ex: `menu_login.xml`). 89 | 90 | Untuk kasus file yang tak punya aturan penamaan, by default mengikuti aturan penamaan `.java/xml` atau default name yang diberikan. 91 | 92 | Selain penamaan file, penamaan variable & method juga memiliki aturan yakni: 93 | - **layout variable**: `_` (ex: `tv_person_name`), menggunakan lower case & underscore sebagai pemisah kata. 94 | - **class variable**: `` (ex: `tvPersonName`), menggunakan camelBack notation. 95 | - **class method**: `` (ex: `getPersonName`), menggunakan camelBack notation. 96 | 97 | Beberapa aturan lainnya yang perlu diperhatikan ialah: 98 | - Menggunakan code style dari [Flipbox](https://gist.github.com/sakadigital/41b4be80ab92234a48e0) (Automatic reformat & arrange code). 99 | - Jika nama terlalu panjang, bisa menggunakan akronim (ex: textView = tv). 100 | - Hindari nama yang kompleks & panjang. 101 | --- 102 | 103 | ## 4. App Flow 104 | Hubungan alur dalam app yang saat ini digunakan. 105 | ![](https://i.imgur.com/XqBTXAU.png) 106 | 107 | Selain itu, dalam mengembangkan produk terdapat beberapa aturan yang dianjurkan untuk dipatuhi, yakni: 108 | **Dependency Rule** 109 | ![](https://i.imgur.com/gfAjZ37.png) 110 | 111 | **Visual** 112 | - Buat reusable component. 113 | - Kumpulkan warna/ukuran/kata dalam satu file (ex: values/colors.xml). 114 | 115 | **Activity/Fragment** 116 | - Implementasi BaseMethod.java. 117 | - Pahami & ikuti lifecycle. 118 | - Buat activity untuk flow placeholder (jika terasa gemuk silahkan pisahkan). 119 | - Tipe activity yang digunakan Fragments holder, ViewPager holder, & UI container. 120 | 121 | **Model & ViewModel** 122 | - Representasi obyek dari properti dan logika bisnisnya. 123 | - Model dianjurkan berbentuk plain old java object (POJO). 124 | - Buat ViewModel untuk setiap model/fragment. 125 | 126 | **View** 127 | - Gunakan two way data binding. 128 | - Gunakan designtime attributes. 129 | 130 | **Constant** 131 | - File S.java untuk variable String yang nilainya mungkin akan berubah. 132 | - File I.java untuk variable konstan dalam Integer. 133 | - File K.java untuk variable konstant selain Integer (ex: Key value). 134 | - Gunakan String.format untuk kebutuhan format daripada operator "+". -------------------------------------------------------------------------------- /android-recommended-library.md: -------------------------------------------------------------------------------- 1 | # Recommended Library 2 | Berikut merupakan kumpulan library yang diharapkan membantu pengembangan. 3 | - [Soft keyboard flow helper](https://github.com/yshrsmz/KeyboardVisibilityEvent) 4 | - [Material dialog helper](https://github.com/afollestad/material-dialogs) 5 | - [Bottom-bar helper](https://github.com/roughike/BottomBar) 6 | - [Circle indicator](https://github.com/ongakuer/CircleIndicator) 7 | - [Debug helper](http://facebook.github.io/stetho/) 8 | - [Recyclerview helper](https://github.com/jianghejie/XRecyclerView) 9 | - [Memory leak detector](https://github.com/square/leakcanary) 10 | - [Android db helper](http://greenrobot.org/greendao) 11 | 12 | Kindly, add your recommended & tested library in here for help others :). -------------------------------------------------------------------------------- /api-standard.md: -------------------------------------------------------------------------------- 1 | # FLIPBOX API STANDARD 2 | 3 | 4 | Seluruh deskripsi di bawah merupakan standar dari API yang dibuat oleh Flipbox dan telah melewati diskusi bersama. 5 | 6 | ## KETENTUAN UMUM 7 | * Menggunakan versi dalam URLnya | contohnya `http://example.com/api/android/v1` 8 | * URL dibuat dengan menggunakan `kebab-case` | contohnya `http://example.com/api/ios/v1/sample-api-url` 9 | * Menggunakan singular form | contohnya `http://example.com/api/android/v1/table` atau `http://example.com/api/ios/v1/city` 10 | * Menggunakan id untuk mengakses child object | contohnya `http://example.com/api/android/v1/country/{id}/city` 11 | * Menggunakan pagination untuk mengakses kumpulan object | contohnya `http://example.com/api/ios/v1/city?page=1` 12 | * Memisahkan URL untuk setiap platform yang akan menggunakan API tsb | contohnya `http://example.com/api/android/v1/city?page=1` 13 | * URL publik harus dilindungi dengan menggunakan `X-APP-TOKEN` ( dikirimkan via Header ) 14 | * API harus memiliki discovery URL 15 | * Private Token harus dikirimkan melalui Header 16 | * Menggunakan raw parameter berisi JSON untuk non multipart request 17 | * Maksimal waktu response API adalah 250ms untuk data umum / detail dan 400ms untuk kumpulan data 18 | 19 | ## KETENTUAN PENGEMBALIAN DATA 20 | * Data yang dikembalikan harus menggunakan transformer untuk memastikan konsistensi struktur data 21 | * Sebaiknya 1 Transformer digunakan untuk 1 endpoint untuk menghindari perubahan struktur / key yang akan mengubah endpoint lain 22 | 23 | * Nilai data yang dikembalikan harus sesuai dengan tipenya ( apabila tipenya DOUBLE jangan mengembalikan STRING, apabila tipenya OBJECT jangan mengembalikan ARRAY dll ) 24 | * Hindari pengembalian null value apabila sangat tidak terpaksa 25 | 26 | ## List Request 27 | 28 | * Data **HARUS** di-paging, ukuran record-per-page dapat menyesuaikan dengan kondisi yang berjalan 29 | * `next` pointer link **HARUS** berupa string, jika current pointer adalah pointer terakhir dari daftar pointer, maka backend cukup mengembalikan string kosong: `""`. 30 | 31 | Contoh kembalian data dari List 32 | 33 | ```json 34 | { 35 | "data": [], 36 | "meta": { 37 | "links": { 38 | "next": "/relative/url/to/resource", 39 | "prev": "/relative/url/to/resource" 40 | }, 41 | "total_data": 100, 42 | "count": 2, 43 | "per_page": 10, 44 | "current_page": 10, 45 | "total_page": 10 46 | }, 47 | } 48 | ``` 49 | 50 | ## READ Request 51 | * Menggunakan HTTP GET Method 52 | * Mengembalikan HTTP Status Code 200 untuk return value dengan data, dan HTTP Status Code 204 untuk return value tanpa data. 53 | 54 | Contoh kembalian data READ 55 | 56 | ```json 57 | { 58 | "data": {}, 59 | "message": "get data xxx success" 60 | } 61 | ``` 62 | 63 | ## CREATE Request 64 | * Menggunakan HTTP PUT / POST Method 65 | * Mengembalikan HTTP Status Code 201 apabila data berhasil dibuat 66 | 67 | ## UPDATE Request 68 | * Menggunakan HTTP PUT / PATCH Method 69 | * Mengembalikan HTTP Status Code 200 apabila data berhasil diperbarui 70 | 71 | ## DELETE Request 72 | * Menggunakan HTTP DELETE Method 73 | * Mengembalikan HTTP Status Code 200 apabila data berhasil dihapus 74 | 75 | Contoh kembalian data untuk CREATE UPDATE & DELETE 76 | 77 | ```json 78 | { 79 | "message": "pesan yang bersesuaian dengan aksi" 80 | } 81 | ``` 82 | 83 | ## RESPONSE UNTUK ERROR 84 | * Error Autentikasi 85 | 86 | Harus mengembalikan HTTP Status Code 401 dengan error data sbb 87 | 88 | ```json 89 | { 90 | "code": 401.5, 91 | "message": "error message" 92 | } 93 | ``` 94 | 95 | * Error Validasi 96 | 97 | Harus mengembalikan HTTP Status Code 422 dengan error data sbb 98 | 99 | ```json 100 | { 101 | "message": "error message", 102 | "errors": [{ 103 | "field": "foo", 104 | "message": ["pesan error 1", "pesan error 2"] 105 | }, { 106 | "field": "bar", 107 | "message": ["pesan error 1", "pesan error 2"] 108 | }] 109 | } 110 | ``` 111 | 112 | * Error URL Tidak Ditemukan 113 | 114 | Harus mengembalikan HTTP Status Code 404 dengan error data sbb 115 | 116 | ```json 117 | { 118 | "message": "pesan yang bersesuaian dengan error" 119 | } 120 | ``` 121 | 122 | * Error Server 123 | 124 | Harus mengembalikan HTTP Status Code 500 dengan error data sbb 125 | 126 | ```json 127 | { 128 | "message": "error message", 129 | "trace": "string formatted stack trace" 130 | } 131 | ``` 132 | 133 | > `trace` hanya ditampilkan pada saat aplikasi run di staging environment, pada saat aplikasi run di production environment, `trace` **HARUS** disembunyikan. 134 | 135 | # Untuk kondisi lain 136 | 137 | Apabila dijumpai kondisi yang tidak diprediksi, silahkan menggunakan kembalian data 138 | 139 | ```json 140 | { 141 | "message": "pesan yang bersesuaian kondisi" 142 | } 143 | ``` 144 | 145 | dengan HTTP Status Code yang sesuai dengan situasi -------------------------------------------------------------------------------- /daily-coordination.md: -------------------------------------------------------------------------------- 1 | # Koordinasi Harian 2 | 3 | Bagian ini berisikan tata cara dan ketentuan izin, bekerja dari rumah ( WFH ) dan koordinas lain terkait kegiatan pengembangan di hari kerja. 4 | 5 | --- 6 | ### **_Daily Standup_** 7 | 8 | *Daily Standup* dilakukan setiap pagi di antara rentang waktu 10:30 - 11:00. Setiap individu di dalam tim akan mendapatkan kesempatan untuk memimpin jalannya *Standup* ( sukarela / bergiliran ). Apabila tidak ada sukarelawan untuk memimpin *Standup* esok hari, pemimpin *Standup* boleh menunjuk individu lain. 9 | 10 | Beberapa hal yang sebaiknya didiskusikan pada saat *Standup* : 11 | 12 | - Jumlah *task Redmine* pada hari itu, dan *task Redmine* yang sudah diselesaikan kemarin. 13 | - Kendala yang dihadapi saat pengembangan sistem 14 | - Rencana pengembangan sistem pada hari tsb 15 | - Pemimpin *Standup* harus mencatat hasil *Standup* pada hari tsb 16 | - Khusus untuk hari Senin, dalam *Standup* akan dibahas target mingguan secara singkat dan progress *Sprint* yang sedang berjalan 17 | - Khusus pada hari Jumat, QA akan mencatat / memotret hasil rekapitulasi *Standup* pada minggu berjalan dan mencatatnya di dokumen *Morning Standup Recap* 18 | 19 | --- 20 | ### **Tata Cara Izin & Cuti** 21 | 22 | - **Izin Terlambat** : Individu yang berhalangan hadir tepat waktu harus menginformasikan alasan keterlambatan dan waktu kehadiran kepada kepala divisi masing masing sebelum jam 9. Apabila keterlambatan disetujui, individu terkait harus mengirimkan email kepada tim sebelum jam 9:30. 23 | - **Izin Sakit** : Individu yang berhalangan masuk dikarenakan sakit harus melaporkan keterangan sakit kepada kepala divisi dan tim secepat mungkin. Sakit lebih dari 1 hari harus melampirkan surat dokter dan diharapkan langsung melapor ke tim bisnis untuk proses *reimbursement*. 24 | - **Izin Lain** : Dalam keadaan tertentu, individu berhak mengajukan izin. Proses ini harus didiskusikan terlebih dahulu dengan kepala divisi dan tim terkait. 25 | - **Cuti** : Cuti harus didiskusikan dengan kepala divisi paling lambat H-14 sebelum cuti diambil. Pengajuan cuti harus melalui form cuti yang diisi dan disampaikan dalam bentuk berkas *google drive* ataupun berkas fisik yang nantinya akan diubah ke dalam bentuk digital kembali. Apabila disetujui, form cuti harus diisi dan disampaikan ke tim bisnis paling lambat H-4 sebelum cuti diambil. 26 | 27 | --- 28 | ### **Tata Cara Kerja dari Rumah (WFH)** 29 | 30 | Flipbox mempunyai kebijakan Kerja dari Rumah sebanyak maksimal 2x dalam 1 bulan. Individu yang ingin mengambil Kerja dari Rumah harus memperhatikan beberapa hal berikut : 31 | 32 | - Kerja dari Rumah dan Cuti tidak boleh berada di dalam minggu yang sama 33 | - Kerja dari Rumah hanya bisa diambil 1x setiap minggunya 34 | - Kerja dari Rumah harus didiskusikan dengan rekan 1 divisi. Dalam 1 hari, hanya diperbolehkan maksimal 50% dari jumlah anggota divisi yang melakukan WFH. 35 | - Dalam keadaan tertentu, kepala divisi boleh memberikan bonus Kerja dari Rumah. Hal ini harus didiskusikan dengan PM dan tim terkait. 36 | - Kerja dari Rumah harus disetujui oleh kepala divisi dan tim terkait maksimal H-1 dan email pemberitahuan harus dikirimkan maksimal H-1 sebelum jam 3 sore. 37 | - Email pemberitahuan Kerja dari Rumah berisi jam kerja aktif, *task Redmine* yang akan diselesaikan, dan keterangan tambahan lain yang relevan. 38 | 39 | --- 40 | ### **Slip Kuning** 41 | 42 | Slip kuning adalah sebuah mekanisme pencatatan dan sanksi kepada individu yang melakukan tindakan indisipliner. 1 slip kuning setara dengan 10 ribu rupiah dan hasil slip kuning akan digunakan untuk kepentingan bersama seperti pembelian buah buahan, makanan ringan atau hal lainnya. 43 | 44 | Tindakan indisipliner yang akan mendapat slip kuning adalah : 45 | 46 | - Melakukan izin, WFH, ataupun cuti tanpa mengikuti kaidah yang berlaku 47 | - Tidak melakukan komunikasi dengan [Howdy](https://howdy.ai/) pada waktu yang telah ditentukan 48 | - WFH, namun tidak merespon pertanyaan ( toleransi waktu 30 menit ) pada jam aktif yang telah diinformasikan 49 | - Tidak melakukan proses *update* Redmine sesuai tugas masing masing 50 | 51 | **Amnesti Slip Kuning** : 52 | Individu boleh mengajukan amnesti slip kuning dalam kondisi : 53 | 54 | - *Sprint* selesai lebih cepat dari estimasi 55 | - Individu ybs telah melakukan kontribusi kepada komunitas ( pembuatan / pembaruan pustaka, pembuatan artikel, ataupun menghadiri / mengisi acara komunitas ) 56 | 57 | Slip kuning akan dicatat setiap hari pada saat *Daily Standup* dan setiap individu bertanggung jawab terhadap penulisan slip kuning masing masing. 58 | 59 | Slip kuning akan dikumpulkan ( beserta dendanya ) pada awal bulan untuk kemudian diberikan kepada juru kunci kulkas agar dikelola bagi kemaslahatan umat. -------------------------------------------------------------------------------- /fabric-guide.md: -------------------------------------------------------------------------------- 1 | # Panduan Penggunaan *Fabric* 2 | 3 | Bagian ini berisi mengenai panduan untuk menggunakan *Fabric* dan alat yang disediakannya seperti *Crashlytics*, *Beta* dan *Answer* 4 | 5 | 6 | --- 7 | ### Panduan penggunaan *Beta* 8 | 9 | ***Beta*** adalah sebuah alat yang disediakan oleh *Fabric* untuk mengakomodir proses distribusi dan testing dari sebuah aplikasi *mobile* berbasis iOS dan Android. 10 | 11 | Proses distribusi aplikasi dilakukan oleh *Quality Assurance* ataupun *Mobile Developer* dengan ketentuan sebagai berikut : 12 | 13 | - Sudah terdapat beberapa perubahan / pembaruan aplikasi ( berupa *story*, *2-3 bugfixes*, *2-3 tasks* ataupun *2-3 improvements* ) 14 | - Perubahan / pembaruan yang ada harus sudah melewati proses testing dan uji kualitas melalui *Pull Request* 15 | - *Changelog* harus dilampirkan sedetail mungkin 16 | 17 | Distribusi aplikasi melalui *Beta* bisa dilakukan melalui *Android Studio plugin* ataupun melalui aplikasi versi Mac OSX 18 | 19 | --- 20 | ### Panduan penggunaan *Answer* 21 | 22 | TBD 23 | 24 | --- 25 | ### Panduan penggunaan *Crashlytics* 26 | 27 | ***Crashlytics*** adalah sebuah alat yang disediakan oleh *Fabric* untuk mengakomodir rekaman terjadinya sebuah *crash* ataupun *force close* di dalam aplikasi *mobile* berbasis iOS dan Android. 28 | 29 | Instalasi *Crashlytics* bisa dilakukan melalui *Android Studio plugin* ataupun melalui aplikasi versi Mac OSX 30 | -------------------------------------------------------------------------------- /ios-development-style-guide.md: -------------------------------------------------------------------------------- 1 | # vip-starter 2 | sebuah proyek iOS menggunakan Arsitektur VIP (View Interactor Presenter) 3 | 4 | ### Cara penggunaan 5 | instal template dari [clean-swift.com](https://clean-swift.com/) setelah download template tersebut buka directory template di terminal dan `make install_templates` untuk instal template, untuk menghasilkan `scene` baru : `New File` -> `iOS` -> `Clean Swift` -> `Scene` -> `Masukkan Nama Scene Anda` 6 | 7 | ### `Library` yang digunakan: 8 | * Fabric 9 | * Crashlytics 10 | 11 | * Alamofire ( networking ) 12 | * AlamofireImage ( request image from server ) 13 | * ModelMapper ( mapping model ) 14 | * PKHUD ( Loading View ) 15 | 16 | ## VIP 17 | VIP adalah satu set Xcode Templates untuk menghasilkan komponen Clean Architecture. 18 | 19 | #### Key Points VIP Cycle 20 | 21 | * `ViewController` menerima aktivitas pengguna, membuat objek permintaan, mengirimkannya ke `Interactor`. 22 | * Interactor melakukan beberapa pekerjaan dengan `request`, membangun objek respon, dan mengirimkannya ke presenter. 23 | * Presenter memformat data dari `response`, dan membangun `view model object` dan mengirimkan ke `ViewController`. 24 | * `ViewController` menampilkan hasil yang ada di `ViewModel` ke pengguna. 25 | 26 | ![vip cycle](https://cdn-images-1.medium.com/max/2000/1*QV4nxWPd_sbGhoWO-X7PfQ.png) 27 | 28 | ## VIP Component 29 | 30 | #### View Controller 31 | * `ViewController` berisi `display logic` 32 | * untuk bikin `scene` baru : `New File` -> `iOS` -> `Clean Swift` -> `Scene` -> `Input Scene Name` 33 | * Terapkan `UIViewController` atau `Base__ViewController` 34 | * Terapkan `UITableViewController`, `UICollectionViewController`, atau `UIWebViewController` jika dibutuhkan 35 | * Terapkan `BaseFormViewController` untuk `scene` berbasis form 36 | * Gunakan `xib`, jangan menggunakan `storyboard`. 37 | 38 | #### Interactor 39 | 40 | * `Interactor` berisi `Bussiness Logic` 41 | * Gunakan `worker` jika dibutuhkan 42 | * Menunggu permintaan dari `ViewController` dan mengirimkan respon ke `presenter` 43 | 44 | #### Presenter 45 | 46 | * Berisi `ViewLogic` 47 | * Memformat ulang data dari `interactor` dan mengirimkan ke `ViewController`. 48 | 49 | #### View 50 | 51 | * Gunakan `xib` atau `by code` 52 | * Jangan menaruh `bussiness logic` disini 53 | 54 | #### Model 55 | 56 | * Representasi dari objek dengan propertinya 57 | * Gunakan `ModelMapper` 58 | 59 | #### Router 60 | 61 | * Mengarahkan ke `scene` berikutnya 62 | * Mengirim data ke `ViewController` lain 63 | 64 | # Group dan Penamaan 65 | 66 | ``` 67 | [Optional] Core 68 | - Assets.xcassets 69 | - LaunchScreen.storyboard 70 | - AppDelegate.swift 71 | Base 72 | Models 73 | Scenes 74 | - YourSceneName 75 | Services 76 | Worker 77 | ``` 78 | | Nama Group | Deskripsi | 79 | | ---------- | ----------- | 80 | | Core | File inti dari proyek xcode seperti `Assets.xcassets`, `LaunchScreen.storyboard`, `AppDelegate.swift` | 81 | | Base | Kelas dasar, yang berguna untuk meminimalkan kode | 82 | | Models | Berisi struktur data yang akan digunakan untuk manajemen data | 83 | | Scenes | Berisi VIP Components yang membangun `Scene` | 84 | | Services | `Global Helper` yang tidak berhubungan dengan logika bisnis | 85 | | Worker | `Global Helper` spesifik untuk logika bisnis | 86 | ``` 87 | -------------------------------------------------------------------------------- /mobile-development.md: -------------------------------------------------------------------------------- 1 | # Panduan untuk *Mobile Developer* 2 | Bagian ini berisi mengenai panduan untuk membuat kode baik, penjelasan arsitektur dan pustaka yang ada dan/atau digunakan di Flipbox. 3 | 4 | --- 5 | 6 | ### MVVM-Starter : Standar arsitektur untuk Aplikasi Android 7 | 8 | *MVVM Starter* merupakan standar arsitektur proyek berbasis Android yang dikembangkan di Flipbox. Sesuai dengan namanya, arsitektur ini mengadopsi konsep MVVM dengan penambahan beberapa fungsi lain untuk membantu pengembangan aplikasi menjadi lebih cepat dan stabil. 9 | 10 | Lihat deskripsi selengkapnya di [MVVM Starter](https://github.com/flipboxstudio/mvvm-starter) dan [Panduan MVVM Starter](https://github.com/flipboxstudio/tech-handbook/blob/develop/android-development-guide.md) 11 | 12 | #### Pustaka : Sosoito 13 | Lihat selengkapnya di [sosoito](https://github.com/flipboxstudio/sosoito) 14 | 15 | --- 16 | 17 | ### VIP-Starter : Standar arsitektur untuk Aplikasi iOS 18 | 19 | *VIP Starter* merupakan standar arsitektur proyek berbasis iOS yang dikembangkan di Flipbox. Arsitektur ini mengadopsi konsep [Clean Swift](http://clean-swift.com/) dengan penambahan beberapa fungsi lain untuk membantu pengembangan aplikasi menjadi lebih cepat dan stabil. 20 | 21 | Lihat deskripsi selengkapnya di [VIP Starter](https://github.com/flipboxstudio/vip-starter) dan [Panduan VIP Starter](https://github.com/flipboxstudio/tech-handbook/blob/master/ios-development-style-guide.md) 22 | 23 | --- 24 | Bacaan tambahan ( gunakan akun Flipbox untuk akses Udemy *course* ) : 25 | 26 | - [Panduan Penggunaan Fabric](https://github.com/flipboxstudio/tech-handbook/blob/develop/fabric-guide.md) 27 | - [Stanford iPhone App Development 2017](https://www.youtube.com/playlist?list=PLPA-ayBrweUz32NSgNZdl0_QISw-f12Ai) 28 | - [100 Days of Google Dev](https://www.youtube.com/watch?v=32i7ot0y78U&list=PLOU2XLYxmsIJDPXCTt5TLDu67271PruEk) 29 | - [Android App Architecture](https://developer.android.com/topic/libraries/architecture/index.html) -------------------------------------------------------------------------------- /programming-concepts.md: -------------------------------------------------------------------------------- 1 | # Panduan dan konsep dasar Programming 2 | 3 | Bagian ini berisi rangkuman dan referensi dasar dasar pemrograman yang wajib dipahami oleh seluruh tim teknis Flipbox. 4 | 5 | --- 6 | ### Konsep Clean Code 7 | 8 | Konsep *Clean Code* mempunyai beberapa penafsiran dan karakteristik, di antaranya : 9 | 10 | - **Kode tersebut harus mudah dipahami** 11 | - Memiliki alur kerja/pertukaran data yang jelas dan konsisten 12 | - Kolaborasi antar *class* atau berkas harus mudah dipahami 13 | - Tanggung jawab dan fungsi dari setiap berkas harus mudah untuk dipahami. Jangan membuat fungsi yang terlalu kompleks apabila tidak dibutuhkan. 14 | - Fungsi atau *method* yang ada di dalam sebuah berkas harus mudah dipahami 15 | - Tujuan, penamaan dan fungsi dari setiap variabel ataupun baris mudah dipahami dan mudah dibaca 16 | - Kode harus mudah dibaca, tambahkan komentar di bagian yang cukup kompleks atau kurang stabil (lihat bagian *readable code*) 17 | 18 | - **Kode tersebut harus mudah diubah** 19 | - Kelas dan fungsinya harus dijaga agar tetap kecil dan bertanggung jawab pada sebuah pekerjaan tertentu (*single responsibility principle*) 20 | - Kelas harus memiliki API yang jelas dan mudah dipahami / mudah dibaca 21 | - Kelas dan fungsinya harus berjalan dengan sebagai mana mustinya dan proses yang ada di dalamnya mudah untuk ditebak 22 | - Mempunyai *unit test* atau diatur sedemikian rupa agar memudahkan pembuatan tes. 23 | - Tes yang tersedia mudah dipahami dan mudah untuk diubah 24 | - Redundansi kode harus dijaga seminimal mungkin (*DRY principle*) agar kode dapat tetap berjalan dengan konsisten ketika terjadi perubahan di suatu tempat 25 | - Dependensi yang ada di dalam kode harus dijaga seminimal mungkin untuk mengurangi resiko kesalahan akibat perubahan dependensi 26 | 27 | 28 | > "Clean Code is a code that is written by someone who cares" - **Michael Feathers** 29 | 30 | Bacaan tambahan : 31 | 32 | [Clean Code : A Handbook of Agile Software Craftmanship](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) 33 | 34 | [High Quality Code for Better Programmer](https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer) 35 | 36 | [Clean Code for Javascript](https://github.com/ryanmcdermott/clean-code-javascript) 37 | 38 | 39 | --- 40 | ### Konsep Readable Code 41 | 42 | Hal yang cukup sering dilupakan pengembang adalah bahwa kode yang mereka kembangkan akan digunakan kembali suatu hari nanti, mungkin oleh orang lain. Banyak kasus muncul ketika kode lama dibuka kembali, dibutuhkan waktu untuk memahami ataupun mengingat ulang bagaimana kode tersebut dibuat. Waktu tersebut dapat diminimalisir apabila kode yang dibuat mudah untuk dibaca dan dipahami. 43 | 44 | Prinsip prinsip untuk membuat kode yang mudah dibaca adalah : 45 | 46 | - Konsistensi dalam tata cara pembuatan kode, di antaranya : 47 | - Spasi vs tab 48 | - Peletakan { } 49 | - Ikuti kesepakatan yang berlaku di dalam tim 50 | - Penamaan *files & folders* yang konsisten : 51 | - Peletakan berkas di dalam *folder* yang relevan dan mudah dipahami 52 | - Konvensi penamaan (CamelCase, snake-case, etc) 53 | - Ikuti kesepakatan yang berlaku di dalam tim 54 | - Masukkan komentar dan dokumentasi di tempat yang membutuhkan penjelasan tambahan 55 | - Hindari pembuatan fungsi / baris yang kompleks dan membutuhkan waktu tambahan untuk dipahami. 56 | - Hindari spasi / tab yang terlalu menjorok (*deep nesting*) karena akan menyulitkan pemahaman fungsi dan tujuan kode 57 | 58 | > "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live. Code for readability" - **John F Woods** 59 | 60 | Bacaan lebih lanjut : 61 | 62 | [The Art of Readable Code](https://www.amazon.com/Art-Readable-Code-Practical-Techniques/dp/0596802293) 63 | 64 | [Write Elegant Code](https://code.tutsplus.com/articles/writing-elegant-and-readable-code--mobile-21514) 65 | 66 | [Write Cleaner Code](https://www.codeschool.com/blog/2015/09/29/10-ways-to-write-cleaner-code/) 67 | 68 | --- 69 | ### Konsep SOLID, KISS & DRY 70 | 71 | 72 | **KISS** : Keep It Simple and Straightforward! 73 | 74 | Konsep KISS menyatakan bahwa kode yang dibuat harus sederhana dan mudah dipahami tanpa mengorbankan kualitas hasil akhir pengerjaan kode. 75 | 76 | Beberapa hal yang harus diperhatikan dalam penerapan konsep KISS adalah : 77 | 78 | - *methods & classes* harus dibuat sesederhana mungkin. 79 | - Hindari kompleksitas dalam kondisi perulangan dan percabangan (*nested/complex loop & conditional*) 80 | - Hindari solusi yang terlalu kompleks atau kode yang terlalu singkat namun sulit untuk dibaca. Jangan pula mengorbankan performa demi mendapatkan baris kode yang mudah dibaca. Cari keseimbangan antara keduanya. 81 | 82 | **DRY** : Don’t Repeat Yourself! 83 | 84 | Apabila sebuah blok kode sudah digunakan beberapa kali ( +- 3 kali ) dalam sebuah proyek, buatlah *reusable/helper method* dan hapus duplikasi yang terjadi. 85 | 86 | **SOLID** 87 | 88 | - **Single responsibility** : Sebuah *class* hanya boleh memiliki 1 tanggung jawab. Jangan membuat sebuah *class* yang terlalu kompleks dan melakukan banyak hal sekaligus. 89 | > **Contoh** : sebuah layanan ojek online mungkin bisa membuat kelas `AntarJemput` untuk memodelkan proses bisnisnya. Namun akan lebih baik apabila kelas tersebut dipecah menjadi `Antar` yang bertanggung jawab dengan pengantaran pengguna menuju tujuan dan `Jemput` yang bertanggung jawab untuk fungsi penjemputan pengguna dari tempat asal sehingga apabila ada optimalisasi dalam proses `Jemput` , fungsi yang mengimplementasi kelas `Antar` menjadi relatif lebih aman 90 | 91 | - **Open for extension but closed for modification** : Fungsi atau kegunaan dalam sebuah entitas seharusnya bisa ditambahkan tanpa harus mengubah isi dari entitas tersebut ( *Open Closed* ) 92 | > Contoh : sebuah `Truk` memiliki fungsi `jumlahVolumeBarang` yang memiliki parameter *List* barang barang yang ada di dalam `Truk` tersebut. Fungsi `jumlahVolumeBarang` bertugas untuk menghitung volume masing masing barang kemudian menjumlahkan keseluruhan volume. Apabila terdapat jenis barang baru dengan rumus volume baru, maka `jumlahVolumeBarang` harus diperbarui. Seharusnya ada implementasi `hitungVolume` di dalam barang sehingga untuk barang tertipe apapun, `jumlahVolumeBarang` tidak harus diperbarui karena hanya akan menjumlahkan hasil dari `barang.hitungVolume()` 93 | 94 | - **Liskov substitution principles** : Sebuah *object* seharusnya dapat diganti oleh *object subtype* tanpa mengubah keluaran dari sebuah program ( *Design by Contract* ) 95 | > Contoh : sebuah fungsi `antarPenumpang` memiliki parameter *Kendaraan* yang memiliki fungsi `rem`. *Liskov subtitution* menyatakan bahwa semua jenis *Kendaraan* (`Odong Odong`, `Bemo`)harus mengimplementasikan `rem` dengan tujuan yang sama ( menurunkan kecepatan ). 96 | 97 | - **Interface segregation principles** : *Interface* yang spesifik dan kecil lebih baik daripada *Interface* besar yang menyebabkan *class* harus menerapkan fungsi yang tidak dibutuhkan. 98 | 99 | - **Dependency inversion principle** : Detail harusnya bergantung pada abstraksi. Seharusnya tidak ada *class* yang bergantung / *depend* dari *class* yang konkrit ( *non abstract* ) 100 | > **Contoh** : Fungsi `antarPenumpang` dalam kelas `Antar` mungkin bisa memiliki parameter/dependensi `Sepeda Motor`. Namun apabila layanan ojek online ingin menambahkan `Bemo` di armadanya tentu harus mengubah isi dari `Antar`. Akan lebih baik apabila parameter dari `antarPenumpang` diubah menjadi `Kendaraan` (*abstract*) sehingga memungkin adanya penambahan tipe armada tanpa harus mengubah fungsi / kelas terkait. 101 | 102 | 103 | Bacaan lebih lanjut : 104 | 105 | [SOLID : Object Oriented Design](https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design) 106 | 107 | [SOLID, GRASP and other principles of OOP](https://dzone.com/articles/solid-grasp-and-other-basic-principles-of-object-o) 108 | 109 | --- 110 | ### Konsep OOP 111 | 112 | Beberapa konsep utama yang harus dipahami dari sebuah paradigma OOP ( *Object Oriented Programming* ) adalah : 113 | 114 | **Everything is an object** 115 | 116 | Banyak pihak yang menyebutkan bahwa dalam OOP, semua hal bisa direpresentasikan sebagai `Object`. Hal ini bisa mungkin tidak bisa diimplementasikan dalam beberapa situasi/konsep tertentu ( *primitive variables*, *methods*, etc ). Namun perlu dipahami bahwa dalam pemodelan solusi, hampir sebagian besar masalah dan solusinya dapat direpresentasikan sebagai kumpulan objek yang saling berinteraksi satu sama lain. Oleh karena itu, kemampuan memodelkan masalah menjadi objek dan representasinya menjadi sangat penting dalam pemahaman OOP. 117 | 118 | **Encapsulation** 119 | 120 | Enkapsulasi menyatakan bahwa implementasi/representasi internal dari sebuah objek seharusnya tidak bisa terlihat dari objek lain. 121 | 122 | Enkapsulasi bisa dilakukan dengan cara melakukan pembatasan akses terhadap *accessor* dan *mutator*. ***Accessor*** merupakan sebuah fungsi yang dapat memberikan nilai yang terkandung di sebuah objek. ***Mutator*** adalah sebuah fungsi yang dapat mengubah representasi/nilai internal yang terkandung di dalam sebuah objek. 123 | 124 | > **Contoh** : objek `Person` bisa mempunyai *Accessor* `getClothes()` dan *Mutator* `setClothes(...)` untuk mencari tahu dan mengubah pakain yang sedang dikenakannya 125 | 126 | **Abstraction** 127 | 128 | Abstraksi berhubungan erat dengan enkapsulasi, karena pada dasarnya abstraksi adalah proses pembuatan sebuah objek yang tidak memiliki implementasi nyata dalam *Accessor* ataupun *Mutator* yang dimilikinya. Implementasi tersebut akan diterapkan pada objek yang merepresentasikannya 129 | 130 | > **Contoh** : objek `Manusia` memiliki *Accessor* `bisaMembaca` , namun implementasi `bisaMembaca` akan berbeda tergantung objek lain yang merepresentasikan `Manusia`. Budi mungkin `bisaMembaca` ( mengembalikan `true` ) namun Joko bisa saja tidak `bisaMembaca` ( mengembalikan `false` ) 131 | 132 | **Inheritance** 133 | 134 | Secara umum, objek dapat berinteraksi satu dengan yang lainnya dalam hubungan mempunyai (*has a*), menggunakan (*use a*), atau merepresentasikan (*is a*). *Is a* atau representasi adalah sebuah bentuk dari *Interitance* atau pewarisan. Dalam konsep *Inheritance* terdapat istilah *parent/super class* dan *child class*. *Child class* akan mewarisi properti dan fungsi non-privat yang dimiliki oleh *parent/super class*. 135 | 136 | > **Contoh** : Kelas `Kendaraan` memiliki properti `roda` dan fungsi `aturKecepatan`. Semua kelas yang menjadi *child class* dari `Kendaraan` akan memiliki `roda` dan fungsi `aturKecepatan` secara otomatis. 137 | 138 | **Polymorphism** 139 | 140 | *Polymorphism* bisa dijabarkan atau diartikan sebagai sebuah operasi yang memiliki beberapa jenis implementasi 141 | 142 | Beberapa jenis *Polymorphism* adalah : 143 | 144 | - *Ad Hoc Polymorphism* atau *Function Overloading* adalah sebuah fungsi yang memiliki nama sama, namun parameter berbeda sehingga bisa memiliki implementasi yang berbeda 145 | > Contoh : fungsi dengan `jumlah` bisa memiliki parameter `angka arab (1-0)` ataupun `angka romawi (I-X)` sehingga implementasi `jumlah(10, 20)` tentunya akan menjadi beda dengan `jumlah (XV, IV)` 146 | 147 | - *Parametric Polymorphism* atau *Generic Type* adalah sebuah fungsi atau jenis data yang ditulis secara umum sehingga bisa mengakomodir semua jenis tipe data tanpa terkecuali 148 | > Contoh : kelas `Minuman` dan fungsi `racikMinuman(T)` mempunyai *Generic Type* yang direpresentasikan dalam `T`. Dalam proses representasi `Minuman`, `T` dapat didefinisikan sebagai data berjenis apapun (misal `Kopi` atau `Teh`) dan `racikMinuman` harus menggunakan tipe data yang sama sebagai parameter ( menjadi `racikMinuman(Kopi)` atau `racikMinuman(Teh)`. 149 | 150 | - *Subtyping* atau *Function Overriding* adalah sebuah fungsi yang diwariskan dari *parent class* namun dapat didefinisikan berbeda oleh *child class* 151 | > Contoh : kelas `Binatang` mempunyai fungsi `bicara`, namun kelas yang merepresentasikan `Binatang` mungkin mempunyai cara yang berbeda untuk `bicara` ( misalkan `Kucing` `bicara` akan mengembalikan *Meow!* dan `Anjing` `bicara` akan mengembalikan *Woof!* ) 152 | 153 | 154 | Bacaan tambahan ( gunakan akun Flipbox untuk akses Udemy *course* ) : 155 | 156 | [Design Pattern Guide](https://www.udemy.com/draft/725258/learn/v4/content) 157 | 158 | [OOP on Wikipedia](https://en.wikipedia.org/wiki/Object-oriented_programming) 159 | 160 | --- 161 | ### Konsep Reactive Programming 162 | 163 | Beberapa konsep utama yang harus dipahami dari sebuah paradigma *Reactive Programming* adalah : 164 | 165 | **Everything is a stream** 166 | 167 | Sedikit berbeda dengan konsep OOP yang menggambarkan masalah dan solusinya sebagai objek dan interaksinya, *Reactive Programming* menitikberatkan kepada kejadian dan alur kejadiannya (*stream & events*). Hampir sebagian besar proses dapat digambarkan dalam kumpulan kejadian (*events*) dan alur kejadian dari mulai sampai selesai (*stream*) 168 | 169 | Karena perbedaan paradigma ini, *Reactive Programming* sangat cocok apabila diterapkan ke dalam sebuah sistem yang membutuhkan respon secara instan / *real time* karena paradigma ini sangat menitikberatkan kepada kejadian (*event*) dan reaksinya (*response*). 170 | 171 | **Subject / Observable** 172 | 173 | *Stream* dapat diimplementasikan dengan menginisialisasi sebuah *Subject* (bisa juga disebut *Observable*). *Observable* adalah sebuah objek/data yang dapat dipantau (*observe/subscribed*) oleh sebuah *Observer*. Setiap perubahan dari status data akan langsung diinformasikan kepada seluruh *Observer* yang memantau data *Observable* tersebut. 174 | 175 | **Observer** 176 | 177 | *Observer* adalah sebuah objek/data yang memantau semua perubahan nilai dari *Subject/Observable*. Setelah *Observer* menyatakan diri siap memantau (*subscribe*) *Observable*, maka *Observer* tersebut sudah memasuki *stream data* yang ada di dalam proses. Setiap ada perubahan status internal di dalam *Subject/Observable* maka *Observer* akan mendapatkan notifikasi sehingga dapat melakukan reaksi yang bersesuaian dengan aksi. 178 | 179 | Bacaan lebih lanjut : 180 | 181 | [Reactive Programming Introduction](https://gist.github.com/staltz/868e7e9bc2a7b8c1f754) 182 | 183 | [ReactiveX](http://reactivex.io/) 184 | 185 | --- 186 | 187 | -------------------------------------------------------------------------------- /pull-request-workflow.md: -------------------------------------------------------------------------------- 1 | # Kolaborasi dan Review menggunakan *Pull Request* 2 | 3 | Bagian ini berisi tentang proses _Pull Request_ yang berjalan di Flipbox, tata cara dan kesepakatan yang berlaku. 4 | 5 | --- 6 | ### *Main Cast* 7 | 8 | Dalam proses _Pull Request_ ini terdapat tiga peran utama, yakni: 9 | - **Captain**: *Code reviewer & decision maker* (pengembang utama). 10 | - **QA**: *Feature/function reviewer*. 11 | - **Member**: *Developer* (pengembang). 12 | 13 | ![](https://i.imgur.com/qNyLVwx.png) 14 | 15 | ### *Pull Request Manifesto @ Flipbox* 16 | 17 | 1. Tidak boleh ada proses development di dalam *branch* `develop` atau `master` - kedua *branch* tersebut hanya berfungsi untuk `merge, test & release` fitur yang sudah stabil 18 | 2. Segera buat *Pull Request* setelah *branch* dibuat dan *remote push* sudah dilakukan. 19 | 3. *Pull Request* akan ditolak apabila ditemukan konflik dalam kode. Pengembang harus menyelesaikan konflik tersebut dan memastikan tidak ada konflik dalam *Pull Request* 20 | 4. Lakukan penamaan *branch* sesuai kesepakatan bersama ( lihat Ketentuan *Branching* ) 21 | 5. *Branch* `hotfix` akan menghasilkan *Pull Request* ke *branch* `master` dan *branch* `develop` 22 | 7. Pengembang utama sebaiknya melakukan proses `merge` di repositori lokal. Khusus untuk branch `story` sebaiknya dilakukan *preserve commit history* dengan melakukan proses `git merge --no-ff`. Untuk branch lain silahkan `merge & squash` menggunakan `git merge --squash` 23 | 8. Pengembang utama yang memiliki akses *push* ke `master` dan `develop` harus mengatur proses `release` aplikasi dan memungkinkan untuk membuat *branch* `release` dengan beberapa permintaan pekerjaan tambahan sebelum akhirnya akan dilakukan `merge` ke `develop` dan `master` 24 | 25 | 26 | ### Ketentuan *Branching* 27 | 28 | Pilihan nama *branch* yang dapat digunakan adalah 29 | 30 | - **story**/[nomor redmine] [deskripsi] 31 | 32 | > Untuk *Story* yang dirasa terlalu besar, pecah ke dalam *Task* yang lebih kecil untuk kemudian di merge ke *branch* `story` sebelum melakukan *Pull Request* ke *branch* `develop` 33 | 34 | - **task**/[nomor redmine] [deskripsi] 35 | - **improvement**/[nomor redmine] [deskripsi] 36 | - **bug**/[nomor redmine] [deskripsi] 37 | - **hotfix**/[nomor redmine] [deskripsi] 38 | 39 | ### Konsep Git 40 | 41 | - Gunakan pesan *commit* yang relevan dan masukkan *tag* yang sesuai. 42 | - [ADD] deskripsi penambahan berkas yang dilakukan 43 | - [UPDATE] deskripsi *update* yang dilakukan 44 | - [FIX] deskripsi perbaikan yang dilakukan 45 | - [Git Cheatsheet](https://www.git-tower.com/blog/git-cheat-sheet/) 46 | - [Rewrite Commit History](https://git-scm.com/book/id/v2/Git-Tools-Rewriting-History) 47 | - [Squash Published Commits](https://stackoverflow.com/questions/5667884/how-to-squash-commits-in-git-after-they-have-been-pushed) 48 | 49 | -------------------------------------------------------------------------------- /quality-assurance.md: -------------------------------------------------------------------------------- 1 | # Panduan untuk *Quality Assurance* 2 | Bagian ini berisi mengenai panduan untuk melakukan testing dengan baik, deskripsi dokumen, proses dan kesepakatan yang berlaku di Flipbox. 3 | 4 | --- 5 | ### *Automated Testing* 6 | 7 | Tes otomatis dilakukan dengan menggunakan *Katalon Studio* dan *Groovy* sebagai bahasa pemrogramannya. 8 | 9 | Beberapa hal yang perlu diperhatikan dalam melakukan pembuatan tes otomatis adalah : 10 | 11 | - Masukkan *Test Case* dan *Object Repository* dalam folder yang relevan untuk memudahkan organisasi kode 12 | - Buat *Test Suite* dengan kombinasi beberapa *Test Case* agar menghasilkan tes yang mencakup keseluruhan skenario 13 | - Gunakan fasilitas *Custom Keywords* untuk pembuatan *reusable function* dan pembuatan kelas *Model* 14 | 15 | --- 16 | ### *Manual Testing & Test Case Document* 17 | 18 | Tes manual dilakukan dengan menggunakan dokumen *Test Case* untuk panduan langkah langkah testing. 19 | 20 | Tes manual dilakukan oleh pengembang setelah melakukan *Pull Request* untuk kemudian dikonfirmasi oleh QA. Sebelum *sprint* berakhir, QA akan memastikan kembali seluruh pekerjaan yang diselesaikan sudah memenuhi kondisi yang tertera di dalam dokumen *Test Case* 21 | 22 | Beberapa hal yang perlu diperhatikan dalam melakukan pembuatan tes manual adalah : 23 | 24 | - Pastikan skenario yang dibuat sudah mencakup berbagai kondisi, meliputi *positive case* , *negative case* , *corner cases* dan validasi data masuk/keluar ataupun data kosong. 25 | - Masukkan dokumen yang telah dibuat ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 26 | - *Parent Folder* : [NAMA PROJECT] QUALITY 27 | - *Test Case Folder* : Test Case Sprint X 28 | - Nama berkas : Test Case [Nama Project] [Platform] 29 | - Atur dokumen berdasarkan tanggal pengisian 30 | 31 | --- 32 | ### Dokumen *Technical Test Specification* 33 | 34 | Merupakan dokumen kolaborasi antara *Quality Assurance* dengan *System Analyst*. Dokumen ini menggabungkan antara *Tech Spec* dengan *Test Case* agar didapatkan proses yang efisien tanpa mengurangi kualitas dan informasi yang didapatkan dalam kedua dokument tersebut. Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Sheets -> From a template* ) 35 | 36 | *Technical Test Spec* dibuat untuk proyek yang sudah biasa dikerjakan dan tidak memiliki tingkat kesulitan khusus. 37 | 38 | Di dalam dokumen ini terdapat *sheet Test Case* yang akan diisi oleh *Quality Assurance*. 39 | 40 | Masukkan dokumen *Tech Spec* ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 41 | 42 | - *Parent Folder* : [NAMA PROJECT] QUALITY 43 | - Nama folder : Technical Tech Spec 44 | - Nama berkas : TTS [Nama Project] [Platform] 45 | 46 | --- 47 | ### Dokumen *User Manual* 48 | 49 | Manual penggunaan sistem dibuat sebelum sistem dirilis ke pengguna. Manual penggunaan berisi beberapa hal utama yaitu : 50 | 51 | - Garis besar kegunaan sistem 52 | - *Screenshot* dari halaman sistem 53 | - Penjelasan mengenai kegunaan dan fungsi yang terkandung dalam halaman tersebut 54 | 55 | Masukkan dokumen manual penggunaan sistem ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 56 | 57 | - *Parent Folder* : [NAMA PROJECT] QUALITY 58 | - Nama berkas : User Manual [Nama Project] [Platform] 59 | - Jika dibutuhkan, masukkan berkas ke dalam folder bernama *User Manual* 60 | 61 | --- 62 | Bacaan tambahan ( gunakan akun Flipbox untuk akses Udemy *course* ) : 63 | 64 | - [Panduan Penggunaan Fabric](https://github.com/flipboxstudio/tech-handbook/blob/develop/fabric-guide.md) 65 | - [Java for Tester](https://www.udemy.com/complete-java-for-test-automation/learn/v4/overview) 66 | - [Selenium WebDriver using Java](https://www.udemy.com/selenium-real-time-examplesinterview-questions/learn/v4/overview) 67 | - [Katalon Studio Tutorial](http://toolsqa.com/katalon-studio-tutorial/) -------------------------------------------------------------------------------- /redmine-scrum.md: -------------------------------------------------------------------------------- 1 | # Penggunaan Redmine dan SCRUM 2 | 3 | Bagian ini berisi tentang proses SCRUM yang berjalan di Flipbox, dan penerapannya di sistem kolaborasi yang digunakan ( Redmine ) 4 | 5 | --- 6 | ### SCRUM @ Flipbox 7 | 8 | 9 | SCRUM di Flipbox terbagi ke dalam beberapa proses utama 10 | 11 | - **_Requirement Gathering_** : Pembuatan konsep awal yang menghasilkan dokumen SRS dan _Backlog_ yang berisi _User Stories_ ( dapat dilihat di bagian Panduan System Analyst ) 12 | - **_Sprint Planning_** : Proses perencanaan sprint yang menghasilkan dokumen _Technical Specification_ ( selanjutnya akan disebut _Tech Spec_ ) 13 | - **_Pre Grooming_** : Proses diskusi _Tech Spec_ untuk menyamakan pendapat dan meminimalisir resiko salah asumsi 14 | - **_Grooming_** : Proses perencanaan sprint berjalan. Dalam proses ini dilakukan _Poker Planning_ untuk menentukan bobot setiap _Story_ yang telah ditentukan sebelumnya 15 | - **_Sprint_** : Proses pengembangan sistem berdasarkan _Stories_ yang telah ditentukan sebelumnya 16 | - **_Daily Standup_** : Proses diskusi di awal hari mengenai proses dan kendala yang dihadapi dalam pengembangan. Lihat deskripsi lebih lanjut di [Koordinasi Harian](https://github.com/flipboxstudio/tech-handbook/blob/develop/daily-coordination.md) 17 | - **_Sprint Retrospect_** : Proses evaluasi _Sprint_ sebelumnya. Dalam proses ini akan dilakukan identifikasi masalah dan solusi yang harus dilakukan ke depannya. 18 | 19 | --- 20 | ### REDMINE @ Flipbox 21 | 22 | Dalam proses menjalankan SCRUM, Flipbox menggunakan sistem kolaborasi yang bernama REDMINE. Berikut adalah hal hal penting yang harus dipahami dalam penggunaan REDMINE 23 | 24 | **JENIS TASK** 25 | 26 | - ***Story*** : pekerjaan terkait fitur yang akan dikembangkan 27 | - ***Task*** : pekerjaan kecil pendukung fitur / pecahan *Story* yang akan dikembangkan 28 | - ***Bug*** : pekerjaan terkait ketidaksesuaian atau kesalahan dalam fitur yang telah dikembangkan 29 | - ***Hotfix*** : adalah *Bug* yang muncul saat sistem telah digunakan ( *in production* ) dan harus segera diselesaikan secepatnya. 30 | - ***Improvement*** : pekerjaan yang akan memperbagus fitur yang telah dikembangkan 31 | 32 | **STATUS TASK** 33 | 34 | - ***New*** : cukup jelas 35 | - ***In Progress*** : sedang dalam pengerjaan. pengembang diharapkan mencatat waktu pengerjaan melalui fitur *log time / WorkTime* 36 | - ***Resolved*** : pekerjaan sudah selesai dan bisa dilakukan testing oleh QA pada *staging server* atau *beta distribution platform* 37 | - ***Pending*** : pekerjaan ditunda karena ada faktor penghambat 38 | - ***Feedback*** : terdapat hal yang kurang jelas yang harus ditanyakan, diwajibkan untuk meninggalkan komentar/pertanyaan kepada PM 39 | - ***Re-open*** : pekerjaan tidak lulus hasil uji QA dan membutuhkan perbaikan, diwajibkan untuk meninggalkan komentar terkait perbaikan yang dibutuhkan. 40 | - ***Closed*** : pekerjaan lulus hasil uji QA dan siap untuk digunakan. 41 | - ***Rejected*** : pekerjaan tidak akan dikerjakan karena ada beberapa faktor tertentu. 42 | 43 | **PRIORITAS TASK** 44 | 45 | - ***Low*** 46 | - ***Normal*** 47 | - ***High*** 48 | - ***Urgent*** 49 | - ***Immediate*** 50 | 51 | Selengkapnya dapat dilihat di dokumen [SOP Redmine](https://docs.google.com/presentation/d/1w2kwv066bAktqGxvwLaVD5VkBwsNNFb93iPZj0iJkLA/edit#slide=id.g128f9841ee_0_82) 52 | -------------------------------------------------------------------------------- /software-analysis.md: -------------------------------------------------------------------------------- 1 | # Panduan untuk *System Analyst* 2 | Bagian ini berisi mengenai deskripsi dokumen analisis yang ada di Flipbox, proses dan kesepakatan yang berlaku di Flipbox. 3 | 4 | --- 5 | 6 | ### Dokumen *Software Requirement Specification* 7 | 8 | Merupakan dokumen hasil analisis kebutuhan sistem yang diinginkan oleh pengguna. Dokumen ini berisi garis besar pembuatan sistem dan asumsi awal yang diberikan. Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Docs -> From a template* ) 9 | 10 | Beberapa hal yang perlu dianalisis dalam dokumen ini adalah : 11 | 12 | - Deskripsi singkat sistem yang akan dikerjakan, tujuan pembuatan sistem dan asumsi awal yang diberikan 13 | - Fitur utama yang terdapat di dalam sistem 14 | - Tipe pengguna di dalam sistem 15 | - Teknologi yang akan digunakan dalam pembuatan sistem 16 | - Diagram basis data (ERD) / *Class diagram* 17 | - Penjelasan entitas sistem 18 | - Daftar Pustaka / referensi 19 | 20 | Masukkan dokumen SRS ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 21 | 22 | - *Parent Folder* : [NAMA PROJECT] Software Analysis 23 | - Nama folder : SRS 24 | - Nama berkas : SRS [Nama Project] [Platform] 25 | 26 | --- 27 | ### Dokumen *Product Backlog* 28 | 29 | Merupakan dokumen hasil penjabaran analisis ke dalam deskripsi singkat fitur-fitur yang akan diimplementasikan (*user stories*). Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Sheets -> From a template* ) 30 | 31 | Format *user stories* yang digunakan adalah 32 | `As a , I can ` atau bisa disingkat ` can `. 33 | > Contoh : Admin can create user, Customer can buy products, dan lain lain. 34 | 35 | Masukkan dokumen *Product Backlog* ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 36 | 37 | - *Parent Folder* : [NAMA PROJECT] Software Analysis 38 | - Nama folder : PRODUCT BACKLOGS 39 | - Nama berkas : Product Backlog [Nama Project] [Platform] 40 | 41 | --- 42 | ### Dokumen *Tech Spec* 43 | 44 | Kepanjangan dari *Technical Specification*, dokumen ini berisi penjabaran setiap item dalam *Product Backlog* menjadi lebih detail dalam aspek teknis implementasi. Dokumen ini dibuat untuk mendukung *sprint* yang akan berjalan. Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Docs -> From a template* ) 45 | 46 | Beberapa hal yang perlu dianalisis dalam dokumen ini adalah : 47 | 48 | - Deskripsi dan tujuan *sprint* 49 | - Tujuan *story* 50 | - Data yang akan masuk ke dalam sistem 51 | - Data yang akan dikeluarkan oleh sistem 52 | - Alur kerja dari *story* yang akan diimplementasikan 53 | - Penjabaran kasus yang memungkinkan terjadinya *error* dan penanganannya 54 | - Validasi sistem 55 | - Interaksi dengan sistem lain ( apabila ada ) 56 | - Aturan / batasan tambahan yang harus diperhatikan 57 | 58 | Masukkan dokumen *Tech Spec* ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 59 | 60 | - *Parent Folder* : [NAMA PROJECT] Software Analysis 61 | - Nama folder : TECH SPECS 62 | - Nama berkas : Tech Spec [Nama Project] [Platform] 63 | 64 | --- 65 | 66 | ### Dokumen *Technical Test Specification* 67 | 68 | Merupakan dokumen kolaborasi antara *System Analyst* dengan *Quality Assurance*. Dokumen ini menggabungkan antara *Tech Spec* dengan *Test Case* agar didapatkan proses yang efisien tanpa mengurangi kualitas dan informasi yang didapatkan dalam kedua dokument tersebut. Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Sheets -> From a template* ) 69 | 70 | *Technical Test Spec* dibuat untuk proyek yang sudah biasa dikerjakan dan tidak memiliki tingkat kesulitan khusus. 71 | 72 | Di dalam dokumen ini terdapat *sheet Tech Spec* yang akan diisi oleh *System Analyst*. 73 | 74 | Masukkan dokumen *Tech Spec* ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 75 | 76 | - *Parent Folder* : [NAMA PROJECT] QUALITY 77 | - Nama folder : Technical Tech Spec 78 | - Nama berkas : TTS [Nama Project] [Platform] 79 | 80 | --- 81 | ### Dokumen *Tech Doc* 82 | 83 | Kepanjangan dari *Technical Documentation*, dokumen ini berisi penjabaran teknis dari sistem yang telah diimplementasikan. Pembuatan dokumen ini dapat dilakukan dengan menggunakan *Google Drive Template* ( *New -> Google Docs -> From a template* ) 84 | 85 | Beberapa hal yang perlu dijabarkan dalam dokumen ini adalah : 86 | 87 | - Deskripsi & Tujuan modul yang telah dibuat 88 | - Deskripsi & Tujuan *user story* yang ada di dalam modul terkait 89 | - Proses yang berjalan dalam *story* terkait dan dilengkapi dengan diagram proses 90 | - Tampilan terkait proses yang telah dijabarkan dan interaksi yang ada di dalam tampilan tsb 91 | - Basis data yang digunakan dalam implementasi *story* terkait 92 | - Pesan dan kombinasi *error* yang telah diimplementasikan 93 | 94 | Masukkan dokumen *Tech Doc* ke dalam drive folder dengan menggunakan penamaan sebagai berikut : 95 | 96 | - *Parent Folder* : [NAMA PROJECT] Software Analysis 97 | - Nama folder : TECH DOCS 98 | - Nama berkas : Tech Doc [Nama Project] [Platform] 99 | 100 | --- -------------------------------------------------------------------------------- /web-development.md: -------------------------------------------------------------------------------- 1 | # Panduan untuk *Web Developer* 2 | Bagian ini berisi mengenai panduan untuk membuat kode baik, penjelasan arsitektur dan pustaka yang ada dan/atau digunakan di Flipbox. 3 | 4 | --- 5 | 6 | ### Panduan *API* 7 | 8 | API di Flipbox dibuat menggunakan panduan yang ada di dalam dokumen [API Standard](https://github.com/flipboxstudio/tech-handbook/blob/develop/api-standard.md) 9 | 10 | --- 11 | ### PHP-Flip : Standar arsitektur untuk PHP 12 | 13 | PHP-Flip merupakan standar arsitektur untuk pembuatan API berbasis PHP yang dikerjakan oleh Flipbox. Sangat dianjurkan untuk proyek dengan kompleksitas yang cukup tinggi. 14 | 15 | Lihat deskripsi selengkapnya di [PHP Flip](https://github.com/flipboxstudio/php-flip) dan [Panduan PHP-Flip](http://flipbox.co.id/career/) 16 | 17 | #### Pustaka : Lumen Generator 18 | Lihat selengkapnya di [lumen-generator](https://github.com/flipboxstudio/lumen-generator) 19 | #### Pustaka : Image Controller 20 | Lihat selengkapnya di [image-controller](https://github.com/flipboxstudio/image-controller) 21 | 22 | --- 23 | ### .NET Core Boilerplate 24 | 25 | Merupakan *starter* untuk pembuatan API yang dibuat menggunakan ASP.NET Core. Beberapa pustaka utama dan contoh penggunaannya sudah terkandung di dalam *starter* tersebut. 26 | 27 | Lihat deskripsi selengkapnya di [.NET Core Boilerplate](https://github.com/flipboxstudio/boilerplate) dan [Panduan .NET Core](http://flipbox.co.id/career/) 28 | 29 | --- 30 | ### Progressive Vue 31 | 32 | Merupakan *starter* untuk pembuatan *Single Page Web Application* berbasis *VueJS* dan *Progressive Web App*. Beberapa pustaka utama dan contoh penggunaannya sudah terkandung di dalam *starter* tersebut. 33 | 34 | Lihat deskripsi selengkapnya di [Progressive Vue](https://github.com/flipboxstudio/progressive-vue) dan [Panduan VueJS](http://flipbox.co.id/career/) 35 | 36 | --- 37 | ### *Deployment Checklist* 38 | 39 | - SSL sudah terpasang 40 | - API sudah melewati *stress test* 41 | - Tidak ada variabel yang masih menggunakan `development environment` 42 | - API & server monitoring sudah terpasang 43 | - *Frontend* sudah melakukan optimalisasi *page speed* dan *SEO* 44 | - *Analytics* sudah terpasang dengan baik dan benar 45 | - Jangan lupa berdoa setelah berusaha 46 | 47 | --- 48 | Bacaan tambahan ( gunakan akun Flipbox untuk akses Udemy *course* ) : 49 | 50 | - [ASP.NET MVC](https://www.udemy.com/the-complete-aspnet-mvc-5-course/learn/v4/overview) 51 | - [Understand TypeScript](https://www.udemy.com/understanding-typescript/learn/v4/overview) --------------------------------------------------------------------------------