Đôi điều về việc đi làm

28 tuổi, đi làm được 6 năm, nhảy 2 công ty.

Rút ra được đôi điều.

1. Ai cũng có lúc trẻ tuổi và mắc sai lầm, vấn đề là làm sao để nó ngắn ngắn thôi

Chẳng ai cho không ai cái gì cả, đơn giản là như vậy. Công ty đầu tiên của tôi là một công ty hàng đầu về phần mềm trong nước, chuyên cung cấp giải pháp trọn gói cho các doanh nghiệp trong nước. Chuyện chẳng có gì nếu không có cái yếu tố nhà nước gắn vào, công việc đơn giản nhẹ nhàng, áp lực ít, chất xám ít, nghiêm túc cũng ít. Cụ tỉ, tôi đi làm vào lúc 9 rưỡi và về nhà ăn cơm lúc 11 rưỡi, sau đó ngủ đến 2h và có mặt ở công ty vào lúc 2 rưỡi, ngày làm việc như vậy kết thúc vào lúc 5h, rất đều đặn. Đương nhiên, lương của tôi ì ạch tăng từng… trăm nghìn một và đi cùng với đó là sự ỳ trệ về đầu óc, lạc hậu về tư duy và công nghệ. Tôi vật lộn ở đó 5 năm và phải rất cố gắng để có thể chấm dứt những suy nghĩ tiêu cực đã kéo tôi ở lại  công ty đó suốt từng ấy năm trời.

Bài học rút ra: chẳng công ty nào đáp ứng được một loạt nhu cầu: lương cao, việc nhàn, ít áp lực, vấn đề là bạn không được ngủ quên trên sự sung sướng và nhàn tản, rồi bạn sẽ tiếc nuối khoảng thời gian đó khi bạn trưởng thành.

2. Hãy thông minh khi cống hiến cho công ty mà bạn được trả lương

Khi tham gia vào bất cứ công ty nào, tôi luôn quan tâm đến các vấn đề sau:

– Tôi học được gì trong thời gian làm ở đó

– Lương, đãi ngộ của công ty dành cho mình và gia đình

– Cơ hội thăng tiến

Tôi đang tham gia vào 1 dự án thuộc dạng hiếm ở miền bắc, sử dụng các công nghệ vào dạng mới nhất và hay nhất hiện nay, xử lý các vấn đề đau đầu cũng thuộc dạng nhất hiện nay. Nhưng tôi quyết định xin nghỉ việc khi phát hiện ra tôi đã chững lại trong việc học hỏi suốt 1 khoảng thời gian dài, và cùng với đó, mức lương công ty trả cho tôi không còn đáp ứng được những gì tôi phải bỏ ra trong suốt thời gian làm ở đây.

Bài học rút ra: Khi công việc còn thỏa mãn được 2/3 các vấn đề trên, hãy cố gắng làm việc thật tốt, và quyết định sớm việc chuyển công ty khi thấy không được đáp ứng các vấn đề này. Một số ngoại lệ có thể xét tới, nhưng đại để thì tôi nghĩ cứ 2/3 là có thể quyết nhanh :).

3. Mơ lớn, nghĩ lớn và không dừng học hỏi

Tôi có một người anh, xuất phát điểm như các cậu thanh niên khác ở quê lên HN học, tay trắng, đầu óc ngây thơ và trong sáng, có chăng, anh khác tôi ở những giấc mơ lớn và khả năng học hỏi không ngừng nghỉ. Anh mới nhận một công việc với mức lương mơ ước và điều kiện làm việc giúp anh được trải nghiệm nhiều vùng đất mới. Điều làm anh khác tôi và những người còn lại ở chỗ, anh xác định được giấc mơ của mình, có thể nó lớn thật nhưng chẳng có gì là “impossible”, căn bản, ngay khi ta mơ ta đã nghĩ nó chỉ là giấc mơ, vậy là đã có 1 rào cản “nho nhỏ” ngăn cách chính ta với mục đích cuối. Hãy mơ lớn, có thể sẽ viển vông, có thể sẽ thật bại, nhưng tuổi trẻ là phải mơ, và mơ thì phải đi cùng với hành động thực tế. Tất nhiên, đừng quên việc học hỏi, vắt tay lên trán mơ mãi mà không học tập, trau dồi kiến thức thì cũng chẳng để làm gì :).

