Как Писать Код, Чтобы Коллеги Не Ругались На Вас

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

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

Представлен?! Начало слишком многообещающее и уже чувствуешь какой-то лохотрон.

Теперь давайте серьезно.

Я пишу код как для себя в своем проекте, так и в компании, где программирую не один.



И я стал замечать, что даже когда я работаю один и возвращаюсь к старому участку кода, у меня возникают мысли: «Зачем я вообще это сюда написал, это неправильноЭ» И вдруг, если я захочу его изменить, может возникнуть ситуация, что теперь что-то работает не так и решение, которое я принял, когда писал тот старый код, было оптимальным.

Итак, важно написать в комментариях «Почему», «Почему я принял такое решение при программированииЭ», «Почему из всех вариантов я выбрал именно ту реализацию, которую выбралЭ» Особенно, если вы работаете в команде.

У меня была ситуация, что кусок кода, который написал другой человек, не полностью реализовал то, что мне нужно и теперь у меня возникает логичный вопрос: «Почему он это сделалЭ», но мы не можем все запомнить и логически получили ответ: «Я не помню почему именно.

Что-то там не срослось».



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

Кто это знает теперь?! А это приводит к тому, что некоторые части кода становятся «неприкосновенными»; ты боишься к ним прикоснуться.

Итак, я считаю, что написание причины выбора варианта дает определенные бонусы.

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

  3. Со временем сама причина, по которой был написан такой код, может «кануть в Лету» и теперь, видя это, понимаешь, что с ним можно со спокойной душой расстаться, но если ты его не напишешь, то он останется здесь.

    , боясь что-то повредить.

  4. Вы можете посмотреть на старый код, написанный до вас, по-новому.

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

  5. От ситуации, когда вы его убираете, спасает то решение-костыль, которое было перед вами, а потом оказывается, что вы открыли ящик Пандоры, потому что только этот костыль удерживал вас от всеобщего разрушения.

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

В заключение хочу сказать.

Код долго остается напечатанным, но мысли и доводы людей, принявших его в конкретный момент в конкретной ситуации, испаряются уже на следующий день.

Теги: #программирование #разработка приложений #Идеальный код #советы и подсказки

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2011-09-02 00:59:22
Баллов опыта: 617
Всего постов на сайте: 5
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.