> 1. Как можно меньше отвлекайтесь.
Тут речь идет о решении одной задачи до конца, без переключения внимания на другие задачи. В процессе решения можно отвлечься, на еду, например =) Часто бывает так, что из-за пункта 7 (один редактор кода) программеру помимо движения вперед приходится поддерживать уже существующий код. Тупые [проджект]менеджеры часто садятся на шею и не дают программисту решать текущую конкретную задачу постоянно меняя приоритеты. Так делать нельзя.
> 4. Переписывание прог
При хорошем стиле рефакторинг --- это неотъемлимая часть жизни проги. Система тестов держит функционал в рамках и не позволяет вещей вроде "упс, сломалась". Рефакторинг не всегда направлен на изменение архитектуры приложения, скорее, это "горизонтальное" развитие: батлнеки, новые подходы, оптимизация, багфиксы, читаемость кода и т.п. Так что рефакторинг - это и метко и часто.
> 5. Читаемость кода
Опять же про хороший стиль - в проекте должно быть соглашение о форматировании кода, его надо принимать и пользоваться. Тут проблемы перевода. В оригинале: Write rereadable code. Это означает: пишите код, который можно прочитать [любому].
> 6. Небольшие группы
Это не о "позволить себе", а об "организовать работу". Об этом писал еще Брукс в "Мифическом человеко-месяце". Небольшие команды эффективнее больших команд, пример тому - youtube. Это связано лишь со сложностью организации работы внутри больших коллективов.
> 7. Несколько редакторов кода
Согласитесь, глупо давать двум программерам одно и то же задание. В оригинале: Don't have multiple people editing the same piece of code. Не допускайте работу нескольких человек над одним кусом кода. Вне зависимости от сложности задачи исполнитель должен быть один (или два для eXtreme Programming). Если у него возникнут сложности он всегда сможет проконсультироваться с любым количеством коллег. Но исполнитель - один!
Сначала использовал AceMoney, потом надоело тратить время на переписывание сумм и дат с чеков и попытки вспомнить, за что я заплатил согласно "ООО ЧУЧМЕКБАЙСВЯЗЬПРОМЛАРЕК, чек фискальный, 179 р 57 к".
Достал свой пыльный Palm Tungsten E и, попробовав в общей сложности 14 прог, остановился на SplashMoney. Пользуюсь уже больше года и доволен. Есть недостатки, но это лучшее для меня. Единственное исключение - траты, связанные с автомобилем я учитываю с помощью AutoMobile (http://www.linkesoft.com)
Следующая заметка будет "Из-за необъянимых причин работа судебной системы США была нарушена. Потребовалось 540 человекочасов для устранения программных неисправностей. Ущерб оценивается в 25 тысяч долларов" =)
Сложно сказать, с какого краю людей станет меньше. Любой край это современная Украина. Множество украинских народностей не просто так появилось, откуда-то они пришли и когда-то там обосновались. Поражает истеричное стремление отбросить огромный кусок истории страны, переписать его начисто и сдаться кому угодно, но так, чтобы огромному соседу поплохело. Это искусственно, навязано и неестественно.
Вспомните Российские 90-е и дефолты. Это было настоящее дерьмо. Инфляция, космическое воровство, бандитизм, "утечка мозгов" и т.п. Я называю это дерьмом и подразумеваю под этим низкий (высокий, но нестабильный, если хотите) заработок, произвол властей, выражавшийся в беспомощности судов, аппетитах чиновников и развивающегося "института князьков" в лице доблестных сотрудников милиции. Сейчас лучше и гораздо! Вектор налицо. А на Украине сейчас не наблюдается национального единства, иначе происходящее не было бы возможным в принципе! Да, я мог бы назвать это дерьмом. Не народ Украины, не их конкретных лидеров (не знаком лично), а ситуацию, процессы, которые сейчас там происходят. Стиллавин называет это дерьмом с переходом на личности. Это можно назвать кризисом, революцией, переделом территории, волнениями и другими социально-приемлимыми кусочно-гладкими терминами. Смысл-то не меняется. Стиллавин не политик и не посол, не обязан он не называть вещи своими именами.
По моему опыту, ТЗ проходит некоторые эволюционные этапы:
- Этап переговоров и принятие решения заказчиком. Условия и критерии, принятые или озвученные заказчиком ни в коем случае не должны быть потеряны или искажены. Это по сути основа ТЗ. В терминах статьи это "Цели и задачи сайта", "Описание пользователей сайта, их цели и задачи", частично остальные пункты.
- Драфт. Первоначальный вариант ТЗ, который интенсивно обсуждается и исправляется.
- Рабочий вариант. Фактически старт боевых действий.
На первых двух этапах ТЗ у меня хранится преимущественно в текстовом виде и под управлением системы контроля за версиями. На третьем компилируется и становится красивым =)
А я жду не дождусь появления большого количества небольших фирм, прелагающих услуги пресональных финансовых консультантов. Это что-то вроде семейного врача - он всегда есть, ему можно доверять, он всегда на твоей стороне. Иначе рассказы о кредитах и ипотеках долго еще будут напоминать страшилки "темной-темной ночью, черный-черный банкир...".
Надеюсь, что когда-нибудь человек, отвечающий за то, чему обучают на "информатике" поймет, что для нормального пользования компьютером не обязательно быть программистом. Это атавизм со стажем.
Тут речь идет о решении одной задачи до конца, без переключения внимания на другие задачи. В процессе решения можно отвлечься, на еду, например =) Часто бывает так, что из-за пункта 7 (один редактор кода) программеру помимо движения вперед приходится поддерживать уже существующий код. Тупые [проджект]менеджеры часто садятся на шею и не дают программисту решать текущую конкретную задачу постоянно меняя приоритеты. Так делать нельзя.
> 4. Переписывание прог
При хорошем стиле рефакторинг --- это неотъемлимая часть жизни проги. Система тестов держит функционал в рамках и не позволяет вещей вроде "упс, сломалась". Рефакторинг не всегда направлен на изменение архитектуры приложения, скорее, это "горизонтальное" развитие: батлнеки, новые подходы, оптимизация, багфиксы, читаемость кода и т.п. Так что рефакторинг - это и метко и часто.
> 5. Читаемость кода
Опять же про хороший стиль - в проекте должно быть соглашение о форматировании кода, его надо принимать и пользоваться. Тут проблемы перевода. В оригинале: Write rereadable code. Это означает: пишите код, который можно прочитать [любому].
> 6. Небольшие группы
Это не о "позволить себе", а об "организовать работу". Об этом писал еще Брукс в "Мифическом человеко-месяце". Небольшие команды эффективнее больших команд, пример тому - youtube. Это связано лишь со сложностью организации работы внутри больших коллективов.
> 7. Несколько редакторов кода
Согласитесь, глупо давать двум программерам одно и то же задание. В оригинале: Don't have multiple people editing the same piece of code. Не допускайте работу нескольких человек над одним кусом кода. Вне зависимости от сложности задачи исполнитель должен быть один (или два для eXtreme Programming). Если у него возникнут сложности он всегда сможет проконсультироваться с любым количеством коллег. Но исполнитель - один!
Рекомендую в оригинале почитать.
Достал свой пыльный Palm Tungsten E и, попробовав в общей сложности 14 прог, остановился на SplashMoney. Пользуюсь уже больше года и доволен. Есть недостатки, но это лучшее для меня. Единственное исключение - траты, связанные с автомобилем я учитываю с помощью AutoMobile (http://www.linkesoft.com)
- Этап переговоров и принятие решения заказчиком. Условия и критерии, принятые или озвученные заказчиком ни в коем случае не должны быть потеряны или искажены. Это по сути основа ТЗ. В терминах статьи это "Цели и задачи сайта", "Описание пользователей сайта, их цели и задачи", частично остальные пункты.
- Драфт. Первоначальный вариант ТЗ, который интенсивно обсуждается и исправляется.
- Рабочий вариант. Фактически старт боевых действий.
На первых двух этапах ТЗ у меня хранится преимущественно в текстовом виде и под управлением системы контроля за версиями. На третьем компилируется и становится красивым =)