Я пережил 4 года в индустрии программного обеспечения. Индустрия программного обеспечения научила меня тому, что недостаточно просто уметь решать проблемы или бросать вызов.

Только программисты, сосредоточенные, профессиональные и передовые методы, могут выжить в этой отрасли. Я делюсь некоторыми советами и практиками, которые я использую для отслеживания прогресса, совместной работы, обратимости, документирования в любом проекте.

1. Возвращаясь к основам, необходимо поддерживать свои ветки git.

2. Всегда нужно обновлять все свои рабочие обновления в доске проектов/тележках Agile Sprint.

3. Сделайте скриншоты до и после предыдущих состояний. И по возможности используйте аннотацию. Эта практика делает вашу работу узнаваемой для вашего руководства.

4. Всегда создавайте отдельную ветку git для отдельных задач. Сообщите своим одноранговым партнерам о новой ветке и будьте в курсе изменений в ветке. Чтобы не случилось никакого конфликта.

5. Ваши спринт-корзины должны быть информативными. Всегда добавляйте название ветки, сообщение о коммите/или идентификатор коммита, если появляются повторяющиеся сообщения о коммите.

Ошибки. Если вы устраняете ошибку, вы можете оставить короткий комментарий, где возникла проблема.

Обновления: если вы добавляете новую функцию, оставьте высокоуровневое описание (для понимания на уровне руководства/пользователя) и техническое определение (для равноправных партнеров) проблемы, с которой вы столкнулись. хочу решить.

NB: если вы хотите, чтобы взаимодействие в команде было плавным, определите проблему с слагом и укажите файл и строку, где была ошибка.

7. Если вы новичок в команде, не объединяйте ненужные или повторяющиеся коды; без понимания видения руководителя проекта, целевых пользователей проекта и целей проекта. Вы никогда не знаете, сохранен ли модуль для будущей разработки. Спросите своего руководителя проекта как можно больше. Сделайте свою концепцию ясной перед разработкой. Проверьте, не оставили ли какие-либо документы ваши коллеги или предыдущие разработчики.

8. Не объединяйте код, не потратив достаточно времени на кодовую базу. Это может быть месяц, вы должны хорошо разбираться во всех механизмах, прежде чем слить модуль.

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

10. Поддерживайте чистоту кода, используйте отступы и содержательные определения переменных и объектов. И поддерживайте отдельные модули и файлы для отдельных функций. Один модуль или функция должны служить одной цели. Не делайте название вашего объекта или сущности запутанным. Это экономит много времени для других.

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

12. Помните, если ваш код понятен без комментариев новичков, то ваш код профессиональный.

13. Не будь жадным или скупым. Чем больше вы сотрудничаете с другими партнерами, программистами и менеджерами; И чем комфортнее вы будете в общении с окружающими, тем больше вас будут ценить. Это хорошо для вашего профессионализма. Человек, который идет очень далеко, является честным командным игроком.

14. Возвратность очень важна. Если ваш лидер говорит вам или если вы понимаете, вы сделали ошибку. Итак, вы должны отменить все вещи. Так что работа над отдельной веткой может спасти вам жизнь. Все предыдущие советы написаны для обратимости. Хорошо следуйте им.

15. Тайм-менеджмент обязателен. Итак, если у вас есть несколько проблем, которые нужно решить одновременно, установите приоритет и отсортируйте эти задачи в зависимости от приоритета. Вы можете использовать флажки приоритета в большинстве программ для управления проектами.

16. Всегда старайтесь писать код с большей сосредоточенностью и концентрацией; не очень быстро, но стабильно и осознанно. Это сэкономит много времени, потому что вы будете делать меньше глупых ошибок.

17. Рефакторинг кода является обязательным, поскольку он экономит много ресурсов и времени разработки для компании при будущих обновлениях. Так что, как честный сотрудник, это ваш религиозный долг — делать рефакторинг кода чаще, чем вы можете.

18.Документация. Я считаю, что документация — это высшее качество профессионального программиста. Я люблю документировать свою работу. Я все документирую — как решил проблему, где была проблема, где нашел решение. И я пытаюсь сопоставить все низкоуровневые модули, объекты и пользовательские функции отдельно. Это помогает мне сосредоточиться на цели проекта. Даже никто не разрешает, я все равно маппирую весь проект. Это помогает мне ориентироваться в проекте. И это может сэкономить время моим коллегам и членам команды, когда они застряли в ситуации. Так что документация сама по себе является искусством. Это поможет вам писать код организованно и хорошо спланировано. Так что редко запутаешься при разработке проекта. Ничего не должно запоминаться в голове, потому что большинство кодеров занимаются несколькими проектами. Поэтому документирование фактов, целей, технических деталей является обязательным.

Это все, что я могу вспомнить на данный момент о своем опыте кодирования в индустрии программного обеспечения. Я буду обновлять пост, добавляя даты и советы, так что подпишитесь или перейдите по ссылке.

Особая благодарность и упоминание моим партнерам по грушам Наиму и Абдулле Ваям…