kira2 di group ini ada yang kontra dengan TDD ga ya? penasaran sama sudut pandangnya

https://github.com/teknologi-umum/graphene/tree/master/backend/tests

AI, what is TDD?

saya ngga pernah TDD sih

AI, what is Test first programming?

biasanya domain & interfaces first, lalu minimal implementation (with bunch of TODO markers), lalu bikin tests, barulah full implementation

what is the alternative?

ini, imho, masih TDD

TDD bukannya bener bener bikin test nya dulu baru ngoding?

banyak aliran sih, kyk agile banyak aliran, tp pada convergent di Red-Green-Refactor

interface IFoo {
}
Mock
gitu biasanya TDD di C#

kalo bikin domain, interface, minimal implementation, bunch of ToDo, trus coding test, most likely bakal red

saya sih convention driven

ngoding terus. ngga ditest ngga didebug

your strict typing guides & validates your own code

begitu banyak application parts disambung2in, they validate each other

so beautiful OOP itu

nah ini. ternyata saya TDD

eh ga ditest gimana maksudnya mas? ga di run kali ya? tp unit test dijalanin?

ngga juga

kalo pake CA di C#, bisa ngoding berhari2 tanpa didebug tanpa ditest

CA itu static code analysis maksudnya?

clean architecture

dengan convention yang very very strict & domain driven

om seriously ini indonesia mau nerapin whitelist? 😢ane baru baca2 efek2nya ngeri juga web porto jadi gak bisa diakses atau hal2 lainnya kek mau nyari freelance di platform luar kayak upwork

overloaded istilah CA tuh, haha, perlu saya clarify, CA kearah hexagonal / onion, ato CA kearah SOLID?

Ane malah termasuk yang diracun sama om 😂

hexagonal & onion (DDD), sekaligus SOLID, sekaligus OOP, dan install macam2 code analyzer yang galak sekali

saking strictnya, there's only one way to do everything

jangan lupa treat warnings as errors

wkwkwk

Bahas arsitektur yah ane mau nanya sekalian ideal gak sih kalau properti Dto sama repository itu jumlahnya sama jadi kek cuman copy object aja cuman gak sama methodnya

properti yang kamu maksud itu apa?

class yang isinya data?

iyah om

*Dto

ok itu namanya model

tiap aggregate (class yang jadi root di setiap model) biasanya mappingnya 1 to 1 ke repository

nah ini ane masih rada rancu soal model antara domain model sama model kek di mvc

domain model: buat business logic
view model: buat dioper ke view
DTO: buat urusan komunikasi
data model: buat urusan penyimpanan

model bagusnya dipisah2 sesuai concernnya

misal DTO concernnya mikirin gimana model itu diserialize jadi JSON atau protobuf atau messagepack

Oh iyah om pernah bilang ke ane gak masalah yah kita bikin class objek banyak yang berulang.
ane inget

data model concernnya mikirin gimana model itu disimpan di SQL atau database lain

biasanya ini ada kolom yang kurang di data model-nya

kadang orang suka nyampur2

public class Foo {
  [JsonPropertyName("email")]
  [Required, EmailAddress]
  [Key, StringLength(50)]
  public string Email { get; set; }
}

ada urusan json, ada urusan view model, ada urusan database di 1 class

ini ngga boleh

property di DTO, kalo represent suatu domain model yang sama, biasanya lebih sedikit propertinya dibanding data model

https://t.me/CSharpIndonesia/4111
Nah ane nemu ini dulu inget yang om pernah bilang i see isee

misalnya di data model ada CreatedAt, CreatedBy, UpdatedAt, UpdatedBy, DeletedAt, DeletedBy, ini jarang dibutuhin di DTO

Eh iyah aku liat malah dto lebih kurus di sourcenya codeopinion om nah ini yang mau ane tanyain juga yang ideal itu sama jumlahnya atau dto yang lebih sedikit atau sebaliknya gitu 😂

Oh iyah2 ngerti kalau ini om thanks

iya kok, DTO emang seringnya lebih kurus

Gak sia2 nongol di grup dapet daging malem2

network kan lambat dan mahal ya, makin langsing / dikit data yang di transfer, generally better

lebih kurus lah. jangan sampe user login dikirimin email, nama, alamat, nomer hp, hashed password, salt, dan semua setting

tapi om

sepakat om @okitas0uji , sempet bingung juga tp jadi clear baca ini

Tinggal ane research terkait struktur domain model sama data model.
bisa gak sih kita bilang data model itu masuknya ke entities?

domain model harusnya yang paling deket sama spek / business / real world, dan ga dicampur sama implementation detail

