markdown:
- Đăng tin ưu tiên
-
__Các dịch vụ ưu tiên trên Rồng Bay__
-
__Ưu đãi cho khách hàng thường xuyên__ [Sử dụng tài khoản chuyên nghiệp](http://rongbay.com/su-dung-tai-khoan-chuyen-nghiep.html)
-
__Ðăng tin thu hút khách hàng__ [Cách viết tiêu đề thân thiện, lôi cuốn khách hàng](http://rongbay.com/Cach-viet-tieu-de-than-thien-loi-cuon-khach-hang-fp39.html)
-
[Hỏi & đáp](http://rongbay.com/faqs.html)
- Hỗ trợ
- Nếu bạn cần hỗ trợ, vui lòng liên hệ
-
Điện thoại : **(024) 73095555**(ext: 497 / 496 / 495) Hotline : **0936 194 226**(Nội dung, tin đăng) **0932 223 656**(Liên hệ quảng cáo) : [lienhe@rongbay.com](mailto:lienhe@rongbay.com) Skype : [cskh.rongbay](skype:cskh.rongbay?chat)
-
[Mua quảng cáo](http://rongbay.com/mua-quang-cao.html) [Đăng ký](javascript:void(0);) [Đăng nhập](javascript:void(0);)

Server: Zamba VCCorp


markdown:
(Nhà máy thuỷ điện Sê San 4 là một trong những công trình trọng điểm quốc gia được khởi công xây dựng vào tháng 11/2004 trên sông Sê San thuộc địa phận 02 tỉnh Gia Lai và Kon Tum. Tổ máy số 1 hoà lưới quốc gia vào ngày 28/09/2009, Tổ máy số 2 phát điện ngày 08/12/2009, Tổ máy số 3 phát điện ngày 20/03/2010).
Ngành nghề kinh doanh của Công ty:
- Sản xuất, truyền tải và phân phối điện; lắp đặt hệ thống điện và sửa chữa thiết bị điện.
- Giáo dục nghề nghiệp; hoạt động kiến trúc và tư vấn kỹ thuật có liên quan.
- Buôn bán vật liệu, lắp đặt thiết bị khác trong xây dựng; khai thác đá, cát, sỏi, đất sét.
- Dịch vụ lưu trú ngắn ngày; nhà hàng và các dịch vụ ăn uống phục vụ lưu động; cung cấp dịch vụ ăn uống theo hợp đồng không thường xuyên với khách hàng (tiệc cưới, hội họp, đám cưới).
- Dịch vụ ăn uống khác; dịch vụ phục vụ đồ uống.
- Dịch vụ hỗ trợ liên quan đến quảng bá và tổ chức tua du lịch.
- Xuất nhập khẩu nhiên liệu, nguyên liệu, vật tư thiết bị ngành điện; đầu tư kinh doanh cơ khí điện lực, gia công cơ khí.
Công ty gồm có các đơn vị trực thuộc sau:
- Văn phòng;
- Phòng Kế hoạch - Vật tư;
- Phòng Tổ chức - Nhân sự;
- Phòng Kỹ thuật;
- Phòng Tài chính - Kế toán;
- Phòng Thanh tra - Pháp chế
- Phân xưởng Vận hành;
- Phân xưởng Sửa chữa Cơ khí - Thủy lực;
- Phân xưởng Sửa chữa Điện - Tự động;
- Khách sạn Sê San.
Hình ảnh hoạt động Công ty
Hình ảnh Xây dựng nhà máy thủy điện Sê San 4
Hình ảnh Sửa chữa thiết bị
Công ty Phát triển Thủy điện Sê San.
Địa chỉ: 114 Lê Duẩn - Pleiku - Gia Lai.
ĐT:(0269)3514118. Fax:(0269)2222369 - (0269)3877279. Email: evnhpc.sesan@gmail.com

WARC-Type: response

Content-Type: application/http; msgtype=response

WARC-Identified-Payload-Type: application/xhtml+xml

Cache-Control: private

Content-Type: text/html; charset=utf-8

Set-Cookie: LangInfo_Ducnm=Lang=vi-VN; expires=Sat, 23-Sep-2017 08:08:17 GMT; path=/

X-Powered-By-Plesk: PleskWin

Connection: close


markdown:
##
[Sim Gmobile đầu số 0994 tại Phường An Lạc Quận Ninh Kiều TP Cần Thơ](http://simmobifonegiare.simsomobi.com/2014/04/sim-gmobile-au-so-0994-tai-phuong-lac.html)
Sim Gmobile Giá bán VND
|0994161168||936.000|
|0994146246||936.000|
|0994846568||936.000|
|0994699711||912.000|
|0994700433||912.000|
|0994700115||912.000|
|0994699433||912.000|
|0994704030||912.000|
|0994559468||912.000|
|0994696722||912.000|
|0994698910||912.000|
|0994699400||912.000|
|0994730630||900.000|
|0994684404||900.000|
|0994684864||900.000|
|0994794468||900.000|
|0994559522||900.000|
|0994799792||900.000|
|0994799790||900.000|
|0994559544||900.000|
Bấm chuột để liên hệ hoặc xem thêm:
**sim so dep 0994**
## 0 nhận xét:
## Đăng nhận xét

Server: GSE

X-Content-Type-Options: nosniff

Cache-Control: private, max-age=0

X-XSS-Protection: 1; mode=block

Content-Type: text/html; charset=UTF-8


markdown:
Trang chủ
|
Giá cước
|
Cài đặt 3G/GPRS
|
Hỗ trợ Online:
cskh_sms_vn
1900561588
CLIP
Nhạc chuông
Hình nền
Hình động
Game
Logo màu
Logo đen trắng
HÌNH ĐỘNG
Thương hiệu
Người mẫu
Ấn tượng 3D
Siêu xe
Hài Hước
Cung hoàng đạo
Kinh dị
Các loài hoa
Giáng sinh
Game Online
Sinh nhật
Valentine
Hoạt hình
Anime
Avatar
Chúc mừng
Baby
Động vật
Audition
Ngẫu hứng
Girl kute
Pucca ngộ nghĩnh
FA HOA24291 MãSố
NGẪU HỨNG
62819
62818
62817
62816
62815
62814
62813
62812
62811
62810
62809
62808
62572
62571
62565
62564
62563
62562
62561
62560
62559
62558
62557
Hình động Thương hiệu
,
Hình động Hài hước
,
Hình động Kinh dị
,
Hình động Hoạt hình
,
Hình động Ngẫu hứng
,
Hình động Girl kute
,

WARC-Truncated: length

WARC-Identified-Payload-Type: text/html

X-Powered-By: Servlet/2.5 JSP/2.1


markdown:
# Mã sạch
Bạn đang đọc cuốn sách này bởi hai lý do. Đầu tiên, bạn là một lập trình viên. Thứ hai, bạn muốn trở thành một lập trình viên tốt hơn. Tốt rồi. Chúng ta cần lập trình tốt hơn.
Cuốn sách này viết về điều đó – lập trình tốt – và đầy những mã lệnh. Chúng ta sẽ soi xét mã lệnh theo nhiều hướng khác nhau. Ta sẽ nhìn mã từ đầu đến cuối, ngước lên nhìn mã từ dưới lên trên và lần theo các khối lệnh từ trong ra ngoài. Khi làm được điều đó thì ta sẽ hiểu rất nhiều điều về mã. Thêm vào đó, ta có thể kể ra sự khác biệt giữa mã tốt và mã tồi. Chúng ta sẽ biết cách viết mã tốt. Và chúng ta sẽ biết cách biến mã lệnh xấu thành mã lệnh tốt.
## Tương lai sẽ có lập trình
Ai đó có thể cho rằng sách toàn nói về mã đã là thứ gì đó lỗi thời – rằng bây giờ mã đã không còn là vấn đề nữa, rằng ta nên quan tâm tới những mô hình và yêu cầu thì hơn. Thực tế thì một số người cho rằng thời đại chúng ta bây giờ đang tiến gần tới sự kết thúc của việc viết mã. Sẽ sớm tới ngày tất cả các mã lệnh sẽ được tự động tạo ra thay vì phải viết. Rồi thì đơn giản là sẽ không còn cần tới lập trình viên nữa – bởi vì những người kinh doanh sẽ tạo ra chương trình từ những chi tiết kỹ thuật.
Vớ vẩn! Chúng ta sẽ không bao giờ thoát khỏi mã lệnh. Bởi vì mã lệnh đại diện cho các chi tiết của yêu cầu. Có những chi tiết ở một vài mức độ thậm chí không thể bỏ qua hay trừu tượng hóa được mà phải được đặc tả rõ ràng. Và quá trình đặc tả những yêu cầu thành những chỉ thị mà máy tính có thể thực thi được thì chính là sự lập trình. Một đặc tả như vậy chính là mã lệnh.
Tôi mong rằng mức độ trừu tượng của các ngôn ngữ lập trình sẽ tiếp tục tăng. Tôi cũng hi vọng rằng sẽ có thêm nhiều ngôn ngữ miền cụ thể (Domain-specific language*) hơn nữa. Đó là một điều tốt. Nhưng chúng sẽ không loại bỏ việc viết mã. Thực tế là tất cả những đặc tả được viết bằng những ngôn ngữ miền cụ thể cấp cao hiện nay vẫn là mã. Nó vẫn cần chặt chẽ, chính xác và đủ formal và chi tiết để máy móc có thể hiểu và thực thi nó.
Những người tin rằng mã lệnh sẽ tuyệt chủng thật sự giống như là những nhà toán học hi vọng có một ngày họ có thể nghiên cứu toán học mà không cần dùng tới các công thức. Họ cũng có một ước mơ, rằng một ngày sẽ tìm ra cách để tạo ra các cỗ máy có thể làm những gì chúng ta muốn thay vì những gì chúng ta nói. Những cỗ máy này sẽ phải hiểu chúng ta tốt tới nỗi chúng có thể dịch những yêu cầu mơ hồ thành một chương trình đáp ứng những yêu cầu đó một cách tuyệt vời.
Điều đó sẽ không bao giờ xảy ra. Thậm chỉ cả loài người với tất cả trực giác và khả năng sáng tạo của mình cũng không thể tạo ra những hệ thống thành công từ những cảm giác mơ hồ của khách hàng. Trên thực tế, nếu việc đặc tả các yêu cầu có thể dạy chúng ta điều gì, thì đó là một đặc tả tốt bao giờ trông cũng giống như mã và có thể đóng vai trò như những kiểm thử chạy được luôn của mã đó.
Nhớ rằng mã lệnh suy cho cùng thật ra là ngôn ngữ để chúng ta diễn đạt các yêu cầu. Chúng ta có thể tạo ra những ngôn ngữ lập trình gần với yêu cầu hơn. Ta cũng có thể tạo ra các công cụ giúp ta phân tích và ráp những yêu cầu thành các cấu trúc chuẩn. Nhưng ta sẽ không bao giờ được loại bỏ sự chính xác thiết yếu – và thế là, mã sẽ mãi luôn tồn tại.
## Mã xấu
Gần đây tôi được đọc lời nói đầu trong một cuốn sách của Kent Beck – cuốn Implementation Patterns (Cài đặt Mẫu thiết kế). Trong đó có câu “cuốn sách này được dựa trên một giả thuyết khá mong manh: mã tốt là một vấn đề quan trọng”. Một giả thuyết mong manh? Tôi không đồng ý. Tôi nghĩ rằng tiền đề đó là một trong những cơ sở mạnh mẽ nhất, được khuyến khích nhất, và nan giải nhất trong nghề của chúng ta (và tôi nghĩ là Kent biết điều đó). Còn chúng tôi thì hiểu rõ, vì đã phải đương đầu với sự hiếm hoi của mã nguồn tốt quá lâu rồi.
Tôi biết một công ty vào cuối những năm 1980 đã viết một ứng dụng sát thủ (killer application). Nó đã rất phổ biến, và rất nhiều chuyên gia đã mua và sử dụng nó. Nhưng rồi các chu kỳ phát hành phiên bản mới ngày càng thưa dần. Các lỗi không được sửa sau mỗi bản phát hành. Ứng dụng càng lúc càng “nặng” và hay bị “treo”. Tôi nhớ một ngày tôi đã tắt chương trình đó đi trong sự thất vọng và không bao giờ sử dụng nó nữa. Còn công ty thì đã chấm dứt kinh doanh một thời gian ngắn sau.
Hai thập kỷ sau, tôi gặp một trong những nhân viên đầu tiên của công ty đó và hỏi anh ta những gì đã xảy ra. Câu trả lời đã xác nhận những e ngại của tôi. Họ đã vội vã tung sản phẩm ra thị trường và tạo ra một mớ lộn xộn khổng lồ trong mã. Khi họ thêm ngày càng nhiều các tính năng thì mã nguồn ngày càng tệ hại hơn nữa. Cho đến khi họ thực sự không thể quản lý nổi mã nguồn nữa. Vậy chính mã nguồn xấu đã làm công ty phải đóng cửa.
Đã bao giờ bạn gặp trở ngại to lớn do mã nguồn xấu? Nếu bạn là một lập trình viên từng trải, bạn hẳn đã nhận ra sự trở ngại này nhiều lần. Trên thực tế, chúng tôi đã đặt cho nó một cái tên. Chúng tôi gọi đó là “lội”. Chúng tôi lội qua mã xấu, một cách ì ạch qua những bãi lầy đầy gai rối và cạm bẫy. Chúng tôi nỗ lực tìm đường, loay hoay để tìm ra một vài gợi ý, một ít đầu mối, về những gì đang xảy ra; nhưng tất cả những gì chúng tôi thấy là nhiều và nhiều hơn nữa những dòng mã vô nghĩa.
Tất nhiên bạn đã từng gặp trở ngại với mã xấu. Vậy thì – tại sao bạn lại viết ra chúng?
Có phải bạn đã cố đi nhanh? Lúc đó bạn đang vội? Có lẽ vậy. Có lẽ bạn cảm thấy bạn không có thời gian để làm một việc tốt; rằng sếp có thể sẽ bực mình nếu bạn dành thời gian để làm sạch mã của bạn. Có lẽ bạn thật ra rất mệt mỏi với dự án này và chỉ mong cho nó xong sớm. Hoặc cũng có thể bạn nhìn vào backlog và thấy còn rất nhiều hạng mục khác mà mình đã hứa sẽ hoàn thành, và bạn nhận ra rằng phải nhanh chóng “làm cho xong” mô-đun này để có thể chuyển sang việc tiếp theo.
Chúng ta cũng từng làm như vậy. Chúng ta cũng từng nhìn vào mớ bừa bộn mình vừa tạo ra và ngao ngán quyết định sẽ dọn sau. Chúng ta cảm thấy nhẹ nhõm khi chương trình lộn xộn của chúng ta hoạt động được và quyết định rằng “lộn xộn còn hơn là không có gì”. Chúng ta thống nhất rằng sẽ quay lại làm sạch nó sau. Dĩ nhiên là trong những ngày đó chúng ta chưa biết đến “định luật LeBlanc”: để sau nghĩa là không bao giờ.
## Tổng chi phí của sự lộn xộn
Nếu bạn làm lập trình viên được khoảng hai đến ba năm, có lẽ bạn đã bị mã rối của ai đó làm chậm lại một cách kinh khủng. Nếu bạn làm lập trình viên lâu hơn ba năm, có lẽ bạn cũng đã bị mã rối làm chậm lại. Mức độ làm chậm có thể khác biệt đáng kể. Qua một hoặc hai năm, những đội đang triển khai giai đoạn đầu dự án ở tốc độ rất nhanh có thể thấy rằng tốc độ của họ trở nên chậm như sên. Mỗi sự thay đổi mã nguồn làm hỏng hai hay ba phần khác trong mã nguồn. Không sự thay đổi nào là dễ dàng. Mỗi việc thêm mới hay sửa đổi hệ thống đòi hỏi bạn phải hiểu hết những mớ bòng bong và những nút thắt của mã để bạn có thể thêm vào những mớ bòng bong và những nút thắt khác. Càng ngày đống lộn xộn càng to ra, sâu hơn và cao hơn, họ không thể dọn sạch nó được. Không thể nào làm nổi.
Mã nguồn càng lộn xộn càng làm năng suất làm việc của nhóm liên tục giảm đi, gần như xuống tới không. Và vì năng suất giảm, người quản lý làm việc duy nhất họ có thể làm đó là: bổ sung nhân lực cho dự án hòng cải thiện năng suất. Nhưng nhân viên mới lại không thông thạo về thiết kế hệ thống. Họ không hiểu rằng có những thay đổi phù hợp với định hướng thiết kế trong khi một số khác thì không. Hơn nữa, họ cùng những người khác trong nhóm đều phải chịu áp lực khủng khiếp để tăng năng suất. Và tất cả họ càng ngày càng làm ra nhiều lộn xộn hơn, làm năng suất giảm gần về không hơn.
![ Năng suất & thời gian](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/2.png)
Năng suất & thời gian
**Cuộc tái thiết vĩ đại giữa lưng chừng trời**
Cuối cùng thì nhóm quyết định làm điều gì đó. Họ thông báo cho quản lý rằng họ không thể tiếp tục phát triển mớ mã nguồn kinh khủng này. Họ yêu cầu được thiết kế lại. Quản lý không muốn phải dùng cạn kinh phí của dự án cho việc tái thiết, nhưng cũng không thể phủ nhận rằng năng suất đang thật khủng khiếp. Cuối cùng họ nhượng bộ yêu cầu của đội ngũ phát triển và cho phép bắt đầu cuộc tái thiết kế vĩ đại giữa lưng chừng dự án.
Một nhóm gồm những tay cứng cựa được chọn ra. Ai cũng muốn được vào nhóm này bởi vì đây là một dự án mới toanh. Họ sẽ được làm lại từ đầu và sẽ tạo ra một thứ thật sự đẹp đẽ. Nhưng chỉ những cá nhân xuất sắc và triển vọng nhất được lựa chọn để gia nhập “biệt đội hổ”. Những người khác phải tiếp tục bảo trì hệ thống hiện tại.
Bây giờ thì hai đội đang ở trong một cuộc đua. Đội hổ cần phải xây dựng một hệ thống mới có thể làm mọi thứ thay cho hệ thống cũ. Không những thế, họ còn phải theo kịp với những thay đổi liên tục được thực hiện trên hệ thống cũ. Quản lý sẽ không thay thế hệ thống cũ cho tới khi hệ thống mới đã hoàn toàn đáp ứng được công việc của hệ thống cũ.
Cuộc đua này có thể tiếp diễn qua một thời gian rất dài. Tôi đã thấy nó mất tới mười năm. Qua thời gian, những thành viên cũ của đội hổ đã rời đi, và những thành viên hiện tại đang yêu cầu được tái thiết kế hệ thống mới bởi vì hệ thống mới đã lại là một mớ mã nguồn lộn xộn.
Nếu bạn đã từng trải qua chỉ cần một phần nhỏ câu chuyện tôi vừa kể, bạn đã biết rất rõ rằng bỏ thời gian để giữ cho mã sạch không chỉ là vấn đề giảm chi phí, mà nó là chuyện sống còn của lập trình viên chuyên nghiệp.
## Thái độ
Bạn đã bao giờ lội qua những vũng bùn của mã nguồn khó khăn đến nỗi phải mất một tuần để làm những thứ lẽ ra nên xong trong một giờ? Đã bao giờ nhận thấy lẽ ra chỉ cần thay đổi một dòng mã thay vì phải sửa trong hàng trăm mô-đun khác nhau. Những triệu chứng này đã quá phổ biến rồi.
Tại sao những điều đó xảy ra với mã? Tại sao mã tốt nhanh chóng biến thành mã xấu. Chúng ta đưa ra rất nhiều lời giải thích. Chúng ta phàn nàn rằng những yêu cầu ban đầu bị thay đổi đã phá vỡ thiết kế ban đầu. Chúng ta than vãn rằng lịch công việc quá chặt chẽ để làm mọi thứ một cách đúng đắn.
Chúng tôi đổ lỗi cho quản lý ngu ngốc, những khách hàng cứng cổ, các thể loại tiếp thị vô dụng và cả “những người dọn toa lét”. Nhưng lỗi, Dilbert thân mến, không phải tại những ngôi sao của chúng tôi, mà thuộc về bản thân chúng tôi.
Sự thật đó như một viên thuốc đắng khó nuốt trôi. Làm thế nào mà đống lộn xộn này lại là lỗi của chúng tôi? Thế còn những yêu cầu? Còn lịch công việc thì sao? Quản lý đần độn và tiếp thị vớ vẩn thì sao? Chẳng lẽ họ không lãnh phần trách nhiệm nào?
Không hề! Các quản lý và bộ phận tiếp thị tìm tới chúng ta cho thông tin họ cần để soạn ra những lời hứa và cam kết; và ngay cả khi họ không tới tìm, chúng ta vẫn không nên ngần ngại nói với họ quan điểm của mình. Người dùng thì tìm tới chúng ta để xác nhận liệu những yêu cầu có thích hợp với hệ thống hay không. Quản lý dự án thì nhờ chúng ta hỗ trợ trong việc quyết định lịch trình. Chúng ta can dự sâu sắc vào viện lên kế hoạch cho dự án và chia sẻ phần không nhỏ trách nhiệm với bất kỳ một sự thất bại nào; đặc biệt nếu những thất bại đó một phần là do mã xấu.
Bạn có thể nói “Từ từ đã! Nếu tôi không làm những gì quản lý yêu cầu, tôi sẽ bị sa thải mất.” Không hẳn. Hầu hết quản lý muốn được biết sự thật, ngay cả khi họ không hành động như vậy. Hầu hết các quản lý muốn có mã tốt, ngay cả khi họ bị ám ảnh về lịch trình. Họ có thể bảo vệ lịch trình và yêu cầu với sự đam mê; nhưng đó là công việc của họ. Công việc của bạn là bảo vệ mã nguồn với một đam mê tương đương họ.
Để làm rõ chuyện này, hãy giả sử bạn là một bác sỹ và có một bệnh nhân yêu cầu bạn bỏ qua mấy công việc rửa tay vớ vẩn trong khi chuẩn bị cho ca phẫu thuật vì chúng mất quá nhiều thời gian. Rõ ràng bệnh nhân là ông chủ, nhưng bác sỹ hoàn toàn nên từ chối làm theo yêu cầu trên. Tại sao? Bởi vì chắc chắn là bác sỹ biết rõ hơn bệnh nhân về nguy cơ lây bệnh và nhiễm trùng. Sẽ là không chuyên nghiệp (thậm chí vi phạm pháp luật) nếu bác sĩ làm theo yêu cầu của bệnh nhân. Vì vậy cũng sẽ là không chuyên nghiệp nếu như lập trình viên nhất nhất tuân theo ý muốn của nhà quản lý – những người không am hiểu rủi ro của việc tạo ra mã nguồn lộn xộn.
## Bài toán căn bản
Lập trình viên phải đối mặt với một bài toán hóc búa của các giá trị cơ bản. Tất cả các nhà phát triển có vài năm kinh nghiệm đều hiểu rằng những đoạn mã lộn xộn rồi sẽ làm họ bị chậm lại. Và những người đó luôn cảm thấy áp lực buộc phải tạo ra mã lộn xộn, để đáp ứng thời hạn. Tóm lại, họ bỏ đi phần thời gian dành cho việc gỡ rối mã nguồn để đáp ứng tiến độ.
Chuyên gia thực thụ biết rằng phần thứ hai của bài toán là không đúng. Bạn sẽ không đáp ứng được tiến độ bằng cách tạo ra những đoạn mã lộn xộn. Thật vậy, mã lộn xộn sẽ làm bạn chậm lại ngay lập tức, và sẽ khiến bạn phải trễ thời hạn. Cách duy nhất để đáp ứng tiến độ – cách duy nhất để đi nhanh – đó là giữ cho mã nguồn của bạn luôn luôn sạch nhất có thể.
## Nghệ thuật của mã sạch
Hãy coi như bạn tin rằng mã lộn xộn là một tay ngáng đường kinh khủng. Và bạn chấp nhận rằng cách duy nhất để đi nhanh là giữ sạch mã của bạn. Vậy bạn sẽ tự hỏi: “Làm thế nào để viết mã sạch?” Sẽ là không ổn chút nào nếu bạn cố gắng thử viết mã sạch mà không được biết thật ra như thế nào mới được gọi là mã sạch.
Tin xấu là viết mã sạch có rất nhiều điểm giống như vẽ một bức tranh. Phần lớn chúng ta biết như thế nào là tranh được vẽ đẹp hay xấu. Nhưng có thể nhận thức được cái đẹp và cái xấu không có nghĩa là chúng ta biết làm thế nào để vẽ. Thế nên việc nhìn ra mã sạch hay mã xấu không có nghĩa là ta biết làm thế nào để viết ra mã sạch.
Việc viết mã nguồn sạch yêu cầu sử dụng một cách kỷ luật vô số kỹ thuật nhỏ được ứng dụng thông qua việc dày công luyện tập cảm giác về sự “sạch”. Cảm-giác-mã này là chìa khóa. Một vài trong chúng ta sinh ra đã có được cảm-giác-mã. Một số thì phải chiến đấu để có được nó. Nó không chỉ quan trọng trong việc làm cho chúng ta nhận thấy được mã tốt hay mã xấu, mà còn giúp ta nhìn ra chiến lược để áp dụng kỷ luật mà chúng tôi đề ra cho việc chuyển đổi mã xấu thành mã sạch.
Một lập trình viên thiếu cảm-giác-mã có thể nhìn vào một mô-đun lộn xộn và nhận ra sự lộn xộn trong đó nhưng sẽ không biết sẽ phải làm gì với nó. Lập trình viên có cảm-giác-mã tốt thì khác, anh ta sẽ thấy được những hướng phát triển khác. Cảm-giác-mã sẽ giúp lập trình viên chọn được hướng biến đổi tốt nhất, đưa anh (cô) ta qua một chuỗi biến đổi mà không làm thay đổi hành vi để đi đến đích.
Tóm lại, một “lập trình viên viết mã sạch” là một nghệ sĩ người mà có thể biến một màn hình trống rỗng thành một hệ thống mã thanh lịch thông qua một chuỗi biến đổi
## Mã sạch là gì?
Mỗi lập trình viên thì lại có một định nghĩa về mã sạch khác nhau. Vậy nên tôi đã đi hỏi một vài người rất nổi tiếng và dày dạn kinh nghiệm xem họ nghĩ gì về mã sạch.
**Bjarne Stroustup**, người phát minh ra C++ và là tác giả của cuốn *The C++ Programming Language* ![ Bjarne Stroustup](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/3.-bjarme-261x300.png)
Bjarne Stroustup
*“Tôi thích mã của tôi thanh lịch và hiệu quả. Lô-gic nên đơn giản để làm cho nó khó gặp những lỗi ẩn, có tối thiểu những sự phụ thuộc để dễ dàng bảo trì, xử lý lỗi hoàn chỉnh theo những chiến lược thống nhất, và hiệu suất gần như tối ưu để không cám dỗ người ta làm mã lộn xộn với những trò tối ưu hóa lố lăng. Mã sạch là mã làm tốt một việc”.*
Bjarne dùng từ “thanh lịch”. Một từ hết xẩy. Từ điển trong MacBook® của tôi cung cấp các định nghĩa sau: “diện mạo tinh tế và dễ chịu ; tài tình dễ chịu và đơn giản.” Bất cứ định nghĩa nào cũng nhấn mạnh sự “dễ chịu”. Rõ ràng Bjarne cho rằng mã sạch phải là mã khiến người đọc dễ chịu. Đọc nó phải làm bạn mỉm cười vui sướng giống hệt như trải nghiệm mà một hộp nhạc được chế tác tinh xảo hoặc chiếc xe hơi được thiết kế tinh tế mang lại.
Bjarne cũng đề cập đến “hiệu suất” – hai lần. Có lẽ điều này không làm chúng ta ngạc nhiên vì nó tới từ người sáng tạo ra C++; nhưng tôi nghĩ có nhiều điều để nói về hiệu suất ngoài chuyện tốc độ. Những chu kỳ lãng phí không thanh lịch, chúng không dễ chịu. Và hãy lưu ý từ mà Bjarne dùng để mô tả hệ quả của việc không thanh lịch. Ông dùng từ “cám dỗ”. Có một sự thật sâu sắc ở đây. Mã xấu “cám dỗ” sự lộn xộn phát triển. Khi những người khác thay đổi mã xấu, họ thường có xu hướng làm cho nó tồi tệ hơn.
Pracmatic Dave Thomas và Andy Hunt (**) đã nói về điều này theo một cách khác. Họ sử dụng câu chuyện ẩn dụ về những cửa sổ bị hỏng. Một tòa nhà có những cửa sổ bị hỏng khiến mọi người tưởng rằng không ai quan tâm đến nó. Vì vậy họ cũng không quan tâm đến nó. Họ cứ để mặc những cửa sổ hỏng (
[broken windows](http://pragprog.com/booksellers/2004-12.html)). Cuối cùng người ta chủ động phá chúng. Họ vẽ đầy những hình graffiti lên mặt trước tòa nhà, để mặc cho rác chất đống. Một ô cửa sổ hỏng sẽ dẫn đến sự đổ nát.
Bjarne cũng đề cập tới việc xử lý lỗi nên được hoàn chỉnh. Điều này tiến tới kỷ luật trong việc chú ý vào các chi tiết. Xử lý lỗi không hoàn chỉnh chỉ là một cách để các lập trình viên trốn tránh các chi tiết. Rò rỉ bộ nhớ là một ví dụ khác, tranh đoạt điều khiển (race condition) cũng thế. Đặt tên không nhất quán là một ví dụ khác nữa. Ta có thể kết luận rằng mã sạch thể hiện sự chú ý tỉ mỉ đến từng chi tiết.
Bjarne kết thúc với sự khẳng định rằng mã sạch là mã làm tốt một thứ. Không phải ngẫu nhiên mà có rất nhiều nguyên tắc thiết kế phần mềm có thể tóm lược lại thành lời khuyên đơn giản này. Hết tác giả này đến tác giả khác đã cố gắng truyền đạt tư tưởng này. Mã xấu cố gắng làm quá nhiều thứ, nó có ý định lộn xộn và mục đích không rõ ràng. Mã sạch là sự hội tụ. Mỗi chức năng, mỗi lớp, mỗi môđun cho thấy sự tập trung vào một mục đích, ý đồ duy nhất mà không bị sao nhãng và làm bẩn bởi những chi tiết ngoài lề.
**Grady Booch**, tác giả cuốn Object Oriented Analysis and Design with Applications ![ Grady Booch](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/4.-grady-300x276.png)
Grady Booch
“Mã sạch là mã đơn giản và trực tiếp. Mã sạch được đọc như đọc văn xuôi được viết trôi chảy. Mã sạch không bao giờ làm lu mờ ý định của người thiết kế mà nó luôn có đầy những sự trừu tượng hóa rõ ràng và những dòng mã điều khiển dễ hiểu.”
Grady đưa ra một vài luận điểm tương tự như Bjarne, nhưng ông ấy nhắc tới khía cạnh “dễ đọc”. Tôi đặc biệt thích quan điểm của ông về “đọc mã sạch như đọc văn xuôi được viết trôi chảy.” Hãy nhớ lại một cuốn sách được viết tốt mà bạn đã đọc. Nhớ lại cách mà từ ngữ đã biến mất và thay vào đó là những hình ảnh hiện ra. Giống như xem một bộ phim phải không? Tốt hơn nữa. Bạn thấy những nhân vật, bạn nghe thấy tiếng động, bạn thấy xúc độc và vui vui.
Đương nhiên đọc mã sạch không thể giống hoàn toàn như đọc
*Chúa tể chiếc nhẫn*. Nhưng ẩn dụ đó cũng không phải là quá tệ. Bởi cũng giống như một cuốn tiểu thuyết hay, mã sạch phải phơi bày rõ ràng những căng thẳng trong vấn đề cần giải quyết. Cần đưa những căng thẳng lên tới đỉnh điểm và rồi làm cho người đọc thốt lên: “À há, tất nhiên rồi!” khi thấy các vấn đề và sự căng thẳng được giải quyết bằng một giải pháp rõ ràng.
Tôi thấy rất thú vị với phép chơi chữ nghịch hợp mà Grady sử dụng khi dùng cụm từ “trừu tượng hóa rõ ràng” (“crisp abstraction”). Dù theo nghĩa nào, từ crisp cũng gần như là một từ đồng nghĩa với từ “concrete” (cụ thể). Từ điển trong máy Macbook của tôi có những nghĩa sau của từ crisp: quyết định dứt khoát và thực-tế-nó-vậy, không ngập ngừng hoặc có chi tiết thừa. Dù cho có những ý nghĩa chẳng liên quan đến nhau lắm, từ này vẫn mang đến một thông điệp mạnh mẽ. Mã của chúng ta phải có tính thực-tế-nó-vậy, không phải có tính suy đoán, không chắc chắn. Nó chỉ gồm những gì thực sự cần thiết. Người đọc phải hiểu rõ điều chúng ta quyết định làm trong từng dòng mã.
**“Vĩ đại” Dave Thomas**, sáng lập viên của OTI, cha đẻ của chiến lược Eclipse ![ Dave Thomas](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/5.-Dave-Thomas-251x300.png)
Dave Thomas
*“Mã sạch là mã có thể được đọc và cải tiếng bởi một nhà phát triển bất kỳ chứ không phải chỉ tác giả của nó mới đọc nổi. Nó phải có cả kiểm thử đơn vị ở phía lập trình viên lẫn kiểm thử chấp chận do khách hàng thực hiện. Mã sạch có những tên có ý nghĩa. Nó chỉ đưa ra một cách để làm một việc chứ không đưa ra nhiều cách. Mã sạch có tối thiểu những sự phụ thuộc luôn được định nghĩa một cách tường minh, và đưa ra một cách dùng rõ ràng và tối thiểu hóa các API. Mã nên dễ đọc bởi vì tùy từng ngôn ngữ, không phải mọi thông tin cần thiết đều có thể được thể hiện rõ ràng chỉ bằng mã.”*
Dave có cùng đam mê với Grady về sự dễ đọc, nhưng với một sự bổ sung quan trọng. Ông khẳng định rằng mã sạch giúp người khác dễ dàng cải tiến nó. Điều này có vẻ hiển nhiên, nhưng ta không thể quá coi trọng điều này. Dù sao thì vẫn có sự khác biệt giữa mã dễ đọc và mã dễ cải tiến.
Dave gắn liền tính sạch sẽ với các kiểm thử. Vào thời điểm mười năm trước việc này có thể làm nhiều người nhíu mày. Nhưng kỹ thuật phát triển hướng kiểm thử (Test Driven Development) đã tác động sâu sắc tới toàn nghành công nghiệp phần mềm và trở thành một trong những kỹ thuật cơ bản nhất của chúng ta. Dave nói đúng. Mã không có kiểm thử thì không thể gọi là sạch. Dù cho nó thanh lịch cỡ nào, dễ dọc và dễ tiếp cận ra sao, nếu không có kiểm thử, nó không sạch.
Dave đã hai lần dùng tới từ “tối thiểu”. Rõ ràng ông coi trọng mã nguồn nhỏ gọn hơn là mã nguồn cồng kềnh. Thật vậy, đây là một điệp khúc phổ biến trong tất cả “tàng thư phần mềm” kể từ những tài liệu đầu tiên. Nhỏ hơn thì tốt hơn.
Dave cũng nhắc tới rằng mã nên dễ đọc. Quan điểm này khá gần gũi với thuyết lập trình Literate của Knuth. Nghĩa là mã nên được viết ra với một hình thức dễ đọc cho con người.
**Michael Feathers**, tác giả của Working Effectively with Legacy Code ![ Michael Feathers](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/6.-Michel-Feathers-235x300.png)
Michael Feathers
Tôi có thể liệt kê tất cả những phẩm chất mà tôi nhận thấy trong mã sạch, nhưng có một phẩm chất bao trùm dẫn đến tất cả chúng. Đó là mã sạch bao giờ cũng trông như được viết bởi những người có tâm. Không có manh mối rõ ràng nào cho bạn biết có thể làm mã này tốt hơn nữa. Tất cả mọi phương án dường như đều đã được tác giả của mã này nghĩ tới, và nếu bạn cố gắng tưởng tượng ra những bước cải tiến, bạn sẽ được dẫn về lại chỗ cũ, nơi bạn đang ngồi cảm kích trước mã nguồn được để lại cho bạn bởi một người hết sức có tâm với nghề.
Một từ: “tâm”. Đó thực sự là chủ đề của cuốn sách này. Còn phụ đề sẽ là “Để tâm đến mã như thế nào”.
Michael nhấn mạnh nó đầu tiên. Mã sạch là mã được để tâm tới. Một ai đó đã phải mất thời gian để giữ cho nó đơn giản và ngăn nắp. Họ đầu tư một sự chú ý thích đáng tới các chi tiết. Họ đã để tâm.
![ Ron Jeffries](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/7.-Ron-Jeffries-279x300.png)
Ron Jeffries
**Ron Jeffries**, tác giả cuốn “Extreme Programming Installed” và “Extreme Programming Adventures in C#”.
Ron bắt đầu sự nghiệp lập trình của mình bằng ngôn ngữ Fortran tại Bộ tư lệnh Không quân Chiến lược và đã viết mã nguồn trong hầu hết các ngôn ngữ và trên gần như tất cả các loại máy. Chúng ta nên xem xét ý kiến của ông một cách cẩn thận.
*Trong những năm gần đây, tôi bắt đầu làm theo, gần như đầy đủ, những quy tắc của Beck về mã nguồn đơn giản. Xếp theo độ quan trọng thì thứ tự là:* *• Chạy tất cả các kiểm thử;* *• Không có sự trùng lặp;* *• Diễn đạt tất cả các ý tưởng thiết kế có trong hệ thống;* *• Có tối thiểu số lượng các lớp, phương thức, chức năng, và những thứ tương tự.* *Trong số những quy tắc này, tôi quan tâm chủ yếu tới sự trùng lặp. Khi một điều được thực hiện nhiều lần, đó là một dấu hiệu cho thấy có một ý tưởng trong tâm trí chúng ta đã không được triển khai tốt trong mã nguồn. Tôi cố gắng tìm ra nó là gì. Sau đó tôi cố gắng thể hiện ý tưởng đó rõ ràng hơn.* *“Với tôi, tính rõ nghĩa bao gồm việc đặt tên có ý nghĩa, và tôi thường phải đổi tên của một thứ gì đó nhiều lần cho tới khi vừa ý. Với các công cụ viết mã hiện đại như là Eclipse, đổi tên không hề phức tạp, vì vậy không phải là vấn đề lớn đổi với tôi trong việc đổi các tên. Tuy nhiên, tính rõ nghĩa cũng không chỉ nằm trong các tên. Tôi cũng xem xét liệu có đối tượng hay phương thức nào làm nhiều hơn một việc hay không. Nếu nó là một đối tượng, có thể sẽ cần phải chia nó thành hai hoặc nhiều đối tượng. Nếu nó là phương thức, tôi thường dùng kỹ thuật tái cấu trúc “Extract Method”, kết quả là tôi có một phương thức diễn đạt rõ ràng hơn về việc nó làm, và một số phương thức con diễn đạt việc đó được làm như thế nào.”* *Sự trùng lặp và tính rõ nghĩa đã chiếm rất nhiều thời gian của tôi trong định nghĩa về mã sạch, đổi lại chỉ với hai điều đó thôi cũng có thể làm cho mã xấu trở nên sạch hơn rất nhiều. Tuy nhiên, còn một điều nữa mà tôi vẫn làm để viết mã sạch thì khó diễn đạt hơn một chút.* *“Sau nhiều năm làm công việc này, tôi nhận thấy rằng có vẻ mọi chương trình điều được tạo thành từ những yếu tố rất giống nhau. Ví dụ như “tìm thứ gì đó trong một bộ sưu tập (collection)”. Cho dù cái chúng ta có là một cơ sở dữ liệu các hồ sơ nhân viên, hay một bảng băm (hashmap) của khóa và giá trị, hoặc một mảng các phần tử loại gì đó, thì chúng ta cũng đều nảy sinh nhu cầu tìm lấy một món trong chỗ đó. Thế nên khi tôi muốn làm cái việc “tìm thứ gì đó”, tôi thường bao gói việc triển khai cụ thể vào một lớp hoặc phương thức trừu tượng hơn. Việc này cho tôi một vài lợi thế thú vị”.* *“Tôi hoàn toàn có thể triển khai chức năng ngay lúc đó một cách đơn giản bằng cách sử dụng một bảng băm (hashmap) chẳng hạn, nhưng do tất cả các tham chiếu đến việc tìm kiếm đó đều được gói lại trong trừu tượng hóa nhỏ bé của tôi(một hàm tìm kiếm), tôi có thể thay đổi cách thức triển khai việc tìm kiếm bất cứ lúc nào tôi muốn. Và tôi có thể đi tiếp nhanh hơn trong khi vẫn có thể thay đổi nó sau.”* *“Thêm vào đó, việc trừu tượng hóa bộ sưu tập (collection) lên thường giúp tôi chú ý tới việc gì đang thực sự diễn ra, và giữ cho tôi khỏi sa vào việc triển khai những cách làm phức tạp (arbitrary collection), trong khi tôi thực ra chỉ cần vài cách cực kỳ đơn giản để tìm kiếm điều tôi muốn”.* *“Giảm thiểu trùng lặp, cực kỳ rõ nghĩa, và sớm xây dựng những trừu tượng hóa nhỏ. * *Với tôi, đó là những thứ làm nên mã sạch”.*
Lần này, trong một vài đoạn ngắn, Ron đã tóm tắt nội dung của cuốn sách này. Không trùng lặp, đơn nhiệm (SRP), tính rõ nghĩa, những trừu tượng hóa tí hon. Nội dung cuốn sách này là về tất cả những điều đó.
**Ward Cunningham**, người tạo ra Wiki, Fit, đồng sáng lập của eXtreme Programing. Động tác giả của cuốn sách Design Patterns (Mẫu thiết kế), lãnh đạo tư tưởng của Smalltalk và Lập trình Hướng Đối tượng. Bố già của bất cứ ai quan tâm đến lập trình. ![ Ward Cunningham](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/8.-Ward-271x300.png)
Ward Cunningham
*“Bạn biết bạn đang làm việc với mã sạch khi mỗi đoạn mã bạn đọc đúng như những gì bạn mong đợi. Bạn có thể gọi nó là mã đẹp khi mã đó làm cho ngôn ngữ trông cứ như là ngôn ngữ được tạo ra để giải quyết vấn đề đó.”*
Kiểu phát biểu này đúng là kiểu của của Ward. Bạn đọc nó, gật đầu, và sau đó thì chuyển sang chủ đề tiếp theo. Nó có vẻ rất hợp lý, rất rõ ràng cứ như nó là điều tất nhiên vậy. Bạn có thể nghĩ rằng điều đó là hiển nhiên. Nhưng hãy xem xét kĩ hơn một chút.
“…đúng như những gì bạn mong đợi.” Lần cuối bạn thấy một mô-đun đúng như những gì bạn mong đợi là khi nào? Hay bạn toàn thấy các mô-đun thật là phức tạp, loằng ngoằng? Chả phải mã thì luôn gây nhầm lẫn cho người đọc? Chẳng phải bạn đã quen với việc rất khó khăn để hiểu được mô-đun bạn đang đọc thì liên quan quái gì đến toàn bộ hệ thống? Lần cuối mà bạn đọc mã của ai đó và gật đầu như khi bạn gật đầu trước phát biểu của Ward là khi nào?
Ward muốn rằng khi bạn đọc mã sạch bạn sẽ không gặp phải bất cứ sự ngạc nhiên nào. Thật vậy, bạn sẽ không phải tốn nhiều công sức để đọc mã sạch. Bạn đọc nó, và nó sẽ đúng như những gì bạn mong đợi. Nó rõ ràng, đơn giản và thuyết phục. Mỗi mô-đun sẽ chuẩn bị sân khấu cho mô-đun tiếp theo, nó sẽ cho bạn biết điều gì sẽ được viết tiếp. Những chương trình sạch được viết tốt đến nỗi bạn không phải để tâm đến chuyện nó được viết như thế nào. Người thiết kế đã làm cho nó trông cực kỳ đơn giản như những thiết kế tuyệt vời khác.
Thế còn quan điểm của Ward về vẻ đẹp? Chúng ta luôn trách móc cuộc đời rằng ngôn ngữ ta dùng không được thiết kế để giải quyết vấn đề của mình. Nhưng lời của Ward đã đẩy trách nhiệm đó về lại cho chúng ta.
Ông nói rằng mã đẹp làm cho ngôn ngữ trông chứ như là được sinh ra để giải quyết vấn đề đó. Vậy trách nhiệm của chúng ta là phải làm cho ngôn ngữ trông thật đơn giản. Những người hâm mộ cuồng nhiệt của các ngôn ngữ, hãy nhớ rằng! Không phải ngôn ngữ là thứ làm cho chương trình trông đơn giản. Mà chính lập trình viên mới là “thứ” làm cho ngôn ngữ trông đơn giản!
## Các trường phái tư tưởng
Còn tôi (Uncle Bob) thì sao? Tôi nghĩ thế nào là mã sạch? Cuốn sách này sẽ nói cho bạn biết, qua những chi tiết rất gớm ghiếc, về những điều mà tôi và những bạn đồng sự nghĩ về mã sạch. Chúng tôi sẽ cho bạn biết suy nghĩ về những gì làm tạo nên một tên biến sạch, một hàm sạch, một lớp sạch, v.v… Chúng tôi sẽ trình bày những ý kiến này như là một sự thật hiển nhiên và chúng tôi sẽ không xin lỗi vì ngôn từ chối tai của mình.
![ Uncle Bob](http://tapchilaptrinh.vn/wp-content/uploads/2014/05/9.-Uncle-Bob-259x300.png)
Uncle Bob
Với chúng tôi, tại thời điểm này của sự nghiệp, chúng là tuyệt đối, hiển nhiên. Chúng là trường phái tư tưởng của chúng tôi về mã sạch.
Các võ sư luôn không đồng ý với nhau về môn phái tốt nhất hay kĩ thuật tốt nhất của một môn phái. Thường thì những võ sư bậc thầy sẽ tạo ra trường phái tư tưởng của riêng họ và chiêu dụ môn sinh đến học. Vì vậy ta có Nhu thuật Gracie được thành lập và giảng dạy bởi nhà Gracie ở Brazil, có Nhu thuật HakkoRyu được thành lập và giảng dạy bởi Okuyama Ryuho ở Tokyo, và có Triệt-quyền-đạo, được Bruce Lee sáng tạo và giảng dạy ở Hoa Kỳ.
Những “môn đệ” của các công phu đó đắm mình trong lời dạy của người lập phái. Họ dồn hết tâm huyết để học theo một người thầy, thường là để xóa đi những điều học được từ những người thầy trước. Sau đó, khi đã phát triển công phu đến một mức nhất định, họ có thể tiếp tục học hỏi từ một bậc thầy khác để mở rộng kiến thức và kỹ năng của họ.
Vài người thậm chí tiếp tục khổ luyện công phu, sáng tạo ra các kỹ thuật mới và lập ra trường phái riêng của họ.
Không trường phái nào trong số đó là đúng tuyệt đối. Nhưng khi học tập tại một ngôi trường cụ thể, chúng ta sẽ mặc nhiên coi tất cả những kỹ năng được dạy là đúng. Đúng là luôn phải có một cách chuẩn mực để luyện tập Nhu thuật Hakkoryu hoặc Triệt quyền đạo. Nhưng chuẩn mực trong một trường phái không làm mất giá trị các lời dạy của một trường phái khác.
Hãy xem cuốn sách này như bản miêu tả của trường (phái) Object mentor về mã sạch. Những kỹ năng và bài học trong đây là cách chúng tôi luyện tập công phu của mình. Chúng tôi sẵn lòng khẳng định rằng nếu bạn làm theo những chỉ dẫn này, bạn sẽ nhận được những lợi ích mà chúng tôi đã đạt được, và bạn sẽ học được cách viết mã sạch và chuyên nghiệp. Nhưng đừng nghĩ rằng chúng tôi đúng tuyệt đối trong mọi trường hợp. Có những trường phái khác và những bậc thầy khác cũng được tuyên bố chuyên nghiệp như chúng tôi. Bạn cũng cần phải học từ họ nữa.
Thật vậy, nhiều điều được khuyến nghị trong cuốn sách này vẫn đang gây tranh cãi. Bạn có thể sẽ không đồng ý với tất cả trong số chúng, và thậm chí có thể dữ dội bác bỏ một số trong đó. Không sao cả. Chúng tôi không thể yêu cầu cho mình quyền thắng cuối cùng. Mặt khác, những khuyến nghị trong này là những thứ mà chúng tôi đã phải suy nghĩ rất kỹ sau một thời gian dài mới nhận ra. Chúng tôi đã học được những điều đó qua nhiều thập kỷ tích lũy kinh nghiệm và thử nghiệm lặp đi lặp lại và sai lầm. Vì vậy cho dù bạn có hay không đồng ý, thật là một sự xấu hổ nếu bạn không nhìn thấy được, và tôn trọng quan điểm của chúng tôi.
**Chúng ta là những tác giả**
Trường @author của Javadoc nói lên chúng ta là ai. Chúng ta là những tác giả. Và một điều về các tác giả đó là họ có các độc giả. Thật vậy, những tác giả có trách nhiệm là giao tiếp tốt với độc giả của họ. Mỗi khi bạn viết một dòng mã, hãy nhớ bạn là một tác giả, đang viết cho những độc giả người mà sẽ đánh giá thành quả của bạn.
Bạn có thể thắc mắc: “Mã thật sự được đọc nhiều đến mức nào?” “Chẳng phải hầu hết công sức đều dành cho việc viết ra nó sao?” Bạn đã từng chiếu lại một phiên chỉnh sửa? Trong những năm 80 và 90, chúng tôi có những phần mềm editor như là Emacs, chúng có thể lưu giữ tất cả những lần gõ phím. Bạn có thể làm việc trong một giờ và sau đó phát lại toàn bộ phiên làm việc như đang xem một đoạn phim tốc độ cao. Khi tôi thực hiện việc đó, kết quả thực sự thú vị.
Phần lớn của đoạn phim đó là tác vụ cuộn và nhảy tới các mô-đun khác.
*“Bob nhảy vào mô-đun.”* *“Anh ta cuộn xuống chức năng cần phải sửa đổi.”* *“Anh ấy dừng lại, cân nhắc các lựa chọn.”* *“Ô, giờ thì hắn cuộn lên đầu mô-đun để kiểm tra việc khởi tạo của 1 biến.”* *“Giờ anh ấy cuộn lại chỗ cũ và bắt đầu gõ.”* *“Opp, anh xóa câu vừa gõ.”* *“Anh lại gõ lại câu đó.”* *“Anh lại xóa nó một lần nữa..”* *“Anh gõ một nửa của một thứ khác, nhưng rồi lại xóa nó đi.”* *“Anh cuộn xuống một hàm khác, chỗ mà có gọi tới hàm anh ta đang sửa đổi, để xem nó được gọi như thế nào.”* *“Anh cuộn lại chỗ cũ, gõ lại y hệt những gì vừa xóa.”* *“Anh tạm dừng.”* *“Anh xóa đoạn code đó một lần nữa!* *“Anh ta mở tạm một cửa sổ khác để xem xét một subclass. Liệu chức năng kia có bị ghi đè không?* *. . .* *Bạn thấy vấn đề rồi chứ. Thực vậy, tỷ lệ giữa thời gian đọc mã so với viết mã nhiều hơn 10:1.*
Chúng ta liên tục phải đọc lại mã cũ, việc này chiếm một phần nhất định trong quá trình viết mã mới. Bởi vì tỷ lệ này cao như vậy, chúng ta muốn việc đọc hiểu mã phải thật dễ dàng, ngay cả khi nó làm cho việc viết mã trở nên khó khăn hơn. Tất nhiên ta không thể viết mã mà không cần đọc chính đoạn mã đang viết (trừ khi bạn nhắm mắt trong khi viết mã), thế nên làm cho mã dễ đọc cũng thực sự giúp cho việc viết mã trở nên dễ dàng hơn.
Không có cách nào để thoát khỏi lô-gic này – bạn không thể viết mã nếu bạn không thể đọc được mã xung quanh. Đoạn mã hôm nay sẽ khó hay dễ để viết phụ thuộc vào những đoạn mã liên quan đến nó là khó hay dễ để đọc. Vì vậy nếu bạn muốn công việc của bạn trôi chảy, muốn xong nhanh, muốn viết ra mã dễ dàng hơn – trước hết hãy làm cho nó dễ đọc.
## Luật hướng đạo.
Chỉ viết mã tốt thôi là không đủ. Mã còn phải được giữ sạch cùng thời gian. Tất cả chúng ta đều đã chứng kiến mã xấu đi và giảm chất lượng theo thời gian. Do đó chúng ta cần phải chủ động trong việc ngăn ngừa sự suy thoái này.
Những cậu bé hướng đạo sinh của nước Mỹ có một luật đơn giản mà chúng ta cũng có thể áp dụng vào nghề của chúng ta.
“Rời khỏi khu cắm trại sạch hơn lúc bạn đến”
Nếu mỗi lần check-in mã (commit) chúng ta đều làm mã của mình sạch một chút so với khi ta check-out (update) nó về, mã chắc chắn sẽ không bị thối. Việc làm sạch không phải là thứ gì đó quá lớn lao. Đơn giản có thể chỉ là đổi tên một biến nào đó cho tốt hơn, phân tách một chức năng quá lớn, khử một vài đoạn mã lặp, dọn dẹp một câu lệnh if phức tạp v.v..
Bạn có tưởng tượng được việc làm việc trên một dự án mà mã đơn giản là cứ mỗi ngày một trông đẹp hơn? Nếu không phải như vậy thì liệu có phải là chuyên nghiệp nữa hay không? Thực sự, chẳng phải “cải tiến liên tục” là một phần bản chất của tính chuyên nghiệp sao?
## Cuốn sách tiền truyện và những nguyên tắc
Về nhiều mặt, cuốn sách này là phần trước (prequel) của một cuốn khác mà tôi đã hoàn thành vào năm 2002 với tựa đề “Phát triển phần mềm linh hoạt: Nguyên tắc, Hình mẫu và Thực hành.” (Agile Software Development: Principles, Patterns, and Practices – (PPP) – ND). Cuốn PPP bản thân nó liên quan tới các nguyên lý của thiết kế hướng đối tượng, và có rất nhiều các bài thực hành được dùng bởi các nhà phát triển chuyên nghiệp. Nếu bạn chưa đọc nó, bạn sẽ thấy rằng nó là phần sau của câu chuyện được kể trong cuốn sách này. Nếu bạn đã đọc PPP, thì giờ đây bạn có cơ hội tìm thấy rất nhiều cảm hứng của nó được lặp lại trong cuốn sách này, nhưng ở cấp độ của mã.
Trong cuốn sách này, bạn sẽ thấy nhắc đến nhiều nguyên tắc thiết kế phần mềm. Trong số đó có thể kể đến Nguyên lý đơn nhiệm (Single Responsibility Principle – SRP), Nguyên lý mở đóng (the Open Closed Principle – OCP), và Nguyên tắc đảo ngược sự phụ thuộc (Dependency Inversion Principle – DIP) ngoài nhiều nguyên tắc khác. Những nguyên tắc đó được miêu tả rất sâu trong cuốn PPP.
## Kết luận
Sách về nghệ thuật không bảo đảm giúp bạn trở thành nghệ sĩ. Tất cả những gì nó làm đó là cung cấp cho bạn một số công cụ, kỹ thuật và cách suy nghĩ mà những nghệ sĩ khác đã sử dụng. Vậy nên cuốn sách này không thể đảm bảo sẽ làm bạn trở thành một lập trình viên tốt. Nó không thể đảm bảo sẽ giúp bạn có được cảm-giác-mã. Tất cả nó làm là cho bạn thấy tư duy của những lập trình viên tốt và những thủ thuật, kỹ thuật và công cụ mà họ dùng.
Cũng giống như một cuốn sách về nghệ thuật, bạn sẽ thấy cuốn sách này có rất nhiều những chi tiết. Bạn sẽ thấy rất nhiều mã. Có cả mã tốt và mã xấu. Và bạn sẽ thấy quá trình chuyển mã xấu thành mã tốt. Bạn sẽ thấy hàng loạt các cách giải quyết vấn đề thông qua việc thử nghiệm, những nguyên lý, và những kỹ thuật. Bạn sẽ thấy rất nhiều ví dụ. Kết quả đạt được sẽ phụ thuộc vào chính bản thân bạn.
Bạn có nhớ câu chuyện đùa cũ về người nghệ sĩ hòa tấu violin bị lạc đường khi đang đến buổi biểu diễn (tại Carnegie Hall)? Anh ta hỏi một cụ già xem mình phải làm gì để tới được Carnegie Hall (* “phòng hòa nhạc của những giấc mơ” – ND). Cụ già nhìn chăm chú người nghệ sĩ với cây violin kẹp dưới cánh tay, và nói: “Luyện tập, con trai ạ. Luyện tập!”
(*) Domain-specific language: – trong phát triển phần mềm, là một loại ngôn ngữ lập trình dành riêng cho một vấn đề / kỹ thuật biểu diễn / giải pháp cụ thể. HTML là một ví dụ về DSL. Trái ngược với DSL là General-purpose Programming Language ( những ngôn ngữ lập trình được thiết kế cho lập trình trên diện rộng, điển hình là C, Java, Python ) và General-purpose Modeling Language mà UML là một ví dụ.
(**) Hai người này đã sáng lập Pracmatic programer, và tác giả dùng từ Pracmatic trong tên như biệt danh.
Tham khảo
[Beck07]: Implementation Patterns, Kent Beck, Addison-Wesley, 2007.
[Knuth92]: Literate Programming, Donald E. Knuth, Center for the Study of Language and Information, Leland Stanford Junior University, 1992.
Nguồn:
*Chương 1 – Clean Code (Mã sạch)* của Robert C. Martin
Người dịch:
[Trần Thu Vân](https://www.facebook.com/van.tran.1253?fref=ts&ref=br_tf), [Nguyễn Trung Tuyến](https://www.facebook.com/com.mediannguyen), [Nguyễn Bình Sơn](https://www.facebook.com/lionel.nguyen.14) & [Ngô Trung](https://www.facebook.com/lewtds)
Biên tập: Phạm Anh Đới
Bài viết hay. Rất mong chương 2 ra sớm.
Chương hai đã có từ lâu: http://tapchilaptrinh.vn/2014/01/07/ma-sach-ten-co-y-nghia/
Chúng tôi đang tìm người để dịch chương 3.
https://docs.google.com/a/fpt.aptech.ac.vn/document/d/1UlgsBK3ZcFd6mDLsb8zvvcSCJL5SkYyfW6ozsgUHjS8/edit
Bài viết rất hay.
Mình đang đọc cuốn Clean Code của Robert C Martin đây
Bạn có link tải cuốn “Clean Code” này không ?
Bạn có thể vào nhóm facebook: CocoDojo để xem nhé
https://www.facebook.com/groups/cocodojo/files/
Pingback: Mã sạch | PlayerNam
Pingback: Mã sạch | Mai Chân Chính
Bài rất hay, đúng tâm trạng e @@, rất cảm ơn thầy
Cám ơn bài viết này. Đúng cái mà mình đang cần. Cám ơn anh rất nhiều
![ :)](http://tapchilaptrinh.vn/wp-includes/images/smilies/simple-smile.png)
Bài viết rất hay. Cám ơn tác giả rất nhiều.
Thực sự bài viết rất hay. Mình chỉ mới học lập trình được khoảng một tháng thôi, nhưng cảm giác bài này sẽ là kim chỉ nam cho quá trình học của mình trong thời gian sắp tới. Cảm ơn vì đã dịch một bài hay như vậy!^^
Bài viết chuẩn, mình học được nhiều điều rối rắm ?
Chào các quản trị viên tapchilaptrinh.vn
Bài này rất hay, cho mình hỏi tapchilaptrinh.vn có thể cho mình chia sẽ lại nội dung trên blog cá nhân của mình không, mình sẽ ghi rõ nguồn từ tapchilaptrinh.vn
thanks,
Bạn có thể chia sẻ các bài viết của TCLT nhưng lưu ý ghi rõ nguồn gốc là ok.

Vary: Accept-Encoding,User-Agent


markdown:
Nhịp chậm chạp của người hướng dẫn mới làm cho tiến độ là gì đó của quá khứ, Alphonse muốn bay lên và học được tầm quan trọng của sự chậm rãi
Tác giả: Robert C. Martin
Người dịch: Hoàng Ngọc Diêu | Biên tập:
[Phạm Anh Đới](http://tapchilaptrinh.wordpress.com/author/doipa/)
“Được rồi cậu bé thân mến, tôi nghĩ đã đến lúc chúng ta bắt đầu làm việc với phần server của chương trình này, phải không cậu bé? Đến lúc này phần client làm việc có vẻ ngon lành như chúng ta thấy được, và một client mà không có server thì trông cô đơn quá. Cậu đồng ý không nào?”
[đọc tiếp](http://tapchilaptrinh.vn/2014/01/08/tho-lanh-nghe-18-cham-ma-chac-smcremote-phan-8/#more-5435)


markdown: Facebook Chia sẻ Google+ Twitter Email Đại tá Nguyễn Văn Tuyên, Cục trưởng Cục CSGT đường bộ - đường sắt (C67) Bộ Công an, bày tỏ quyết tâm dùng biện pháp mạnh để dẹp nạn lạng lách, đua xe vốn đang gây bất an cho toàn xã hội. Đại tá Nguyễn Văn Tuyên, Cục trưởng Cục CSGT đường bộ - đường sắt (C67) Bộ Công an, bày tỏ quyết tâm dùng biện pháp mạnh để dẹp nạn lạng lách, đua xe vốn đang gây bất an cho toàn xã hội. Đua xe quậy phá gây bất an Theo đánh giá của C67, 10 tháng đầu năm nay, nạn đua xe quậy phá vẫn là vấn đề gây bức xúc cho người dân tại các đô thị lớn như TP.HCM, Hà Nội, Bà Rịa-Vũng Tàu. Tệ nạn này cũng đã xuất hiện tại các tỉnh lẻ như Long An, Thanh Hóa. Tại Hà Nội, ngoài xe máy, các đối tượng còn tổ chức đua ô tô. Đại tá Nguyễn Văn Tuyên Theo đại tá Tuyên, mặc dù lực lượng công an nói chung đã có nhiều nỗ lực trấn áp nhưng tình trạng lạng lách, đánh võng, đua xe vẫn xảy ra với nhiều biến tướng phức tạp. Tại Hà Nội, TP.HCM vào lúc nửa đêm, các đối tượng có thể tập trung lên hàng trăm người, đi xe máy lạng lách, đánh võng, chạy tốc độ cao. “Qua thực tế, chúng tôi thấy những đối tượng coi thường pháp luật này không chỉ làm mất an ninh trật tự mà còn gây nguy hiểm cho người đi đường, đã có không ít người dân, thậm chí là cả CSGT mang họa bởi các đối tượng này”, đại tá Tuyên nói. Thống kê của C67 cho biết trong 10 tháng đầu năm đã xảy ra 56 vụ chống lại người thi hành công vụ, đa số các vụ đều gắn liền với đám đua xe. Sau sự kiện, Công an tỉnh Thanh Hóa phải tạm ngưng biện pháp dùng lưới cá để dừng những xe cố ý lạng lách, ông Tuyên cho rằng đây chỉ là một sáng kiến của Công an Thanh Hóa và đang được triển khai thí điểm. Đến thời điểm bị dừng lại, biện pháp này đã giúp cơ quan chức năng bắt được 40 đối tượng lạng lách đua xe trái phép và không xảy ra hậu quả đáng tiếc. “Tôi cho rằng về cách thức thực hiện còn gây ra tranh cãi nhưng đây là một thành công bước đầu của Công an Thanh Hóa. Việc dừng lại là tạm thời để cơ quan chức năng nghiên cứu kỹ hơn chứ không phải là dừng hẳn”, ông Tuyên cho biết. Cũng theo ông Tuyên, việc nhìn nhận biện pháp của Công an tỉnh Thanh Hóa ở nhiều góc độ là cần thiết nhưng cần hiểu đúng: “Không ai làm việc này để bắt người vi phạm giao thông bình thường mà là nhằm bắt các đối tượng lạng lách đua xe, là đối tượng vi phạm pháp luật hình sự mà chúng tôi cho rằng đây là cần thiết bởi đấy không khác gì những kẻ giết người”, ông Tuyên nói. Gần đây, các đối tượng đua xe gây bất an tại nhiều thành phố - Ảnh: Nghĩa Phạm Biện pháp mạnh Trước câu hỏi của Thanh Niên, việc dùng lưới bắt cá để ngăn chặn đua xe khi chưa có quy định pháp luật phải chăng là sự bế tắc của CSGT, ông Tuyên cho rằng cơ quan công an trong đó có CSGT được giao nhiệm vụ phòng chống đua xe, nhưng pháp luật lại không quy định cụ thể về phương pháp. Điều này khiến cơ quan chức năng gặp rất nhiều hạn chế. Theo C67, việc xử lý đua xe, lạng lách theo quy định hiện hành đã nảy sinh nhiều vướng mắc. Cụ thể, Nghị quyết 88 của Chính phủ và các quy định liên quan cho phép cơ quan chức năng tịch thu phương tiện của đối tượng đua xe nhưng lại không quy định tịch thu xe của chính chủ hay tịch thu bất kể chính chủ hay không. Hành vi đua xe được quy định trong bộ luật Hình sự, nhưng quy định cấu thành tội phạm này lại rất “lỏng” nên khó khởi tố. Đơn cử, đối tượng chỉ được coi là đua xe trái phép khi để xảy ra hậu quả nghiêm trọng, hoặc đã từng bị xử lý hành chính đang trong thời hiệu hoặc đã từng bị kết án nhưng chưa được xóa án tích. Đây cũng là lý do khiến rất nhiều vụ từng bị phát hiện nhưng không xử lý được đối tượng hoặc phải chuyển sang xử lý về hành vi gây rối trật tự công cộng với hình thức xử phạt không đủ sức răn đe. ''Những đối tượng này không chỉ làm mất an ninh trật tự mà còn gây nguy hiểm cho người đi đường, đã có không ít người dân, thậm chí cả CSGT mang họa'' - Đại tá Nguyễn Văn Tuyên, Cục trưởng Cục CSGT đường bộ - đường sắt “Đối với biện pháp dùng lưới của Thanh Hóa, suy cho cùng cũng chỉ mới giải quyết phần ngọn, cái mà chúng ta mong muốn là phải xử lý từ gốc, tức là từ khi các đối tượng thanh thiếu niên có những dấu hiệu muốn đua xe. Để làm được, không chỉ lực lượng công an mà phải có sự chung tay của toàn xã hội”, đại tá Tuyên nói. Theo ông Tuyên, hiện C67 đang nghiên cứu đề xuất nhiều giải pháp xử lý, trong đó đề nghị bổ sung thêm một số dấu hiệu cấu thành tội đua xe trái phép gồm: cản trở giao thông, gây rối trật tự công cộng. Với các dấu hiệu này thì các đối tượng lạng lách đua xe dù chưa gây ra hậu quả nghiêm trọng đã có thể bị khởi tố. Mặt khác, cơ quan công an địa phương sẽ thành lập các chuyên án điều tra các ổ nhóm có dấu hiệu đua xe trái phép để xử lý. Đồng thời cho phép tịch thu phương tiện của các đối tượng đua xe, bất kể chính chủ hay không chính chủ. Ông Tuyên cũng cho biết trong thời gian tới sẽ đề nghị bổ sung một số biện pháp mạnh cũng như công cụ hỗ trợ cho lực lượng tham gia phòng chống đua xe trái phép. “Trước mắt, theo chỉ đạo của Bộ, chúng tôi đã đề nghị các địa phương, tùy theo tình hình sẽ thành lập các lực lượng đặc biệt với sự tham gia của CSGT, Cảnh sát 113, Cảnh sát cơ động tổ chức cắm chốt và tuần tra lưu động tại những địa bàn phức tạp để phối hợp kiểm tra, xử lý các đối tượng điều khiển xe máy lạng lách, đánh võng, đua xe như mô hình TP.Hà Nội đang làm và đang chứng tỏ có hiệu quả”, ông Tuyên cho biết. Thái Sơn Tags:Đua xetruy tốNguyễn Văn Tuyên Bình luận Gửi bình luận Ý kiến của bạn sẽ được biên tập trước khi đăng. Xin vui lòng gõ tiếng Việt có dấu Tối thiểu 10 chữ Tiếng Việt có dấu Không chứa liên kết

X-Cache: MISS from xCache11-01

Vary: Accept-Encoding

Set-Cookie: .ASPXANONYMOUS=8r78phlT7XVZZbviv8C92LCfSXJklWdmPuLVi6t5wiBwRDn0Ve6SZTEPu3-IGbpbfW2TPpGroj9aGLKKuaeXWiG22x-TZDxdCf296Q88J_hJJpjqUBx5_jU93GCyQo6BSsx_B53-qnaondYs6HrXjQ2; domain=thanhnien.vn; expires=Thu, 30-Nov-2017 18:32:00 GMT; path=/; HttpOnly


markdown: Facebook Chia sẻ Google+ Twitter Email Vui sống mỗi ngày, chương trình truyền hình mới, do VTV và Công ty Chu Thị sản xuất, sẽ phát sóng lúc 11 giờ từ thứ hai đến thứ sáu hằng tuần trên VTV3, từ 14.2. Được xây dựng với nội dung gần gũi, dành cho khán giả từ 18 tuổi trở lên, chương trình gồm 5 phần: Gam màu cuộc sống, Trò chuyện cuộc sống, Tận hưởng cuộc sống, Ẩm thực cuộc sống và Kỹ năng cuộc sống. Qua đó, MC của Vui sống mỗi ngày (diễn viên Thanh Vân, người mẫu Phương Mai, đạo diễn Lê Hoàng...) sẽ cùng các khách mời là chuyên gia trong các lĩnh vực, người nổi tiếng... cung cấp những thông tin hấp dẫn cần thiết. N.V Tags:cuộc sốngThanh VânPhương Mai Bình luận Gửi bình luận Ý kiến của bạn sẽ được biên tập trước khi đăng. Xin vui lòng gõ tiếng Việt có dấu Tối thiểu 10 chữ Tiếng Việt có dấu Không chứa liên kết

Set-Cookie: .ASPXANONYMOUS=e7xYwckN4xIZooH6tM9TXkZsgLMwuUtXP53wajj58Dbz0Pipl_9rmALCtbXxZ9SDKoNzQkrR2xtmoyEfHnaRYg4FX1eYNhqK-HVPKoolPnOnAezaXK9nyrmIRJetu2qicbSFjlxAndtDI9GpCwnkOg2; domain=thanhnien.vn; expires=Thu, 30-Nov-2017 18:48:24 GMT; path=/; HttpOnly


markdown:
Tin bán ôtô
1088
Tin bán xe hạng sang
178
Bán/cho thuê xe công trình
288
Bán/thuê xe chuyên dụng
293
Xe khách-xe du lịch - xe Bus
96
Tin bán xe tải
566
Phụ tùng xe tải & công trình
299
Tin bán phụ tùng
579
Tin bán phụ kiện
875
Dụng cụ &Thiết bị sửa chữa
92
Dịch vụ thuê xe & vận tải
537
Dịch vụ xe cưới
210
Dịch vụ vận tải
20
Dịch vụ sửa xe
379
Dịch vụ chăm sóc xe
385
Dịch vụ độ xe
100
Sơn, thân vỏ, gầm xe
87
Điểm gửi xe & trạm xăng
66
Bảo hiểm
43
Cứu hộ-Sửa xe trên đường
47
Thủ tục-thông tin-trả góp
33
Kiến thức học lái xe
263
Danh ba website ôtô
149
Danh bạ salon & showroom
Danh bạ trường dạy lái xe
212
Bảng giá xe
9

Pragma: no-cache

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Content-Type: text/html


markdown:
21-06-14, 11:03 AM (Được chỉnh sửa: 21-06-14, 11:05 AM bởi
[changkhoonline77](http://thuthuataccess.com/forum/user-8326.html).)
Thấy diễn dàn có nói vấn đề này rồi nhưng là đối với file đã thêm rồi
Còn mình thì không thêm được Microsoft DAO 3.6 cho file access accdb (2007-2013). Mọi người có cách nào không?
Khi chọn thì nó báo lỗi
Còn mình thì không thêm được Microsoft DAO 3.6 cho file access accdb (2007-2013). Mọi người có cách nào không?
Khi chọn thì nó báo lỗi
![ [Hình: dao36_zps9bd18743.jpg]](http://i834.photobucket.com/albums/zz262/changkhoonline77/dao36_zps9bd18743.jpg)
![ [Hình: dao36_zps9bd18743.jpg]](http://i834.photobucket.com/albums/zz262/changkhoonline77/dao36_zps9bd18743.jpg)
![ [Hình: loi_zpsc56dd809.png]](http://i834.photobucket.com/albums/zz262/changkhoonline77/loi_zpsc56dd809.png)
![ [Hình: loi_zpsc56dd809.png]](http://i834.photobucket.com/albums/zz262/changkhoonline77/loi_zpsc56dd809.png)

Server: Apache

Cache-Control: no-cache, must-revalidate


markdown:
Đăng Nhập hoặc Đăng Ký
Tiền Việt Nam
Diễn đàn
>
THƯ VIỆN THAM KHẢO
>
Phòng trưng bày
>
BST Mô hình tỉ lệ thật
Trang 1 của 2
1
2
Tiếp theo >
Sort by:
Tiêu đề
Ngày bắt đầu
Trả lời
Lượt xem
Tin nhắn cuối ↑
Mô hình "Miền Tây hoang dã"
youngboss1vn
,
11/9/09
Trả lời:
2
Lượt xem:
1,006
youngboss1vn
11/9/09
Khu trục Hạm SOVREMENNY 698 (Scale 1/200)
youngboss1vn
,
12/9/09
Trả lời:
2
Lượt xem:
2,301
youngboss1vn
12/9/09
Hàng Không Mẫu Hạm Kuznetsov
youngboss1vn
,
12/9/09
Trả lời:
3
Lượt xem:
2,252
youngboss1vn
12/9/09
Mô hình WARRIOR MCV
youngboss1vn
,
18/9/09
Trả lời:
0
Lượt xem:
1,132
youngboss1vn
18/9/09
* Trực thăng vận tải quân sự CH-46E CURRENT U.S.MARINES "BULL FROG"
youngboss1vn
,
18/9/09
Trả lời:
0
Lượt xem:
1,155
youngboss1vn
18/9/09
Máy bay ném bom B29 USAF
youngboss1vn
,
18/9/09
Trả lời:
1
Lượt xem:
1,431
graffboy
18/9/09
Hàng không mẫu hạm U.S.CVN-68 NIMITZ (1975)
youngboss1vn
,
18/9/09
Trả lời:
1
Lượt xem:
2,289
youngboss1vn
18/9/09
* Máy bay trực thăng UH
youngboss1vn
,
18/9/09
Trả lời:
0
Lượt xem:
1,450
youngboss1vn
18/9/09
Trực Thăng Ch-53e Super Stallion "u.s Marines Version"
youngboss1vn
,
18/9/09
Trả lời:
0
Lượt xem:
1,163
youngboss1vn
18/9/09
D-day june 6, 1944: The climactic battle of world war II
youngboss1vn
,
18/9/09
Trả lời:
3
Lượt xem:
1,147
youngboss1vn
18/9/09
máy bay chiến đấu F18A Hornet
youngboss1vn
,
18/9/09
Trả lời:
1
Lượt xem:
1,257
youngboss1vn
18/9/09
TRỰC THĂNG UH-60 Black Hawk Merchandise
youngboss1vn
,
18/9/09
Trả lời:
2
Lượt xem:
1,496
graffboy
18/9/09
Tank M1A1 (HA) "ABRAMS"
admin
,
9/10/09
Trả lời:
0
Lượt xem:
1,256
admin
9/10/09
Chinese DF-21 BALLISTIC MISSILE LAUNCHER MOUNTED
admin
,
9/10/09
Trả lời:
1
Lượt xem:
1,374
admin
9/10/09
Tàu chiến PT 15 (Japan)
admin
,
9/10/09
Trả lời:
0
Lượt xem:
1,222
admin
9/10/09
Trực thăng HTL-4 US COAST GUARD
youngboss1vn
,
9/10/09
Trả lời:
0
Lượt xem:
1,131
youngboss1vn
9/10/09
xe tải quân sự M923 A1 Big Foot
youngboss1vn
,
9/10/09
Trả lời:
0
Lượt xem:
1,785
youngboss1vn
9/10/09
JGSDF TYPE 90 TANK W/MINE ROLLER (japanese)
youngboss1vn
,
9/10/09
Trả lời:
0
Lượt xem:
1,126
youngboss1vn
9/10/09
M12 155mm GUN MOTOR CARIAGE
youngboss1vn
,
9/10/09
Trả lời:
0
Lượt xem:
1,239
youngboss1vn
9/10/09
M60A1 BLAZER w/KMT4 MINE ROLLER
youngboss1vn
,
9/10/09
Trả lời:
0
Lượt xem:
1,512
youngboss1vn
9/10/09
Sa Bàn Chiiến Tranh Thế Giới
admin
,
12/9/09
Trả lời:
4
Lượt xem:
1,470
youngboss1vn
25/7/10
máy bay chiến đấu F14A Tom cat
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
738
youngboss1vn
31/7/10
xe vận tải quân sự Slt_Elefant (Đức)
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
1,110
youngboss1vn
31/7/10
I.D.F M113 ZELDA w
youngboss1vn
,
31/7/10
Trả lời:
1
Lượt xem:
962
youngboss1vn
31/7/10
M163 Vulcan
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
883
youngboss1vn
31/7/10
xe thiết giáp lội nước US Marines AAV7 WAAK
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
1,228
youngboss1vn
31/7/10
Mô hình M-113 fitter
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
1,010
youngboss1vn
31/7/10
I.d.f m60a1 blazer mbt
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
974
youngboss1vn
31/7/10
Thiết giáp PUMA Heavy Amored Personnel Carier
youngboss1vn
,
31/7/10
Trả lời:
0
Lượt xem:
846
youngboss1vn
31/7/10
Gia đình tứ đại "Ác Nhân"
youngboss1vn
,
31/7/10
Trả lời:
3
Lượt xem:
1,368
youngboss1vn
31/7/10
Mô hình Chiến hạm SOVREMENNY 618 - Tỉ lệ: 1/200
youngboss1vn
,
3/4/12
Trả lời:
7
Lượt xem:
741
youngboss1vn
3/4/12
Mô hình Tàu sân bay AKAGI (Đế qốc Nhật - 1942 WW II)
youngboss1vn
,
17/4/12
Trả lời:
8
Lượt xem:
2,692
youngboss1vn
5/6/12
Mô hình Thiết giáp hạm RICHELIEU - Pháp 1939
youngboss1vn
,
4/6/12
Trả lời:
4
Lượt xem:
1,019
youngboss1vn
5/6/12
World War II - Krupp K5(E) ‘Leopold’ railway gun and BR-52 ‘Kriegslokomotive’
youngboss1vn
,
12/9/09
Trả lời:
4
Lượt xem:
1,904
youngboss1vn
17/4/15
đội đặc Nhiệm (biệt Kích)
youngboss1vn
,
31/7/10
Trả lời:
1
Lượt xem:
2,294
youngboss1vn
9/9/15
Tuần Dương Hạm Peter Đại Đế - Russia Navy Cruiser Pyotr Velikiy (Scale 1/350)
youngboss1vn
,
18/9/16
Trả lời:
0
Lượt xem:
50
youngboss1vn
18/9/16
Tàu khu trục hạng nhất của Hải quân Đế quốc Nhật Bản Yukikaze Operation Ten-Go 1945
youngboss1vn
,
18/9/16
Trả lời:
1
Lượt xem:
63
youngboss1vn
20/9/16
thiết giáp hạm của Hải quân Đế quốc Nhật Bản Japanese Battleship YAMATO (Premium Ver)
youngboss1vn
,
18/9/16
Trả lời:
1
Lượt xem:
42
youngboss1vn
20/9/16
thiết giáp hạm của Hải quân Đế quốc Nhật Bản Fusō (scale 1/350)
youngboss1vn
,
18/9/16
Trả lời:
2
Lượt xem:
37
youngboss1vn
20/9/16
Tàu sân bay Aircraft Carrier KAGA (Three Flight Deck Version Full Hull) (Scale 1/700)
youngboss1vn
,
19/9/16
Trả lời:
2
Lượt xem:
69
youngboss1vn
20/9/16
Tàu Tuần Dương hạng nặng IJN Heavy Cruiser TAKAO - Full Hull Model (Scale 1/700)
youngboss1vn
,
19/9/16
Trả lời:
1
Lượt xem:
45
youngboss1vn
20/9/16
Thiết giáp hạm USS New Jersey (BB-62) - Scale 1/350
youngboss1vn
,
4/11/16
Trả lời:
0
Lượt xem:
51
youngboss1vn
4/11/16
Thiết giáp hạm MUSASHI - Hải quân Đế quốc Nhật Bản (Scale 1/700)
youngboss1vn
,
12/11/16
Trả lời:
1
Lượt xem:
55
youngboss1vn
26/11/16
Thiết giáp hạm Kii - Hải quân Đế quốc Nhật Bản (Scale 1/700)
youngboss1vn
,
26/11/16
Trả lời:
1
Lượt xem:
38
youngboss1vn
11/12/16
Tàu sân bay KAGA - Hải quân Đế quốc Nhật Bản (Scale 1/350)
youngboss1vn
,
12/11/16
Trả lời:
1
Lượt xem:
51
youngboss1vn
12/12/16
tàu sân bay AKAGI - Hải quân Đế quốc Nhật Bản (Scale 1/700)
youngboss1vn
,
14/12/16
Trả lời:
1
Lượt xem:
133
youngboss1vn
14/12/16
Thiết giáp hạm MUSASHI - Hải quân Đế quốc Nhật Bản (Scale 1/350)
youngboss1vn
,
14/12/16
Trả lời:
1
Lượt xem:
104
youngboss1vn
14/12/16
Tàu sân bay Shōkaku - Hải quân Đế quốc Nhật Bản (Scale: 1/350)
youngboss1vn
,
12/12/16
Trả lời:
1
Lượt xem:
44
youngboss1vn
14/12/16
Tàu sân bay Sōryū - IJN Aircraft Carrier Soryu ver. Full Hull (scale: 1/350)
youngboss1vn
,
5/2/17
Trả lời:
1
Lượt xem:
107
youngboss1vn
6/2/17
Tàu sân bay Hiryū - IJN Aircraft Carrier Hiryū Full Hull Model (scale: 1/700)
youngboss1vn
,
5/2/17
Trả lời:
1
Lượt xem:
113
youngboss1vn
6/2/17
Chủ đề hiển thị từ 1 đến 50 trong tổng 81
Tùy chọn hiển thị chủ đề
Phân loại chủ đề theo:
Thời gian gửi tin nhắn cuối
Thời gian tạo chủ đề
Tiêu đề (ABC)
Số bài trả lời
Số lần xem
Thích bài đầu tiên
Hiện chủ đề theo:
Thứ tự giảm dần
Thứ tự tăng dần
Đang tải...
(Bạn cần phải đăng nhập để viết bài)
Hiển thị nội dung Bỏ qua
Trang 1 của 2
1
2
Tiếp theo >
Tên của bạn hoặc địa chỉ email:
Bạn đã có tài khoản chưa?
Chưa, tôi muốn tạo một tài khoản.
Rồi, mật khẩu của tôi là:
Click vào đây nếu bạn quên mật khẩu
Ghi nhớ đăng nhập
Tiền Việt Nam
Diễn đàn
>
THƯ VIỆN THAM KHẢO
>
Phòng trưng bày
>
Diễn đàn
Diễn đàn
Liên kết nhanh
Tìm trong diễn đàn
Recent Posts
Thành viên
Thành viên
Liên kết nhanh
Notable Members
Lượt truy cập hiện tại
Hoạt động gần đây
UPLOAD ẢNH
Menu

X-Frame-Options: SAMEORIGIN


markdown:
Cần bán căn hộ 814 nhà CT13A khu đô thị Ciputra - Nam Thăng Long (ngay mặt đường Võ Chí Công). Nhà mới, còn nguyên bản
Giá bán: 64.51m2 x 28,5tr/m2 = 1.838.535.000đ
(Trong đó: Tiền gốc: 1.018.770.627đ + chênh lệch: 819.764.373đ)
Hướng cửa: Tây Nam
Ban Công 3 hướng: 3 mặt tiền, thoáng mát, Đông Nam, Đông Bắc, Tây Bắc.
Tòa nhà CT13A, CT13 có một vị trí thuận lợi về mọi mặt, nằm ngay mặt đường Võ Chí Công, cách Hồ Tây 500m có tầm nhìn rộng ra mặt Hồ Tây, hệ thống an ninh tốt, gần trường học, siêu thị, khu tiện ích. Nhà mới chưa có người ở, chi phí dịch vụ và bảo trì rẻ.
Người mua nhà chỉ thanh toán trước tiền chênh, tiền gốc nộp cho nhà nước => nhận nhà.
Liên hệ: 0984.632.955 (Linh)
( Chấp nhận qua trung gian)

Server: nginx


markdown:
[Hành trình Hạ Long: Tìm lại màu xanh cho biển](http://timeoutvietnam.vn/hanh-trinh-ha-long-tim-lai-mau-xanh-cho-bien-12226.html)
Vịnh Hạ Long một ngày cuối tháng 8 bỗng trở nên sôi động và tràn ngập màu áo xanh. Khung cảnh náo nhiệt đó không đến từ các đoàn khách du lịch mà bắt nguồn từ hơn 100 tình nguyện viên – những người đang cần mẫn thu gom rác để trả lại vẻ đẹp cho thiên nhiên vùng vịnh.Tác giả: oanhdh (Đỗ Hoàng Oanh)


markdown:
Mái
**tóc xoăn** sóng đẹp hè 2017 hút hồn sao kpop Hàn Quốc. Tóc xoăn gợn sóng tuy không tạo nên vẻ ngoài lộng lẫy, cầu kỳ như tóc xoăn bồng bềnh nhưng chính vì vậy mà kiểu tóc này lại có được sự tự nhiên, nhẹ nhàng và rất dịu dàng, nữ tính.
Mời bạn cùng tocdep2017.com chiêm ngưỡng những mái tóc xoăn gợn nhẹ tuyệt đẹp của các sao Hàn qua chùm ảnh dưới đây.
Mái tóc xoăn gợn nhẹ càng làm tôn thêm vẻ đẹp thuần khiết, dịu dàng của Park Shin Hye. Cô kết hợp kiểu tóc này với trang phục khá khỏe khoắn mà không hề bị “lệch tông”.
Nữ diễn viên tỏ ra ưu ái kiểu tóc này khi diện nó trong khá nhiều dịp và với nhiều phong cách khác nhau, khi khỏe khoắn, năng động, khi lại nữ tính, dịu dàng.
Nếu như trên sân khấu, HyunA thường chọn kiểu tóc xoăn bồng bềnh thì ngày thường, cô “refresh” cho diện mạo của mình với những lọn tóc xoăn nhẹ. Có thể thấy rằng nữ ca sỹ vẫn không hề kém xinh đẹp và quyến rũ.
Kiểu tóc với những lọn xoăn gợn tập trung ở phần đuôi rất hợp với vẻ ngoài nhu mì của Yoona. Để tạo thêm sự khác biệt, cô kết hợp kiểu tóc này với mái thưa cũng được uốn xoăn nhẹ.
Thời gian gần đây, Yoona diện kiểu tóc này khá thường xuyên.
Tiffany khiến fan ngây ngất với vẻ ngoài ngày càng xinh đẹp. Trong đó, mái tóc óng ả với đuôi tóc uốn xoăn lọn to bồng bềnh cũng là một trong những điểm nhấn khiến cô nàng trông ngọt ngào hơn.
Những thành viên khác của SNSD như Yuri…
… và Seohyun cũng rất “kết” kiểu tóc nhẹ nhàng này.
Mái tóc ngắn của Suzy trông bắt mắt và có sức sống hơn hẳn khi được uốn xoăn gợn nhẹ như thế này.
Sulli (f(x)) cũng biến hóa cho mái tóc ngắn của mình bằng cách uốn xoăn nhẹ. Kiểu tóc này rất phù hợp với khuôn mặt vẻ đẹp trong sáng của cô nàng.
*Thời gian gần đây, nhiều sao nữ Hàn rất ưa chuộng kiểu tóc xoăn nhẹ gợn sóng. Khác với kiểu tóc xoăn bồng bềnh quen thuộc, đặc trưng của của kiểu tóc này là những gợn xoăn rất nhẹ và thường tập trung nhiều ở phần đuôi tóc. Chúc các bạn gái sẽ có 1 mái tóc đẹp.*

LCache: BYPASS

Link: <http://tocdep2017.com/wp-json/>; rel="https://api.w.org/", <http://tocdep2017.com/?p=1864>; rel=shortlink