Code refactoring

Từ 1 comment status của thằng bạn trên facebook, nhớ lại về nguyên lý thứ hai của nhiệt động lực học. À, mà sao lại nguyên lý thứ hai nhỉ, có nguyên lý thứ nhất không nhỉ?

Học từ hồi cấp 3, bắt đầu từ câu chuyện không thể chế tạo động cơ vĩnh cửu loại 2, tức là động cơ dùng 2 nguồn nhiệt để có thể biến nhiệt hoàn toàn thành công. Tuy không vi phạm định luật bảo toàn năng lượng, nhưng vẫn không làm được.

Hiệu suất lý tưởng để chuyển nhiệt biến thành công chỉ đạt được = (T2- T1)/T2; T1,T2 là nhiệt độ nguồn nóng & lạnh tính theo nhiệt giai Kelvin.
Tại sao lại thế? qui luật gì đã chi phối cái đó. Trong quá trình giải quyết cái đó thì ông cụ Rudolf Clausius đã mang đến một khái niệm gọi là Entropy (kí hiệu là S), bản chất là đặc trưng cho tính hỗn loạn của hệ thống. Chốt lại là qui luật trên sẽ tương đương với việc phát biểu: Entropy của hệ cô lập không thể giảm. Tức là tính hỗn loạn của hệ thống cô lập sẽ tăng hoặc ít nhất là giữ nguyên.
Câu chuyện tưởng đến đây là hết, thì hóa ra mới bắt đầu. Trong lý thuyết thông tin, Shannon định nghĩa lượng thông tin của hệ thống thông qua Entropy, xem ở đây. Hệ thống càng hỗn loạn thì càng chứa nhiều thông tin, hệ thống càng trật tự thì lượng thông tin chứa trong đó càng ít, nghe cũng có lý đấy chứ nhỉ!. Vậy là từ cái máy nhiệt lại liên hệ mật thiết với chủ đề nóng, vấn đề thông tin.

Cái nghề làm phần mềm chắc chắn cũng không ngoài cuộc, vì nguyên lý phổ quát mà, bao trùm từ vũ trụ bao la bát ngát ( xem Lược sử thời gian – Stephen Hawking, thì biết) đến trà đá vỉa hè (cục đá đang tan dần trong cốc trà, chính là biểu hiện của việc Entropy đang tăng). Vậy phần mềm có xu hướng càng ngày càng lộn xộn, và thực tế đúng như thế. Lúc bắt đầu dự án, nếu là dự án tử tế thì basic design, detail design chuẩn mực thật. Nhưng theo tháng năm, ta thêm tí mắm, lâu lâu cho chút muối vào, thi thoảng thêm tí tính năng để phần mềm lúc đầu đặc tính giống Chó nhưng lại muốn bắt đc cả Chuột, và dần dần nó trở thành 1 đống lộn xộn. Và đâu đó cũng có Sofware entropy thật.
Nhưng chú ý, điều đó chỉ đúng với hệ cô lập, và để phần mềm không trở nên thành 1 đống hổ lốn theo tháng năm thì phải tìm cánh phá vỡ tính “cô lập” của nó, một trong những cách đó là REFACTORING, quyển sách cần đọc, nó nằm ở đây.  Mặc dù  không khuyến khích, nhưng trước khi mua sách tử tế thì có thể xem tạm ở đây

Tóm lại từ nguyên lý thứ hai của nhiệt động lực học, ta rút ra rằng để software không bị xuống cấp, ta phải học cách refactoring?

Ngụy khoa học

Khoảng cuối 2013, thằng ku em, giờ đang phD Vật lý ở Pháp, gọi lên viện Vật lý nghe seminar đủ mọi thứ từ Vật lý đến lịch vực nghệ thuật rồi nghe đâu có lúc ra cả Biển Đông… do thầy của nó, GS. Nguyễn Văn Liễn, tổ chức chủ yếu cho học sinh phổ thông, một việc làm rất đáng quí, không rõ đến giờ còn duy trì nữa không.
Giai đoạn đó công việc đang bận nên mình chỉ ghé qua vài lần, nhớ nhất là chuỗi câu chuyện về Feynman, nhà vật lý đa tài người Mỹ, đạt giải Nobel vật lý 1965, tham gia dự án Manhattan (dự án làm bom nguyên tử của Mỹ), học phá khóa két sắt và giải mã kí tự của người Maya làm thú tiêu khiển. Tiện thể xin giới thiệu phương pháp đơn giản để học nhanh kiến thức mới của Feynman ở đây[2], mời các bạn áp dụng để khám phá chân trời kiến thức bao la bát ngát.
Ấn tượng nhất để lại với mình là tính trung thực của Feynman, thể hiện rõ nhất là quá trình tham gia điều tra và đấu tranh với NASA để có báo cáo trung thực về nguyên nhân của vụ tai nạn tàu Challenger[4,5].
Ở đây trích dẫn 1 phần mà bản thân cũng thường hay mở ra xem lại nhất, nói về việc trung thực trong nghiên cứu khoa học, trong quyển “Feynman chuyện thật như đùa!“, do Nguyễn Văn Liễn và Nguyễn Huy Việt dịch từ “Surely you’re joking, mr.Feynman”. Bạn nào tò mò muốn đọc thêm thì có thể mua sách có hình như dưới.

feynman

… Một ví dụ: Milikan đo điện tích của electron bằng thí nghiệm các giọt dầu rơi và thu được kết quả, mà bây giờ ai cũng biết là không thực sự chính xác. Có một chút sai lệch do ông ấy đã dùng giá trị không chính xác của độ nhớt không khí. Thật thú vị khi nhìn vào lịch sử các phép đo điện tích electron được thực hiện sau Milikan. Nếu biểu thị các kết quả đó theo thời gian, bạn sẽ thấy một kết quả lớn hơn Milikan một chút, rồi một kết quả tiếp lại lớn hơn một chút, và cuối cùng chúng qui về một con số lớn hơn.

Vì sao họ lại không phát hiện ra ngay rằng, con số mới là số lớn hơn? Đây là câu chuyện, mà các nhà khoa học phải cảm thấy xấu hổ, bởi vì rõ ràng người ta đã hành xử như thế này. Khi họ thu được một kết quả quá cao so với kết quả của Milikan, họ nghĩ rằng chắc chắn có sai sót nào đó, họ tìm kiếm và rồi cũng tìm ra một nguyên nhân có thể dẫn đến sai sót. Còn, khi họ nhận được kết quả gần hơn với kết quả của Milikan, thì họ không xem xét cẩn thận. Rồi họ loại bỏ những sai lệch nhiều so với giá trị của Milikan, hay làm những việc tương tự như thế. Ngày nay, chúng ta đã biết những xảo thuật này, nên không còn mắc những bệnh như thế nữa.
Tuy vậy, lịch sử lâu dài của việc học cách không tự lừa phỉnh mình – của việc có được trung thực khoa học tuyệt đối là, tôi xin lỗi phải nói, cái mà chúng ta chưa chú tâm đưa vào bất cứ môn học nào, mà tôi biết. Chúng tôi hi vọng là, bạn sẽ học được bằng cách ngấm dần.
Nguyên tắc đầu tiên là bạn không được tự lừa phỉnh chính mình – bạn chính là người dễ bị lừa nhất. Vì thế bạn phải rất thận trọng với điều đó. Sau khi bạn không còn bị lừa phỉnh nữa, bạn sẽ dễ dàng không lừa phỉnh các nhà khoa học khác. Sau đó, bạn chỉ cần trung thực theo cách thông thường.

Tham khảo
[1]https://vi.wikipedia.org/wiki/Richard_Feynman
[2]http://genk.vn/nha-vat-ly-doat-giai-nobel-chia-se-phuong-phap-hoc-nhanh-moi-thu-tren-doi-chi-voi-3-buoc-20161204110349259.chn
[3]https://vi.wikipedia.org/wiki/Dự_án_Manhattan
[4]http://www.feynman.com/science/the-challenger-disaster/
[5]https://www.youtube.com/watch?v=6Rwcbsn19c0