Kiến trúc sư phần mềm - anh là ai?

Saturday, February 7, 2009 1 phản hồi

Là dân IT hẳn mọi người không còn xa lạ với cụm từ Software Architect (SA) - ở đây tôi tạm dịch là kiến trúc sư phần mềm. Tuy nhiên không phải ai cũng hiểu được vai trò, trách nhiệm, công việc thực sự và con đường sự nghiệp của một SA. Đây là những câu hỏi mà tôi đã từng đặt ra khi bước vào những nấc thang đầu tiên của vị trí này. Tôi tự đi tìm lời giải đáp cho mình.
Microsoft Software Architect

Phân loại kiến trúc sư phần mềm

Thật ra có nhiều cách để phân loại kiến trúc sư phần mềm. Tuy nhiên, ở đây tôi sử dụng cách phân loại của Microsoft.  Đây cũng là một cách thức phân chia khá phổ biến trong ngành phần mềm hiện nay.



Tên

Mô tả
Kiến trúc sư nghiệp vụ (enterprise architect)Là cầu nối giữa chủ sở hữu sản phẩm và đội ngũ kĩ thuật. Họ  là những người có kinh nghiệm chiều sâu trong lĩnh vực mà sản phẩm đang xây dựng.
Chịu trách nhiệm trong việc xây dựng và phát triển yêu cầu - thiết lập viễn cảnh, bộ khung của môi trường IT trong sản phẩm.
Kiến trúc sư hạ tầng (infrastructure architect)Là người chịu trách nhiệm trong việc thiết lập, xây dựng giải pháp về cơ sở hạ tầng IT (ví dụ: mạng, các vấn đề bảo mật, thiết bị/ phương thức lưu trữ, ..) trong sản phẩm để đáp ứng nhu cầu của doanh nghiệp.
Kiến trúc sư giải pháp (solution architect)Là người chịu trách nhiệm trong việc thiết kế, xây dựng giải pháp cho những yêu cầu của sản phẩm.
Kiến trúc sư kĩ thuật (Technology-specific architect)Là người chịu trách nhiệm về một hoặc một số lĩnh vực kĩ thuật cụ thể.

Trong một số công ty hiện tại ở Việt Nam, có một vị trí gọi là Technical Architect (kiến trúc sư kĩ thuật) trong tổ chức. Vị trí này chịu trách nhiệm cho việc phân tích, đánh giá giải pháp, xây dựng kiến trúc hệ thống. Nếu ánh xạ với cách phân loại trên thì TA chính là Solution Architect.

Những tính cách cần thiết của một kiến trúc sư phần mềm giỏi

Cho dù bạn có là kiến trúc sư phần mềm nào, thì dưới đây là những tính cách bắt buộc phải có để đạt được đỉnh cao của nghề này:

1. Nhạy bén về kinh tế: mọi kiến trúc sư khi đưa ra giải pháp cho bất cứ bài toán nào cũng đều phải cân nhắc chi phí, lợi ích tương quan của doanh nghiệp. Đây là yếu tố then chốt đánh giá hiệu quả của một giải pháp.
2. Có tầm nhìn xa: khi tham gia vào một dự án, kiến trúc sư phải cân nhắc những giải pháp, công nghệ sắp xuất hiện, xem xét những thay đổi gần đây trong lĩnh vực công nghiệp đang phát triển... và làm cách nào để tận dụng tối đa giải pháp hiện tại trong tương lai.
3. Nghiên cứu kĩ thuật mới: một kiến trúc sư phải luôn luôn nghiên cứu những hướng kĩ thuật mới, từ kiến trúc IT cho đến những ứng dụng và xu hướng phát triển ứng dụng
4. Hiểu và có khả năng ứng dụng những framework,kiến trúc hệ thống, phương pháp luận trong quá trình phát triển phần mềm
6. Có thể làm việc trên những thông tin còn chưa rõ ràng.
7. Khả năng truyền đạt và giao tiếp

Làm sao để tôi có thể trở thành một kiến trúc sư phần mềm

