On Mon, 7 Mar 2011, Bùi Thành wrote:
> Dear,
> 2011/3/7 Duong "Yang" Ha Nguyen <cmp...@gmail.com>
> On Mon, 7 Mar 2011, Bùi Thành wrote:
> ...
> > * 2 là, giả sử như có phải refactor, nhưng em thấy công sức để
> refactor rất tốn => không làm. => vẫn chưa giải quyết được vấn đề quản lý mã
> nguồn :D
> >
>
> Công sức refactor có thể tốn nhưng rất đáng.
>
> Nếu "tốn" nhiều hơn "đáng" thì không nên làm :D
>
Theo bác thì thế nào là "tốn" nhiều hơn "đáng"? Nếu ngay từ đầu đã
định sẵn tổ chức rồi thì hầu như cái tốn ấy bao giờ cũng đáng. Chi
phí sửa đôi lúc to hơn chi phí xây nhiều. Nếu không muốn phải sửa
nhiều thì tại sao lúc đầu không xây cho tốt? Không phải rỗi hơi mà
người ta làm ra các công cụ proprietary cực to [1]tiền để phục vụ nhu
cầu tổ chức và refactoring.
>
>
> Refactor là một khâu tối
> quan trọng để giữ mã nguồn có tính maintainability (bảo trì) và
> extensibility (mở rộng), đồng thời tăng chất lượng của cả mã nguồn lẫn
> sản phẩm, giảm tối đa lỗi phát sinh *do con người*. Vấn đề của
> refactoring không nằm ở mặt kỹ thuật mà nằm ở mặt tổ chức. Em không
> tin một sản phẩm nào được coi là "tốt" mà các thành phần của sản phẩm
> đó lại không được tổ chức tốt.
>
> Em thích hiểu "tốt" theo nghĩa kinh tế hơn nghĩa kỹ thuật. Đôi khi
> để có sản phẩm với "thành phần được tổ chức tốt" sẽ trả giá bằng
> thời gian và công sức khiến sản phẩm chẳng "tốt" (kinh tế) chút nào.
> Tương tự cho việc refactoring :D
>
Bác nói như một ông Việt Nam đi quảng cáo đểu vậy. Mặc dù mục tiêu
tối thượng là lợi nhuận nhưng nếu bác chẳng quan tâm đến chất lượng
sản phẩm, chẳng quan tâm đến người dùng thì e rằng cái "tốt" kinh tế
của bác cũng không có giá lắm đâu. Lịch sử đã chứng minh trong câu
chuyện M$ vs. Apple.
>
> Nhìn vào một repo có module riêng biệt, mỗi module có documentation và
> được chia nhỏ theo từng functional unit bao giờ cũng dễ phát triển
> hơn, cho hiệu quả tốt hơn là một mớ hổ lốn code hỗn độn, bạ đâu sửa
> đấy, vô tội vạ. Lập trình cũng giống như viêt văn vậy, lời ý đẹp
> nhưng phải có bố cục rõ ràng mới được gọi là hay.
>
> Vâng, nhưng nhiều khi "văn hay chữ tốt không bằng thằng dốt lắm $" :D
>
> :D Em đùa tí. Ý xuyên suốt của em là về thế nào là "đáng" hay "không
> đáng" làm. Từ việc tổ chức source, việc refactor, document,... đều
> không hẳn là đáng, nhất là với dự án không oss, nhỏ, dễ thay đổi yêu
> cầu.
>
> tkx,
> thanhbv
>
Bác thử đóng vai trò của người sử dụng một phần mềm nhỏ như phần mềm
từ điển thôi nhé. Nếu sản phẩm chạy lỗi liên tùng tục, chính tả sai
lên sai xuống thì suy nghĩ của bác về phần mềm và người phát triển
phần mềm đó như thế nào? Việc gì cũng phải bắt đầu từ cái nhỏ nhặt
trước rồi tăng độ phức tạp và quy mô lên dần dần. Em đồng ý với bác
rằng quy mô nhỏ thì bỏ sức ít; nhưng để xây được nhà cao thì móng phải
tốt cái đã.
My 2 cents.
[1] http://www.jetbrains.com/resharper/
Best regards,
--
Dương "Yang" Hà Nguyễn
Web log: http://cmpitg.wordpress.com/
"Life is a hack"
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GIT/C/ED/L d++ s-:-(:) !a C+++(++++) ULU++++>$ P-- L+++>$ E+++
W++>+++ N+ o+ K w--- O- M@ V- PS+ PE++ Y+>++ PGP++ t+ 5 X+ R-
tv+ b+++ DI+++ D++ G+++ e* h* r* y-
-----END GEEK CODE BLOCK-----
_______________________________________________
POST RULES : http://wiki.hanoilug.org/hanoilug:mailing_list_guidelines
_______________________________________________
HanoiLUG mailing lists: http://lists.hanoilug.org/
HanoiLUG wiki: http://wiki.hanoilug.org/
HanoiLUG blog: http://blog.hanoilug.org/