Note viết vội trong lúc em gái chờ lấy máy làm việc. Hơi nhạt!

Sub version (SVN) Tofu scale

Lang thang mò lại được một bài viết có các định nghĩa cơ bản trong SVN, phải bê ngay về để lưu trữ trong blog.
Bài viết “Sub version (SVN) Tofu scale” sưu tầm từ blog của thanhnp.wordpress.com
Một số khái niệm căn bản về svn:
Repository: Là nơi lưu trữ phiên bản mới nhất của file, cùng các phiên bản trước đó, và nó thường được đặt tại server
Version : Là là một phương pháp đặt tên, hay số duy nhất mỗi trạng cho trạng thái  của cây repository tại một thời điểm. Với version đặt tên bằng số, các số này được săp xếp theo thứ tự tăng dần. Phiên bản mới hơn sẽ có số lớn hơn.
Changeset: Changeset là một tập hợp những thay đổi với một tên là duy nhất, Những thay đổi có thể là những đoạn được edit trong một file nội dung, những thay đổi trong một cấu trúc cây… Changeset không lưu lại toàn bộ file khi bạn edit , nó chỉ lưu lại những điểm thay đổi , nó là một patch với một tên riêng biệt mà bạn có thể truy cập tới.
Project Layout: Nơi tập trung code của một project, chỉ chứa các file liên quan đến project không chứa những project con.
Repository Layout: Cấu trúc các thư mục để lưu các version của project, hay thư mục lưu tài liêu liên quan tới project , cho phép ta có thể check project theo từng giai đoạn.
Example:
  • Repository Layout
  • /branches
      • dev
        • 1.1.10/code   <= Project Layout
        • 1.1.11/code   –
      • releases
  • /tags
  • /trunk
Branches: Branches là một nhánh code được copy ra từ một nguồn code (có thể là trunk hay một branch khác), và nó đươc development một cách độc lập với các thành phần khác.
Branches được tạo ra với các mục tiêu:
  • Development độc lập với các revision hiện tại, và nó sẽ xuất hiện trong release version
  • Làm việc độc lập trong thời gian dài.
  • Sử dụng source code từ các developers khác.