Kiến trúc sư phần mềm là đỉnh cao của thang nghề nghiệp khi bạn chọn đi theo con đường kĩ thuật. Để trở thành một kiến trúc sư phần mềm, bạn nên theo những bước sau:
1. Định hướng rõ ràng về loại kiến trúc sư phần mềm bạn muốn trở thành
2. Xác định và xây dựng những kĩ năng cần thiết. Liên tục bổ sung kiến thức phù hợp cho loại hình kiến trúc sư mà bạn chọn
3. Không ngừng phấn đấu và khẳng định vai trò của một kiến trúc sư trong chính những dự án mà bạn đang tham gia.
4. Cố gắng rèn luyện và lấy những chứng chỉ quốc tế về kiến trúc sư kĩ thuật của những tập đoàn công nghệ lớn (Microsoft hoặc Sun). Microsoft bạn cần lấy được MCA (Microsoft Certificate Architect). Đối với Sun, bạn cần lấy được chứng chỉ: SCEA (Sun Certificate Enterprise Architect)

Con đường để trở thành một kiến trúc sư phần mềm đỉnh cao và chuyên nghiệp vẫn còn ở rất xa. Và có một điều tôi luôn tâm niệm là: dù ở bất kì ngành nghề nào, vị trí nào - việc phấn đấu để đạt được đỉnh cao trong sự nghiệp cũng đều đem lại những lợi ích như nhau so với những vị trí hoặc ngành nghề khác.

Cố gắng hơn nữa!

Request đi từ Windows live writer preview mode - tìm ra rồi

Sunday, February 1, 2009 0 phản hồi

Vừa ăn Tết xong đã bị khách hàng dzí vì một issue trên plugin viết cho Windows Live Writer. Issue đơn giản như thế này:

Module mình vừa release là một plugin viết cho Windows Live Writer (một công cụ soạn thảo blog của Microsoft có thể tích hợp với nhiều blogging platform). Chức năng chính của module là cho phép tìm kiếm một số thông tin đặc biệt và nhúng nội dung tìm được vào cửa sổ blog editor của Windows Live Writer. Khách hàng mong đợi ở chế độ preview của editor này có thể nhìn thấy nội dung hiển thị như khi xem trên blog thật. Tuy nhiên, vì một số hạn chế kĩ thuật dưới đây nên ở preview mode, html content bị vỡ layout và không show được một số phần content liên quan đến business của khách hàng.
1. Windows Live Writer sử dụng một browser engine khác trong preview mode và chặn một số script đặc biệt
2. Cơ chế render nội dung của browser engine này xử lý không tốt cho CSS 2.0 => vỡ layout.

Chính vì những hạn chế này, product manager của khách hàng yêu cầu: chỉ render ra một nội dung HTML đơn giản (chỉ show image tag) ở chế độ preview mode.

Sau khi suy nghĩ về solution trong vài ngày đầu - mình hoàn toàn bị tắc nghẽn. Vì để làm được điều này ta cần biết được request nào đi từ Windows Live Writer và request nào đi từ browser mà user đang duyệt web bình thường. Biết được điều đó ta có thể chặn và render ra những đoạn javascript để sinh ra HTML đúng như mong đợi.

Dưới đây là những phương pháp tôi đã thử:
1. Phân tích http request header khi đi từ Windows Live Writer và request đi từ các browser khác.
Kết quả: hoàn toàn giống nhau. WLW sử dụng một browser engine build từ một version trước của Internet Explorer.
2. Kiểm tra URL referer ở phía client trên WLW và các browser khác:
Kết quả: đều bằng null. Điều này chứng tỏ: WLW preview page được render trực tiếp mà không đi qua trang trung gian nào

Đã trao đổi với technical team của khách hàng để họ hiểu được issue. Critical bug này được chuyển sang cho một developer của team họ để giải quyết. Kết quả: Họ cũng không có solution sau hơn 3 tuần mò mẫm.
Tuyệt vọng!!!

