Программирование в кризис - PullRequest
5 голосов
/ 01 апреля 2009

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

Мне повезло иметь милость Стив Макконнелл и Фредерик Брукс, чтобы сказать мне, что делать, если я хочу испортить свой проект, и я серьезно отношусь к их работе.

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

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

Ответы [ 7 ]

4 голосов
/ 01 апреля 2009

jpgs быстрее, чем HTML-страницы

3 голосов
/ 01 апреля 2009

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

2 голосов
/ 01 апреля 2009

Разместите мои задачи в некотором списке небольших независимых задач (или задач, в которых зависимости уже позаботились в порядке). Затем просто сядьте и уберите одно задание с моей тарелки за другим. Все, что я должен согласовать с кем-то еще, задать вопрос и т. Д., Вылетает вперед; Я просто сижу и пишу код, не отвлекаясь, пока не доберусь до места, где мне нужно какое-то внешнее взаимодействие. Затем я занимаюсь всей своей координацией с другими людьми, перепланировкой и т. Д. В одной партии и снова возвращаюсь к прямому кодированию.

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

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

Во всяком случае, это то, что я делаю, когда я против стены. Не уверен, насколько хорошо это работает для кого-то еще.

2 голосов
/ 01 апреля 2009

Обычно вырезание элементов и рабочих элементов - лучший способ уложиться в сжатые сроки.

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

1 голос
/ 01 апреля 2009

Самая большая помощь (для меня) - заставлять себя выполнять каждую задачу, прежде чем перейти к другой. Если мне нужно исправить некоторые ошибки в libfoo или даже написать libfoo, чтобы перейти к следующему шагу, я заставляю себя продолжать выполнять эту задачу, затем следующую, затем следующую.

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

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

1 голос
/ 01 апреля 2009

На самом деле, я думаю, что у многих программистов и организаций есть много незаметных плодов. Удостоверьтесь, что вы продуктивно используете свое время, знаете, как правильно соотносить скорость и качество, не делайте «золотую тарелку» за пределами того, что просит ваш клиент, и т. Д.

Профилируйте процессы вашей организации. Какое узкое место замедляет тебя? Переключение контекста (т. Е. Многозадачность) часто приводит к снижению производительности.

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

0 голосов
/ 01 апреля 2009

Я бы предложил изучить GTD или что-то в этом роде до того, как вы попадете в кризис, используя, чтобы избежать кризиса, если это вообще возможно, а затем, если вам необходимо, пройти через хруст, просто делая это. Попасть в зону и продолжать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...