Tags: làm một “snapshot” của một project tại một thời điểm. Trong subversion, mỗi revision là một snapshot cùa một repository filesystem sau mỗi lần commit,
Sprint: làm một kỹ thuật quản lý thời gian trong planing projects, trong đó schedule được chia ra thành từng quãng thời gian riêng biệt, với mỗi quãng thời gian thì có một mục tiêu, deadline.
The version control pattern:
Mainline là gì ?
Một branch được gọi là một codeline, như trên hình vẽ release 2.3, 2.4 hay Project x là một codeline.
Cha của một codeline được gọi là baseline, release 2.4 là baseline của release 2.4.1.
– Mainline là một codeline không có base line, trunk là mainline, mỗi resposotory chỉ có một mainline và nó phải thỏa điều kiện
– Can release at any time: Tại mọi thời điểm khi muốn có một sản phẩm mới ta đều có thể release trực tiếp từ mainline.
Theo ví dụ trên: line màu xanh là trunk (mainline). Mỗi green ball thể hiện một lần checkin, khi hoàn thành 5 phần thì kết thúc được một Sprint.  Chúng ta có thể release từ trunk bất cứ lúc nào, khi gặp sự cố không thể finish #5 ta vẫn có thể release.
– Want to release ASAP: Khi không muốn release #3, ta có thể kill branch, và release tới #2 như ở hình trên.
Tofu scale ?
Firm codeline“: là nhánh code ổn định, đã qua test, không thường xuyên thay đổi,  và là một nhánh release đã close.
Soft codeline“: là nhánh ít ổn định hơn, vừa thực hiện test, có thể bị thay đổi thường xuyên, và chưa đưa ra release
Qua ví dụ trên ta thấy, nếu Team B làm một nhánh code khác  merge trực tiếp từ Team A, điều này có thể sẽ dẫn tới nảy sinh rất nhiều lộn xộn trong code. thay vì làm điều đó , team A sau khi kết thúc team A sẽ đưa code của mình lên mainline, và team B sẽ down từ mainline xuống làm.
Mọi nhánh nằm trên mainline được gọi là release codeline. Release codeline firmer hơn mainline.
Mọi nhánh nằm dưới mainline được gọi là development codeline.development codeline softer hơn mainline.
Với ví dụ tại hình trên ta thấy:
  • Project x là một codeline được sinh ra từ mainline. Khi project hoàn thành, thì branch đó sẽ được đóng lại.
  • Team A đang làm việc trên một codeline được sinh ra từ mainline
  • Team A cũng đang song song thực hiện module Spike, module Spike này  có thể có lỗi vì vậy nếu thực hiện chung với branch A có thể gây cho Project A bi lỗi,  khiến team A không thể thực hiện song song được vì vậy tách ra thanh một branch Team A spike khác.
  • release 2.3 branch đã được close, RULES: Không để cho hai nhánh release cùng open, muốn release 2.4 phải close branch release 2.3
Với Tofu scale, ta dễ dàng thấy được rằng
  • Release 2.3 firmer hơn mainline.
  • Team A work softer hơn mainline
  • Team a spike softer hơn Team A work
Qua hình ảnh bên trên ta thấy rằng:
  • Bất kỳ khi nào có thay đổi trên realease codeline, những thay đổi này nên lập tức được merge down (Flow down ) to baseline, tất cả nên được merge xuống mainline
    • Example: khi một bug được fix tại R2.4.2. Nó nên được merge down to R2.4, và sau đó merge từ R2.4 xuống mainline.
  • Release codeline không bao giờ được nhận thay đổi từ baseline.
    • Example: Khi một new code được check tới mainline (từ nhánh dev copy up (flow up) lên), nó không nên được truyền tới R2.3, và R2.4
  • Mọi thay đổi trên baseline nên nhanh chóng được merge down xuống development codeline.
    • Example: Mọi thay đổi từ codeline nên được nhanh chóng merge down xuống Tearm A, Team B, khi Team A merge down xong thông báo với A spike, Merge down từ Team A xuống A spike.
  • Chỉ copy up từ development codeline  lên baseline khi chắc chắn nó đã stable points.
    • Example: Team B copy up to mainline khi đã hoàn thành và qua test.
    • A spike chỉ copy up lên Team A khi đã finished và tested.
Branch owner làm gì?
  • Mỗi một branch nên có một người là owner chịu trách nhiệm về branch đó
  • Quyết định xem có nên tách một codeline từ branch này hay không.
  • Thông báo tới tất cả các codeline khác sinh ra từ branch update khi baseline thay đổi
  • Mọi người làm việc trên codeline, phải biết baseline owner của mình để merge code khi baseline owner báo baseline thay đổi.
Khi nào tôi nên add new branch ?
  • Khi phát triển những new features, nên check code từ trunk, add a new branch và develop trên đó.
  • Khi finish một task, nhưng task này chưa được test, cần một nơi để có thể check code, nơi mọi người trong cùng team có thể làm việc với code.
Khi nào nên merge code từ baseline ?
  • Nên thường xuyên merge code từ baseline, càng sớm càng tốt, hàng ngày, tìm và giải quyết các conflict xảy ra lúc đó.
  • Khi baseline owner thông báo có thay đổi trên baseline.
Resolve conflicts trên branch kém ổn định nhất
  • Nếu bạn bị confict code , bạn nên resolve nó ngay lập tức, nếu code confict được check từ một nhánh khác, nên tìm branch owner của nhánh đó giúp resolve conflict.