Ngày đầu năm, bị sếp dzí và cho biết khách hàng đang complain. Sếp yêu cầu viết mail cho Microsoft nhờ support. Lên trao đổi với anh T - production manager để giúp anh hiểu vấn đề về những khó khăn hiện tại.
Bước ra khỏi thang máy với cái đầu hoang mang trăm chuyện. Quyết định: uống một ly cafe cho sáng suốt. Đúng là cafe có tác dụng cho những hoàn cảnh như thế này. Uống xong bỗng lóe lên một hy vọng.
Phát hiện ra là mình chưa kiểm tra URL referer khi WLW request về phía server (lúc trước chỉ kiểm tra toàn http header).
Và dưới đây là kết quả:
Đứng từ WLW ở preview mode khi request về server thì URL Referer luôn bằng null. Thông thường, khi ta include một file javascript vào một trang - nếu chặn ở server ta sẽ thấy URL referer của request đến nó chính là URL của trang đang chứa đoạn script include này. Riêng với WLW, nó lại là NULL. Đây chính là tín hiệu giúp ta phân biệt được đâu là request từ Windows Live Writer và đâu là request đi từ browser bình thường.

Xong!

Tuyển dịch - Core J2EE patterns best practices and design strategies

Thursday, January 29, 2009 0 phản hồi

Core J2EE patterns - best practices and design strategies là một trong những quyển sách hay dành cho lập trình viên - được biên soạn bởi Deepak Alur, John Crupi, Dan Malks. Cho dù bạn có là tín đồ của .NET, PHP, Ruby, ... tôi khuyên bạn vẫn nên đọc qua nó - nếu bạn muốn mình có thể đạt đến một trình độ kĩ thuật cao hơn (ở mức độ thiết kế và xây dựng kiến trúc hệ thống phần mềm).

Tôi sẽ lựa chọn một số chương mà tôi tâm đắc để dịch và giới thiệu đến mọi người.
Tuy nhiên tôi sẽ không dịch sát nghĩa trên nội dung mà sẽ viết lại theo cảm nhận và cách hiểu của mình. Nội dung dịch sẽ bám sát theo tư tưởng: phân tích và giải thích vấn đề không bị phụ thuộc vào ngôn ngữ. Do đó nếu bạn muốn hiểu sâu về chi tiết và cách hiện thực trên J2EE thì nên đọc từ ebook tiếng Anh.

Một quyển sách khác mà tôi cũng khuyên bạn nên đọc là: Enterprise Solution patterns Using Microsoft.NET. Đây là quyển dành cho lập trình viên .NET. Tuy nhiên xét về nội dung thì các pattern này cũng gần như tương tự nhau - chỉ khác nhau về cách hiện thực chi tiết trên mỗi platform.

Mục đích của việc dịch và giới thiệu quyển sách này là muốn chia sẻ với mọi người
Nếu các bạn thấy có những đoạn dịch chưa chuẩn hoặc làm mọi người hiểu sai ý nghĩa xin vui lòng đóng góp và gửi mail cho mình: tran.dang.khoa.khtn@gmail.com

Danh sách những chương sách đã dịch sẽ được cập nhật qua bài viết này
(hiện tại chỉ mới dịch xong chương 1)

Chương 1: Giới thiệu

Tết Trâu Vàng

Wednesday, January 28, 2009 0 phản hồi

Xuân này tiễn Chuột đón Trâu, xin post một câu đối xuân để tặng mọi người.
Chúc tất cả bạn bè, đồng nghiệp và những người thân của tôi một năm mới an khang thịnh vượng - may mắn và thành đạt.




Riêng tôi lại "già" thêm một tuổi nữa rồi...

Xuân khứ bách hoa lạc
Xuân đáo bách hoa khai
Sự trục nhãn tiền quá
Lão tòng đầu thượng lai
...
(Mãn Giác thiền sư)

Napoleon Hill và Cách nghĩ để thành công

Tuesday, January 27, 2009 0 phản hồi

Có nhiều quyển sách để lại ấn tượng trong tôi, nhưng ít có quyển sách nào để lại trong tôi những "ám ảnh" sâu sắc đến thế.

