Как стать более продуктивным в программировании? - Часть I
Это серия статей о том, как быть продуктивным на работе. Это основано на моем личном опыте. Он может подойти вам, а может и нет. Все зависит от того, что вы собой представляете и в какой ситуации находитесь. Вы должны осознавать как себя, так и свою ситуацию, свои навыки/знания и то, как вы можете их использовать в данной ситуации. И это самое главное, чтобы быть продуктивным — быть осознанным или внимательным.
Следующим важным фактором повышения производительности является сокращение переделок. Количество переделок в наши дни велико. Это можно объяснить темпом и сложностью работы. Рынок становится более конкурентоспособным, а конечный пользователь становится более требовательным. Так что это спешка, чтобы первым выйти на рынок с большим количеством вещей.
Основной причиной доработки является недостаточная коммуникация между заинтересованными сторонами и менеджерами, между менеджерами и разработчиками и между разработчиками и реализацией. С точки зрения разработчика мы можем этого избежать, спросив у 3W что, почему и как.
«Что» означает понимание того, что делать. Какая проблема решается? Какое решение должно быть реализовано? Вы можете получить его из разных источников — от заинтересованных сторон или конечных пользователей, документов или электронных писем. Каким бы ни был источник, дайте время переварить и понять. Затем закрепите и задокументируйте его, и самое главное, подтвердите свое понимание. И не забудьте зафиксировать нефункциональные требования, такие как контроль доступа, производительность и уведомления в реальном времени. Иногда только в конце разработки мы берем нефункциональные требования и заканчиваем переработкой всех уровней.
Далее почему. Это не всегда требуется, но иногда вам нужно понять, почему ~ какова причина или цель того, что вы реализуете. Это может быть фактором мотивации для команды и дать вам импульс. Ничего не могу сказать по этому поводу, за неимением опыта.
И затем вам нужно решить, как это сделать ~ «Нужно ли мне следовать каким-либо правилам кодирования, таким как pep8 или ESLint?», «Есть ли какая-либо философия, например, бизнес-логика должна лежать на этом уровне или в представлении? слой должен быть тонким?» и т. д. А когда вы сомневаетесь, не стесняйтесь спрашивать. Предположения опасны. Не кодируйте на предположениях.
И продолжая о том, что как разработчик я всегда склонен оставлять некоторые технические долги, говоря: «Эй, код, я знаю, что ты пахнешь, но я сейчас тороплюсь, я свяжусь с тобой позже». И чаще всего я не возвращался. Но он был достаточно любезен, чтобы ответить мне на вопрос об ошибке, проблеме с производительностью или ремонтопригодности. Ваш разум будет искать оправдания, чтобы убедить вас и ввергнуть вас в технический долг. Остерегайтесь и осознавайте этот акт ума. Ум хитер и может соблазнить вас на технический долг. Так что имейте волю и терпение, чтобы не влезать в технический долг.
Чтобы завершить эту сессию, будут моменты, когда что-то не работает. В это время не нагружайте себя работой и мыслями. Это не просто непродуктивно, это будет иметь неприятные последствия. Поэтому, когда что-то не работает, сделайте перерыв, освежитесь и снова станьте сильнее. Вы должны иметь осознание того, что вы испытываете стресс, когда вы испытываете стресс и действуете. И «те, кто не осознают, что ходят во тьме, никогда не будут искать света», — Брюс Ли