kalo dah ada domain model, mikirin gmn caranya model itu disimpen, jadilah data model

kek gini naganya sekarang

Hmm gitu yah ane masih belum masuk bagian ini nih ane nangkepnya domain model itu berkaitannya nnti ke repository sedangkan data model itu nnti larinya ke entities.
#cmiiw

jadi telegram itu rada2 hack di feature itu ya

if (fileExtension == "webp"){
showAsSticker(picture);
}

yes. ngeselin karena gambar dari google image rata2 webp

saya kurang paham statement ini

repository itu baca data model, direturn sebagai domain model, atau sebaliknya. domain model disave jadi bentuk data model

aga rancu saya baca ini, tp mungkin buat klarifikasi, data model boleh keluar dari repository ga mas?

ngga boleh

core — repository — db

• domain model cuma boleh dipake di core
• data model cuma boleh dipake di db
• repository boleh pakai keduanya

repository jadi jembatan. jadi detail implementasi gimana cara read & write

Nah iyah gini maksud aku om jadi yang handle si domain model ini si repositorynya ane ngutip dari sini om.

The repository is implemented in the domain layer, because it works with domain objects. But in the domain layer we should have no idea about any database nor any storage, so the repository is just an interface.
https://svatasimara.medium.com/domain-driven-design-part-5-repository-d5ad32b2e06f

kalau mau dipecah lebih jauh:

• domain model
• repository interface
• repository implementation
• data model

Nah iyah berarti bener yah om kalau data model itu berkaitan sama entities.

di repository interface cuma boleh ada domain model
di repository implementation boleh ada both domain model dan data model

untuk memastikan mana yang boleh mana yang ngga boleh, paling enak pake project system

tp berarti harusnya di method signature repository ga boleh ada data model kan mas?

betul

IRepository tempatnya di core project?

iya

Kalau ane ambil kesimpulan singkatnya gini.
Repository : itu tentang bagaimana data disimpan.
Entities itu : tentang bagaimana proses menyimpan data kek transactional dsbnya.
#cmiiw

mungkin kurangin istilah entities itu om, bikin bingung

Data model dan domain model lebih gampang dipahamin

entity itu buat magic

wkwkwk

Ane bingung nyebutin istilah persistence proses om yang berkaitan sama db

Soalnga kalau mengacu ke client architecture bagian ini disebutnya entities

data model = entities, gitu ga si?

karena saya ngga paham entities, saya selama ini asumsinya begitu

AI, what is entities in context of data persistence?

canggih

so... magic

itu pattern yang saya hindari (entities). kecuali kalau berurusan dengan orleans

AI, give me the synonyms of entity

Ane mengacunya disini om

kalo yang kuning itu domain model

lol

tiap orang istilahnya beda2

Entity: In clean architecture, entity means the business logic. Different from the entity in domain-driven design, the entity here can be realized as the domain in domain-driven design.

Ah iyah akwkw

mulai sekarang gw bakal pakai* Creature*

Tapi beberapa ngebedain karena definisi ini sih om berkaitan sama data persistence

AI, what is the structure of clean architecture

pengen rasanya ngasih contoh. tapi projectnya ngga ada

its not that simple

no, clean architecture does not guarantee modularity and flexibility

it does

this is my kind of architecture

Ini yang ane pahamin juga om

ada 1 pojokan ilmu CA yang namanya decorator pattern

CA bisa di implement tanpa DDD mas

Jadi data model itu yah nnti berkaitan langsung sama entities

yang contohnya selalu toping pizza, wkwkwk

itu enak banget buat modularity

bukannya beverages ya? hehe

Ini yg diomongin banyakan buat implement di OOP?

yes

untuk saat ini asumsi ane begitu sma kek om @RonnyGunawan tapi siapa tau ada yang bisa ngasih pencerahan lain 😂

buat tidur lebih nyenyak.
oh.. pilihan gw ada yang setuju

Ane belum nyentuh OOP lgi, agak bingung nyimak dritdi🤣
Tp daging juga wkwk

ya saya taunya entity framework buat database, ya sudah entity = data model WKWKWKWK

padahal aslinya EF itu harus dijinakkan pakai repository pattern

nah iya, persis

biar beneran cuma dipake untuk db

bukan keperluan lain

akwkw iyah ane baru bener2 paham sedikit soal clean architecture ini semenjak nyemplung di dotnet

typescript juga enak dipake buat CA

Hmm gw punya pengalaman lumayan unik sih. Tapi ya ini kalo bisa gw ambil lesson learned nya juga sebetulnya bukan salah di 100% code coverage nya

Jadi code coverage tinggi, near 100%. Yang terjadi adalah bukannya pusing sih, tapi feels rigid

100% code coverage yang dikejar for the sake of coverage maybe?

Okelah, not all of us code the test correctly

Tapi at some point it become increasingly difficult to change thing

Tanpa rewrite a huge chunk of the test

red-green-refactor ga codebase itu awalnya dibuatnya? ato unknown?

Jadi actually kalo mau beneran kejar setinggi itu, ya better make sure semua punya expertise dan knowledge yang strong sih

Pretty much project itu pas dikerjain campuran TDD sama code test along the way

typescript somehow rasanya kayak C# dan F# digabung, lebih enak buat FP daripada C#, cmiiw

But then again, 1 orang make a mistake gitu ya, entah methodnya jelek terus dipaksain unit test, atau test nya simply jelek

Itu amplified

Dulu waktu di django, go sama php cuman sekedar nerapin dikit design patern tapi belum bener2 terstruktur asalkan busnis logic bisa di test ywdh.
tapi pas ngulik c# wah ini bahasa bener2 pure objek oriented banget apa2 harus lewat object gak bisa instan kek bahasa sebelah😂akhirnya ketagihan

Jadinya itu somewhat ngecause other trouble

saya pernah lho. udah yakin banget codenya ngga ada bug, semua case yang rawan udah masuk coverage, sisa test case saya list sebagai TODO. eh besok2nya ada bug, pas dicek ternyata bugnya di bagian yang belum ditulis unit testnya

Yang mana si rigidness tadi yang paling berasa efeknya

menarik, thx input-nya mas

Jadi ada lah ya yang misal bikin test nya too tightly coupled sama implementation

Misal 1 orang bikin kayak gitu. Nah orang yang build on that unit jadi kena dampak semua

Lama2 merembet sampe it's impossible to change a little bit without rewrite a huge chunk of code and tests

Nah tapi when being done correctly, wah cantik banget

Semakin malem semakin mantep bahasannya 😂ane ngetest selama ini cuman ngandelin assertion bawaan aja

Di kantor yg sama, another project yang orangnya lebih dikit dan jadinya gampang koordinasi dan naikin standard nya

moral story, jumlah per tim jangan banyak2? haha

Itu ada code yang cuma di code 1x, sampe gw cabut dari kantor itu mungkin kalo diitung jumlah changes nya ga sampe 10x

For the lifetime of the project selama gw disitu

Jadi add functionality, dll semua smooth

Ga ada yang bentrok, ga ada yg feels rigid, dll

Ga juga. Multiple variables lah

Di satu sisi writing test itu masih skill yang ga banyak dev indonesia kuasai

the very definition of software, its soft thus easy to change

Secara bener ya, bukan cuma asal bisa nulis test

Karena yah banyak magicnya soal ini om kek ngandelin assertion aja beres 😂ane baru tau pentingnya test yang baik aja dari obrolan ini

ya ini spektrum lah, cuma belief saya saat ini, any kind of test its better than no test at all

Jadi kalo berani mau test ngejar 100%, better make sure the code is at high standard

Kalo yang code testnya masih mengandung "anti-patterns" ya it will make things difficult down the road

Jadinya again, ga pusing. Tapi rigid

belom ngerti sih justifikasinya harus ngejar 100%. kalo tinggi, paham, tp 100%? belom dapet why-nya

Pusingnya itu datang dari rigidnya. Kayak anjay where do I even start

Dan baru mau nerapin tdd setelah diracun om @Ramad987

Semua kalo gw colek codenya, yang lain ikut broken

Leave no path untested I guess?

at the expense of false sense of confidence

OCD

noted, thx om

Yes, but again one could argue bahwa kalo code nya is so good, then all codes adalah meaningful code, bukan "noise" jadinya 100% of the code actually do something significant jadinya testnya harus di 100%

btw sebenarnya testing itu tugas QA atau developer sih? Om

But again, it takes some level of expertise buat bisa nulis code sebagus itu dan nulis test yang sama bagusnya

biasanya apa? imperative?

unit test? dev, you code it, you test it

Karena kalo kepeleset dikit, bakal amplified jeleknya itu ke part code yg lain

Pengalaman gw sih gitu ya

might be a hard question, better to write bad test or, knowing one will write a bad one, not writing test at all?

Kan ga harus ada di ujung extreme. Kita di tengah, write test, but also ada room buat make mistakes

kalo kata Uncle Bob, QA seharusnya found no issue in our code

ah yes, make sense

Bukannya mendukung mistakes so it can be made ya, tapi sediain room karena nobody is perfect

kalian nanti pagi ga kerja?