Khi nào tôi nên Merge code với Trunk ?
  • Nên merge code thường xuyên với Trunk, khi bạn kết thúc một phần và đã test kỹ, nên merge nó với trunk, tránh để tới cuối cùng mới merge, điều này khiến bài toán merge trở nên bớt phúc tạp và mất thời gian hơn.
Release Branches
Sau khi kết thúc sprint 1 và released version 1.0.0, và đã thực hiện xong một số phần của sprint 2,qua quá trình test phát hiện một số bug của release 1.0.0. Tôi phải làm gì ?
  • Tạo một release branch gọi là release 1.0, từ nhánh release 1.0.0
  • Fixbug trên nhánh này
  • Merge từ nhánh release xuông trunk ngay khi fix xong, và release ban 1.0.1
Làm thế nào để release code lên Trunk ?
Hiện tại bạn đã finish code tại branch Team B , tested  tại development branch và muốn merge với Trunk.
  1. Lock nhánh release 2.3 mới nhất trên Release branch để không ai commit tại thời điểm này.
  2. Check out code từ trunk về local.
  3. Merge code từ nhánh release 2.3  newest trên release branches về trunk tại local, nếu có conflict edit ngay tại đó.
  4. Merge code từ trunk về nhánh dev Team B của minh trên local, và edit ngay conflict , commit code lên nhánh dev Team B
  5. Merge code từ dev branches Team B tmới commit rên server  về trunk trên local, edit conflict nếu có.
  6. Copy up từ Trunk local lên trunk server
  7. Add branches  release 2.4 trên nhánh release branches bằng cách check code trên trunk mới lên.
 
Trunk: tương ứng với mainline trong Mainline model. Có thể release phiên bản caravat mới bất kỳ lúc nào.
branches/dev : Development  Branches: nhánh phát triển chức năng mới, tách biệt
branches/release : Release Branches: Dùng để release, hay fixbug.
Tạo một brand mới như thế nào
  1. Chọn Tag/branch => Add Branch , hay dùng phím tắt Ctrl + B
  2. Trong màn hình Add Branch
    • Name: Tên của branch sắp tạo ra, phải tuân theo quy tắc
      • Nếu nằm trên nhánh Dev phải: dev/New Name Branch.
      • Nếu nằm trên nhánh Releases phải: releases/new name branch.
      • Có thể thấy các nhánh hiện có trong Repository bằng cánh nhấn vào button “…” => ra màn hình Tag Browser.
  3. Source: Tạo branch mới với source lấy từ đâu
    • Working Copy: Lấy code từ một thư mục nằm dưới local.
    • Repository Revision: Lấy code từ một nhánh khác( thông thường từ Trunk ) chép qua nhánh đang tạo.
  4. Check out code từ nhánh đang tạo về, và sử dụng để develop.
Quy tắc đặt tên version  m.m.b.b (major.minor.bugfix.builds) trong caravat
  • Major: Tăng khi có sự thay đổi lớn trong hệ thống, như core, hay khi có một tính năng lớn, quan trọng được add thêm vào hệ thống
  • Miner: thay đổi theo tháng, hay thêm các tinh năng mới, hay fix những bug lớn và quan trọng
  • Bugfix: khi fix xong một đợt bug
  • Builds: chỉ số bản build
Example: 1.12.2.1,
Project layout phải là nốt lá
Tất cả các project layout đều phải là nôt lá, không có project nào nằm trong nó và đều chung root là “code”. Điều này giảm tối đa chi phí của bài toán merge, SVN sẽ merge đúng hơn khi hai file nằm chung một root.
Khi có project a1 là child của project a, tạo branches thế nào là đúng?
Khi có một project a1 là con của project a, ta nên tạo branch ngang hàng project a1 với project a trong repository Layout
Example: ta sẽ tạo branches/dev/a1/codecùng cấp với branches/dev/a/code
References: