Chia sẻ kinh nghiệm về tái cấu trúc phần mềm (Software Refactoring)

Tham khảo thông tin về series Techtalk của Grokking: www.grokking.org/techtalks/
----
Talk 2: Software Refactoring
- Speaker: Thành Đinh - Cofounder & Chief Architect @ Holistics.
- Language: Tiếng Việt
- Description: Mặc dù lĩnh vực phần mềm đã phát triển nhanh chóng trong những thập kỷ gần đây, chúng ta vẫn chưa có được giải pháp để đánh giá ưu điểm và nhược điểm của một bản thiết kế phần mềm. Trong chủ đề lần này, anh Thành sẽ giới thiệu đến các bạn một framework để có thể dễ dàng đánh giá một phần mềm có được thiết kế hiệu quả hay không cùng những bước để tái cấu trúc và cải thiện chúng dựa trên cách tiếp cận của object oriented và functional programming.
Bài chia sẻ lần này cũng giới thiệu một cách để kết hợp tất cả các ý tưởng lại với nhau để xây dựng một phần mềm.
- Giới thiệu diễn giả: Anh Thành hiện đang làm việc tại Holistics Software, anh là Co-founder và cũng là Chief Engineer đang xây dựng một kiến trúc mới dành cho BI platform dựa trên những nguyên lý của DataOps.
Trước khi tham gia Holistics, anh đã có hơn 8 năm kinh nghiệm trong nghành phần mềm và big data consultant cho nhiều công ty, trong đó có Revolution Analytics đã được mua lại bởi Microsoft năm 2015.
Anh tốt nghiệp NUS năm 2009 chuyên ngành Computer Engineering
Slides: www.slideshare.net/GrokkingVN...
----
Xin cảm ơn hai nhà tài trợ VNG (www.vng.com.vn/) và Holistics (www.holistics.io/) đã tài trợ kinh phí thực hiện video này.
Timeline:
00:00 - Giới thiệu vấn đề liên quan đế độ phức tạp của phần mềm
02:04 - Liệu có cần phải có class inheritance trong lập trình hướng đối tượng không?
06:09 - Agenda
07:14 - Chứng minh class inheritance không nhất thiết cần phải có trong lập trình hướng đối tượng!
15:30 - OOP không hẳn phải có class và cần có inheritance, có thể tiếp cận theo hướng message sending
17:15 - Sự phức tạp của hệ thống phần mềm là nguyên nhân của mọi vấn đề liên quan đến software design
19:45 - Hai loại complexity: Essential (độ phức tạp của nghiệp vụ) và Accidental (sự phức tạp do thiết kế của mình gây ra)
20:44 - 5 tiêu chí để đánh giá xem phần mềm được thiết có độ phức tạp như thế nào?
27:34 - 2 cách để quản lý sự phức tạp: tìm cách thiết kế để giảm độ phức tạp (reduce) hoặc đóng gói sự phức tạp lại (isolate).
- OOP: giúp gói sự phức tạp thành các phần nhỏ hơn và độc lập với nhau
- OOP: nhiều lúc lại làm tăng độ phức tạp, không có tác dụng làm giảm mức độ phức tạp của phần mềm
32:29 - Giảm sự phức tạp bằng functional programming
33:53 - Ví dụ về phần mềm làm bánh tiramisu
- Những vấn đề liên quan đến data mutation phát sinh bởi imperative programming và OOP
- Dùng functional programming để điều khiển data flow, giảm độ phức tạp của phần mềm: giảm shared mutable state, không side effect, không có time dependencies,..
44:13 - Mỗi function đều phải tạo ra data mới thì liệu có ảnh hưởng đến performance của phần mềm?
46:07 - Functional programming có thể apply được tốt cho các dự ắn, có loại bỏ hoàn toàn được shared mutable state không?
48:50 - Kết hợp giữ OOP và functional programming: cần xác
50:57 - Refactor game Attack & Defense từ OOP sang Functional Core, OOP Shell, cách thực hiện và lợi ích mang lại

[@lazboi2787]

cảm ơn Grokking.

[@linhnh1980]

Thực ra nếu viết C mình cũng viết theo OOP Concept được nhưng mà nó lâu...
Ngôn ngữ lập trình là công cụ để thực hiện principles/concepts cái nào nhanh tiện thì dùng chứ không phải ta đi gọt cho vừa công cụ. Uncle Bob nói rằng mỗi cách thức lập trình sẽ hạn chế bớt khả năng đi chứ không phải mang lại thêm khả năng, sự trade-off này giúp tăng tốc độ - giảm sự rắc rối.

[@mindcontrolkmc.3286]

Thêm góc nhìn mới Thank Grokking :D

[@futhedude4848]

, quả ví dụ hơi khó thấm, diễn giả cũng chưa show đc ví dụ về phần "best practice khi kết hợp oop và fp là dùng fp viết core, oop thì viết shell".

[@TruongHoang-du9if]

Functional core imperative shell :)

[@namnguyen41]

mấy người làm c# cười ỉa =))

[@minhly650]

Sao C# lại cười ỉa? 😅

[@caotien6446]

ghê vậy :)