1. Ясно подумайте, прежде чем писать код

Новички в отрасли, чтобы показать свои способности, не могут дождаться, чтобы начать писать код, как только получат требования. Это большое табу! На мой взгляд, реальное время, затрачиваемое на написание кода, составляет всего 20%. Если вы не продумаете всё ясно, остальные 80% времени уйдут на исправление багов.

2. Если не общаться, в итоге получишь разбитую голову и окровавленное лицо

Неразговорчивость и неумение общаться легко приводят к непониманию требований. В итоге вы заканчиваете разработку и обнаруживаете, что это не то, что требовал продукт. Многие функции откладываются и переделываются из-за недостатка общения.

3. Никто не читает документацию, но вы всё равно должны её писать

Роль документации обычно заключается не в общении, а в ведении записей. Большинство требований по-прежнему передаются устно, но если вы не ведёте документацию как запись, позже легко возникнут споры.

4. Обязательно пишите комментарии

Не писать комментарии — значит рыть яму себе и другим, потому что через долгое время вы даже не поймёте свой собственный код.

5. Не ожидайте, что требования будут стабильными

Требования к продукту постоянно корректируются в соответствии с бизнес-потребностями. Изменение требований — совершенно нормально. Не жалуйтесь; единственное, что постоянно в этом мире, — это изменения.

6. Бизнес важнее технологий

Если технология не служит бизнесу компании, она ничего не стоит. Зарабатывать деньги — абсолютный принцип для компании. Поэтому я не рекомендую всем гнаться за новыми технологиями; вместо этого уделяйте больше внимания применению зрелых технологий в коммерческих компаниях.

7. Не полагайтесь на удачу

Место, где вы смутно чувствуете, что возникнет баг, — это именно то место, где баг обязательно возникнет.

8. Сначала протестируйте сами несколько раз

Не просто бросайте код тестировщикам сразу после написания. Всё, что проходит через ваши руки, должно быть гарантированно качественным.

9. По возможности решайте проблемы самостоятельно

Когда вы сталкиваетесь с проблемой, которую не понимаете, сначала постарайтесь решить её самостоятельно (90% проблем можно решить с помощью Google, Stack Overflow и т. п.). Не стоит при каждом удобном случае просто делать скриншот и бросать его кому-то с просьбой о помощи. Ваш начальник и коллеги не для того, чтобы убирать за вами. Но если вы действительно всё испортили, как можно скорее попросите о помощи.

10. Используйте новые технологии с осторожностью

Не гонитесь за новыми технологиями. Все новые технологии — это бета-версии. Если вы берёте на себя смелость использовать их до того, как гуру даже написали понятную вводную документацию на китайском, вы, скорее всего, нарываетесь на неприятности.

Исходный URL: http://www.techug.com/post/funny-programmer-pictures-2.html