Cách nghĩ để thành công là quyển sách đầu tiên đưa ra triết lý của sự thành đạt - được viết ra từ vô số những câu chuyện có thật của những người vĩ đại như Edison, Henry Ford,... những con người phần lớn đi lên từ 2 bàn tay trắng và đôi khi còn bị xem là thất học. Tuy nhiên họ đã để lại những dấu ấn thành công rực rỡ và những đóng góp vĩ đại cho nhân loại. Tác giả Napoleon Hill đã dành cả cuộc đời mình để phỏng vấn những con người như thế và đã đúc kết những nguyên lý dẫn đến thành công trong một quyển sách - mà theo tôi là kim chỉ nam cho những con người luôn đặt câu hỏi cho mình: tại sao tôi chưa thành công?

Dưới đây là một số trải nghiệm của tôi từ quyển sách này
1. Biết rõ các mục tiêu trong đời đã là đi được một nữa chặng đường đến sự thành công"
2. Hãy biến mục tiêu của bạn thành nỗi ám ảnh và sự khát khao tột bực. Nỗi ám ảnh đó sẽ chi phối đến tư duy, tiềm thức của bạn để chỉ cho bạn con đường đến thành công.
3. Đừng bao giờ từ bỏ mục tiêu, bởi vì: kẻ chiến thắng không bao giờ từ bỏ. Kẻ từ bỏ sẽ không bao giờ chiến thắng
4. Đừng bao giờ lo lắng rằng khó khăn sẽ đến với mình và dù đó có là sự thật hiển nhiên thì cũng không được phép nản lòng.
5. Không người nào đạt đến những thành công vĩ đại mà không chấp nhận hy sinh
6. Để thành công cần phải có sự liên kết với những con người nhiệt huyết, có khả năng và có cùng chí hướng
7. Bạn không nhất thiết phải trở thành người xuất sắc nhất trong mọi lĩnh vực. Sức mạnh trí tuệ mà bạn có chính là kiến thức của những con người mà bạn liên kết được.
8. Kiến thức không phải là những gì bạn nên biết mà là những gì bạn cần áp dụng để đạt được mục tiêu.

Rất khó để diễn đạt những ám ảnh của tôi sau khi đọc xong "Cách nghĩ để thành công". Có thể bạn sẽ có những trải nghiệm khác với những gì tôi đã rút ra. Hãy đọc thử xem!

Không đề

Wednesday, January 21, 2009 0 phản hồi

Hôm nay có chút thời gian rảnh rỗi (vì phải install Mac OS và Ubuntu trên máy) nên quan sát một chút không khí làm việc của anh em xung quanh. Thấy một số bạn senior đang ngồi chơi game trong giờ làm việc. Chợt thấy buốn vô cùng. Tôi không trách các bạn, nhưng tôi tự đặt cho mình 3 câu hỏi:
1. Có phải các bạn đang chán công việc hiện tại? Điều gì làm cho các bạn cảm thấy chán? Liệu có ai hiểu được sự chán nản đó và chia sẻ với các bạn không?
2. Có phải các bạn không ý thức được việc mình đang làm ảnh hưởng đến bầu không khí văn hóa của công ty? là những vị trí ở cấp độ senior, nếu không thể kiểm soát được chính mình thì bạn không thể lead được người khác. Tôi mong các bạn không làm thế trong giờ làm việc nữa.
3. Phải chăng có một lỗ hỗng trong cơ chế xét duyệt promotion của công ty? nếu có, nó nằm ở đâu?

Chợt nhớ đến câu thơ của Vũ Đình Liên:
Những người muôn năm cũ.
Hồn ở đâu bây giờ?

... Than ôi, phải chăng những người tâm huyết ngày càng ít đi?

Đọc "Refactoring" của Martin Fowler

Tuesday, January 20, 2009 0 phản hồi

Refactoring là một trong những quyển sách đáng đọc cho lập trình viên. Sách được viết và biên soạn bởi những cây đại thụ trong làng kĩ nghệ phần mềm: Martin Fowler, Kent Beck, John Brant, William Opdyke và don Roberts

Refactoring: Improving the Design of Existing Code (Addison-Wesley Object Technology Series)


"Refactoring" không phải là một quyển sách mới. Quyển mà tôi đọc được ấn hành vào năm 2002 (có ghi một dòng: Another stupid release 2002
For all the people which doesn’t have money to buy a good book - dành cho những kẻ ko có tiền mua sách :-). Có lẽ tác giả cũng khá vui tính). Trước đây tôi chỉ đọc lướt qua, chủ yếu là học chiêu. Giống như bọn giang hồ chỉ thích học lóm chiêu pháp của người khác mà không luyện qua những chiêu thức căn bản. Đến sau này có thời gian đọc lại, tôi mới thấu hiểu những tinh hoa nằm sau nội dung sách.

Một chương trình, xét cho cùng cũng chỉ là một tập những dòng mã. Do đó giá trị của một chương trình ngoài những giá trị về chức năng - kinh tế nó cung cấp cho khách hàng, còn một yếu tố quan trọng nữa là: chất lượng mã nguồn. Mã nguồn được đánh giá là tốt khi nó thỏa mãn các yếu tố:
1. Có giá trị cao về mặt kinh tế
2. Độ bao phủ test gần 100%
3. Có tính đơn giản
4. Không trùng lặp
5. Có sức biểu đạt cao.
(Trích từ phát biểu của Robert C.Martin về "thế nào là mã nguồn tốt")

Refactoring - tạm dịch là tinh chỉnh mã nguồn - là hoạt động giúp ta đạt được 3 yếu tố (3) (4) (5). Trong đó yếu tố số 5 được xem là yếu tố then chốt cần đạt được trong refactoring.
Dưới đây tôi giới thiệu tổng quan một số chương sách để giúp bạn có một góc nhìn ban đầu.

Chương 1 của quyển sách đưa ra một ví dụ đầu tiên về refactoring thông qua một đoạn mã nguồn cụ thể và áp dụng refactoring để làm cho mã nguồn trở nên dễ đọc hơn.

Chương 2 nói về những nguyên tắc của refactoring. Đây là chương chưa đựng nhiều giá trị đáng đọc. Nó trả lời giúp tôi những câu hỏi thú vị: tại sao cần refactoring? tôi phải nói với sếp điều gì khi tôi muốn refactor mã nguồn của tôi? Mối quan hệ giữa refactoring và design? Mối quan hệ giữa refactoring và hiệu suất chương trình.

Chương 3: Giúp bạn phát hiện mã xấu. Đây cũng là một chương rất quan trọng vì nó giúp bạn hình thành nên ý niệm giữa cái tốt và xấu trong mã nguồn

Chương 4: Giúp bạn ý thức về việc viết Unit test để đảm bảo mã nguồn của bạn chạy đúng. Các unit test cũng giúp bạn phát hiện sai lầm trong quá trình refactoring.

Từ chương 5 đến chương 13 là những chương dạy cho bạn chiêu pháp để tinh chỉnh mã nguồn.
Chương 14 bàn thêm về những công cụ hỗ trợ refactoring

Tôi đánh giá rất cao 4 chương đầu tiên của quyển sách. Chúng được xem là những chiêu thức căn bản và tạo nên tinh hoa của quyển sách này.

Về các chiêu thức để refactoring (HOW), tôi tạm chia chúng ra làm 4 cấp bậc:

Cấp 1: các chiêu thức sử dụng để refactor những đoạn mã nguồn nhỏ (các quy tắc đặt biến, biểu thức điều kiện, loại bỏ parameter thừa, ...)
Cấp 2: Cấp độ phương thức (method)
Cấp 3: Cấp độ class
Cấp 4: Cấp độ thuật toán và thiết kế hệ thống


Thực chất, không cần phải nhớ hết tất cả những chiêu thức trong sách. Để đọc quyển sách này một cách hiệu quả, tôi làm như sau:
- Ghi nhớ tinh thần và các ý niệm của 4 chương đầu tiên.
- Mở lại những đoạn mã nguồn cũ - tìm ra những đoạn mã xấu.
- Xác định các module cần refactor
- Viết Unit test cho những hàm mà module cung cấp ra ngoài. (vì trước đây tôi ít viết Unit test cho những đoạn mã nguồn cũ)
- Đọc tiếp các chiêu thức còn lại. Sau mỗi chương, tôi thực hành ngay trên những module tôi xác định muốn refactor.
Đó là cách mà tôi đọc và thực hành trên quyển sách này. Còn bạn?