Giải pháp nhiều khi thật buồn cười

Lâu lâu nhìn lại code của mình, lại thấy thật buồn cười. Những giải pháp mà mình đã sử dụng thật … điên khùng.

Có rất nhiều giải pháp được mình đưa ra trong những cơn “mộng mị”. Sự thể là do khi giải quyết một vấn đề khó nào đó, thay vì sắp xếp lại các ý nghĩ một cách triệt để, thì mình mặc kệ nó. Chính vì vậy mà những lúc đó, đầu óc dường như rất tập trung mà cũng dường như chẳng biết có cái quái gì trong đó. Nói vậy, chứ cái gì cũng có chừng mực của nó. Khi mà quá nhiều suy nghĩ thừa thải thì cần phải dẹp bỏ nó và đi làm chuyện gì đó để làm, khi đó các suy nghĩ thừa thải sẽ lắn lại. Khi mà chỉ còn lại mỗi suy nghĩ về việc mình đang cần làm, thì đúng là tốc độ cao, nhưng dễ đi vào ngõ cụt, và chỉ có hai kết quả có thể, hoặc là thẳng tới đích hoặc là không bao giờ. Mình vẫn hướng trường hợp thứ hai hơn, chỉ là tâm còn động loạn nhiều quá, khó mà tập trung cao độ được.

Trong cơn “mộng mị” có nhiều giải pháp mà khi qua rồi chẳng thể nhớ hoặc hiểu nổi mình đã làm gì và làm nó như thế nào. Rất nhiều trong số đó, về sau nhìn lại, thấy thật buồn cười. Đúng là lúc nào cũng thấy mình ngu, mà lúc nào cũng thấy mình đúng. Cứ thêm một lần thấy đúng, là tương lai sẽ thêm một lần thấy ngu, kể cả khi thấy mình ngu, thì tương lai nó vẫn ngu như thường.

Nhớ cái lần làm giải pháp cho bài toán truyền tham số khi add hook. Giải pháp có vẻ như khá là awesome cho bài toán này. Một thời gian sau mình thấy WooCommerce cũng giải quyết một bài toán tương tự trong plugin subscription, nhưng của họ là “truyền tham số cho schedule action khi add schedule”. Nếu như giải pháp của mình là serialize các tham số vào tên hàm, thì họ là tạo một posttype, rồi khi mỗi giờ họ sẽ chạy crop để kiểm tra các posttype trong posttype đó để chạy. Giờ nhìn lại, thấy giải pháp của mình vẫn tối ưu hơn của họ, nhưng bù lại, nó quá khó hiểu và khả năng tùy biến cũng rất kém. Thật chả hiểu nổi mình đã làm sao để có cái giải pháp kinh khủng đó nữa.

Rồi một lần khác, là khi mình đang cố gắng viết một theme framework, dạng plugin, cài plugin vào trước sau đó cài theme, trong theme sẽ extends các class trong plugin. Môi trường lúc này là plugin chạy trước theme. Nên theme có thể nhìn thấy plugin, còn plugin thì không nhìn thấy theme được. Cần đặt hàm ae_get_option ở plugin, và mỗi theme sẽ định nghĩa một option key khác nhau. Nhưng mình muốn, là ở cả trong theme khi gọi tới ae_get_option thì nó sẽ gọi bằng key của theme, và khi một plugin khác gọi tới ae_get_option, thì sẽ sử dụng key của plugin đó. Nhưng không được truyền key vào ae_get_option. Nghĩ mãi mới thấy, plugin chẳng có cách nào để nhìn thấy thằng đang gọi mình cả. Chẳng có cơ hội nào để theme có thể add một hook chạy trước plugin để thay đổi key cả. ngoại trừ plugin được hook để chạy sau theme, mình không muốn như vậy. Và cuối cùng giải pháp là hàm ae_get_option sẽ chẳng trả về giá trị nào cả, nó chỉ đơn giản là gọi tới một cái hook. Rồi chỗ nào muốn hồi đáp giá trị, thì tự thân add hook, Tên hook là unique. =)) Giải pháp thật buồn cười, nghĩ tới cảnh các plugin, hook tranh nhau cái tên, rồi bug cho bị xung đột tên hook, thứ tự gọi hook. Rồi còn tốn tài nguyên parse tên của caller để xây dựng hook name. Dù nó là giải pháp duy nhất ở hiện tại, sau này nhìn lại chắc ….

Tựu trung lại, thì tại sao lại không thay đổi các giả thuyết và yêu cầu nhỉ ? Đơn giản vì mình không thích nó như vậy.