1. Прототип
Самым позитивным был ответ Джеффа Нельсона, создателя хромбука. Инженер обращает внимание на создание небольших прототипов при изучении какой-либо концепции: в такой ситуации он пишет несколько дюжин маленьких программ, каждая из которых выражает какую-то простую идею. По его словам, такая модель поведения в разы упрощает процесс тестирования нескольких концепция за короткий промежуток времени.
2. Кирпичики
Другую интересную идею предложил веб-разработчик Демиан Рохе. Он говорит о своем наборе заметок, окрещенном «кирпичными стенами». В них содержатся все наиболее сложные задачи, требующие для их решения часов кропотливой работы, а также сами решения. Если он не обращается к этим заметкам на протяжении продолжительного времени, это говорит о том, что он бросает себе недостаточно вызовов, и сигнализирует о необходимости искать новые задачи и цели.
3. Время
Еще один разработчик, чей ответ получил большое количество голосов, — Эд Прентис. Он представил целый список привычек, которым он следует. Первоочередной задачей он считает сэкономить как можно больше времени: «автоматизируйте все, что только можно», — пишет он. Для этого используйте мощную среду разработки, имеющую возможность гибкой настройки под себя, создавайте макросы для выполнения повторяющихся действий, выучите горячие сочетания клавиш и подружитесь с командной строкой (например, в UNIX).
4. Испытания и обучение
Тот же самый Прентис не ограничивается автоматизацией всего на свете. В его обширном списке есть еще один мудрый совет. Необходимо бросать себе вызовы. Никогда не писали веб-приложений? Попробуйте это, например, на Ruby on Rails. Не менее важно постоянно учиться, даже если предмет изучения не относится к программированию. Также бывает полезно время от времени заглядывать на Stack Overflow в поисках топиков, с которыми вы более или менее знакомы. Это позволит укрепить ваши знания. Наконец, небезосновательно считается хорошей привычкой делиться знаниями, а также уроками и полезными ресурсами.
5. Тренировка
Рафаэль Буч (Raphael Buch) представляет вниманию досточтимой публики два упражнения, считающихся традиционными в среде разработчиков: Кайзен (Kaizen) и Ката (Kata). Первый состоит в переписывании и переосмыслении кода, шлифовке его, как драгоценного камня. Каждый раз, когда вам нужно внести изменения в код, переработайте его дизайн, пишет он. Второй принцип основывается на написании одних и тех же строк кода снова и снова, делая аккуратные изменения каждый раз. Всякая подобная тренировка будет приносить небольшие улучшения, а впоследствии будет проще обнаруживать ошибки на ранних стадиях разработки, не позволяя им разрастаться в значительные проблемы.
6. Разделяй и властвуй
Автор и программист Дебасиш Гош (Debasish Ghosh) старается придерживаться привычки читать как можно больше чужого кода — как хорошего, так и не очень. Второе, утверждает он, особенно важно, поскольку позволяет отметить для себя множество принципов, следовать которым не стоит. Еще он рекомендует следовать принципу «разделяй и властвуй»: решая объемные задачи, разбивайте их на подзадачи и начинайте с самого простого, постепенно переходя к все более сложному. Еще один полезный совет заключается в том, чтобы присоединиться к уже существующему и развивающемуся проекту, желательно опенсорсному.
7. Сначала проектирование
Анкит Гупта (Ankit Gupta), разработчик из Амазон, считает важным, чтобы началу разработки предшествовало проектирование. Бесспорно, некоторые задачи решаемы исключительно на втором этапе, но дизайн, как нечто абстрактное, всегда переживает конкретное решение, для которого он создавался. Как сам автор признается, он не всегда следует данному принципу. Также, он является еще одним адептом автоматизирования.
8. В поисках багов
Создатель программ Tune Smithy и Bounce Metronome Роберт Уокер является одним из тех, кто считает необходимым записывать каждый баг, даже самый маленький и незначительный. Это путь, позволяющий запоминать свои ошибки и не повторять их в последующей практике. Еще одна его практика — сохранять все модификации в отдельных .ini-файлах, чтобы при необходимости воспроизвести решение попадавшейся ранее задачи. И, конечно, он всегда делает бэкапы, чтобы не потерять ничего из своей работы.
Самым позитивным был ответ Джеффа Нельсона, создателя хромбука. Инженер обращает внимание на создание небольших прототипов при изучении какой-либо концепции: в такой ситуации он пишет несколько дюжин маленьких программ, каждая из которых выражает какую-то простую идею. По его словам, такая модель поведения в разы упрощает процесс тестирования нескольких концепция за короткий промежуток времени.
2. Кирпичики
Другую интересную идею предложил веб-разработчик Демиан Рохе. Он говорит о своем наборе заметок, окрещенном «кирпичными стенами». В них содержатся все наиболее сложные задачи, требующие для их решения часов кропотливой работы, а также сами решения. Если он не обращается к этим заметкам на протяжении продолжительного времени, это говорит о том, что он бросает себе недостаточно вызовов, и сигнализирует о необходимости искать новые задачи и цели.
3. Время
Еще один разработчик, чей ответ получил большое количество голосов, — Эд Прентис. Он представил целый список привычек, которым он следует. Первоочередной задачей он считает сэкономить как можно больше времени: «автоматизируйте все, что только можно», — пишет он. Для этого используйте мощную среду разработки, имеющую возможность гибкой настройки под себя, создавайте макросы для выполнения повторяющихся действий, выучите горячие сочетания клавиш и подружитесь с командной строкой (например, в UNIX).
4. Испытания и обучение
Тот же самый Прентис не ограничивается автоматизацией всего на свете. В его обширном списке есть еще один мудрый совет. Необходимо бросать себе вызовы. Никогда не писали веб-приложений? Попробуйте это, например, на Ruby on Rails. Не менее важно постоянно учиться, даже если предмет изучения не относится к программированию. Также бывает полезно время от времени заглядывать на Stack Overflow в поисках топиков, с которыми вы более или менее знакомы. Это позволит укрепить ваши знания. Наконец, небезосновательно считается хорошей привычкой делиться знаниями, а также уроками и полезными ресурсами.
5. Тренировка
Рафаэль Буч (Raphael Buch) представляет вниманию досточтимой публики два упражнения, считающихся традиционными в среде разработчиков: Кайзен (Kaizen) и Ката (Kata). Первый состоит в переписывании и переосмыслении кода, шлифовке его, как драгоценного камня. Каждый раз, когда вам нужно внести изменения в код, переработайте его дизайн, пишет он. Второй принцип основывается на написании одних и тех же строк кода снова и снова, делая аккуратные изменения каждый раз. Всякая подобная тренировка будет приносить небольшие улучшения, а впоследствии будет проще обнаруживать ошибки на ранних стадиях разработки, не позволяя им разрастаться в значительные проблемы.
6. Разделяй и властвуй
Автор и программист Дебасиш Гош (Debasish Ghosh) старается придерживаться привычки читать как можно больше чужого кода — как хорошего, так и не очень. Второе, утверждает он, особенно важно, поскольку позволяет отметить для себя множество принципов, следовать которым не стоит. Еще он рекомендует следовать принципу «разделяй и властвуй»: решая объемные задачи, разбивайте их на подзадачи и начинайте с самого простого, постепенно переходя к все более сложному. Еще один полезный совет заключается в том, чтобы присоединиться к уже существующему и развивающемуся проекту, желательно опенсорсному.
7. Сначала проектирование
Анкит Гупта (Ankit Gupta), разработчик из Амазон, считает важным, чтобы началу разработки предшествовало проектирование. Бесспорно, некоторые задачи решаемы исключительно на втором этапе, но дизайн, как нечто абстрактное, всегда переживает конкретное решение, для которого он создавался. Как сам автор признается, он не всегда следует данному принципу. Также, он является еще одним адептом автоматизирования.
8. В поисках багов
Создатель программ Tune Smithy и Bounce Metronome Роберт Уокер является одним из тех, кто считает необходимым записывать каждый баг, даже самый маленький и незначительный. Это путь, позволяющий запоминать свои ошибки и не повторять их в последующей практике. Еще одна его практика — сохранять все модификации в отдельных .ini-файлах, чтобы при необходимости воспроизвести решение попадавшейся ранее задачи. И, конечно, он всегда делает бэкапы, чтобы не потерять ничего из своей работы.