-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Как обычно пишутся программы
- Автор темы Groove
- Дата начала
an_kalinovski
Новичок
Еще какой баян. Видел тыщеу лет назад и на русском и (оригинал) на аглицком
Burunduk-13
[CBT], Старожил РНРClub'a
оригинал в студию
Это было про ТЗ
кстати - показываю тем заказчикам которые не хотят
давать ТЗ :-Ь
-~{}~ 09.08.06 13:42:
10 способов провалить потенциально успешный проект
Десять шагов к саботажу проекта, над которым вы работаете:
1. Начните проектирование с нуля. Ни в коем случае не используйте в качестве основы проекта готовый и работающий код. “Все удачные большие системы являются результатом перепроектирования некоторых меньших работающих систем. Я не знаю исключений из этого правила. Можно привести множество примеров проектов, закончившихся неудачей, над которыми мучились годами, тратили большие средства, и наконец успешно заканчивали, но спустя годы после намеченного срока.” (Б. Страуструп)
2. Никогда не размышляйте в процессе дизайна приложения. Найдите какой-нибудь список правил для проектировщика и безоговорочно ему следуйте. Любые решения, принятые самостоятельно, - это риск создать успешный проект.
3. Никогда не тестируйте свой код или откладывайте это до последнего. Программы, которые не тестировали, не работают. Чем позже вы начнете тестировать свой проект, тем больше вероятность, что он так никогда и не заработает должным образом.
4. Откладывайте релиз настолько, насколько это вообще возможно. Ведь вы разработчик и только вы знаете, что должен представлять собой ваш проект. Мнение пользователей, особенно на ранних стадиях, только вредит разработке вашего проекта.
5. Добавляйте в код все “фичи”, которые только можете вообразить. Создавайте ветвистые диалоги настройки, где для изменения любой опции нужно проделать не менее десяти шагов. Пользователи будут искренне рады каждой крутой возможности, которую они так никогда и не найдут.
6. Используйте готовые библиотеки только в самом крайнем случае. Всегда лучше написать все самостоятельно. Если перед вами стоит выбор между использованием готовой работающей библиотеки, которую нужно лишь слегка подправить, и написанием собственной, не задумываясь выбирайте последнее. Как известно, все библиотеки пишут люди, на самом деле ничего не смыслящие в программировании.
7. С первых же строчек занимайтесь оптимизацией. Если вы где-то прочитали, что двойные кавычки медленнее одинарных, используйте везде только одинарные кавычки. Не стоит задумываться об оптимизации на уровне дизайна приложения. Это не потребуется, если вы будете заниматься микро-оптимизацией. Запомните: “несвоевременная оптимизация - корень всех зол” (Д. Кнут). Только с помощью такого рода оптимизаций вы сможете создать проект, который потом можно будет запустить только на суперкомпьютерах.
8. Никогда не документируйте свой код. Если же вас прижмет начальство, то пишите что-то вроде “This function do various stuff. See source code for more information.” Код, соответсвенно, запутывайте как это только возможно. Не дай бог кто-то, кроме вас, сможет в нем разобраться!
9. Выберите одного самого ценного заказчика и добавляйте только те возможности, которые он потребует. На пожелания остальных клиентов не обращайте ни малейшего внимания.
10. Не придусматривайте расширение возможностей вашей программы. Ведь вы создали самостоятельный продукт, прекрасный в своей завершенности. После окончательного релиза, устроившего вашего самого ценного заказчика (см. выше) можно смело стирать исходный код: добавить к вашему творению больше нечего
кстати - показываю тем заказчикам которые не хотят
давать ТЗ :-Ь
-~{}~ 09.08.06 13:42:
10 способов провалить потенциально успешный проект
Десять шагов к саботажу проекта, над которым вы работаете:
1. Начните проектирование с нуля. Ни в коем случае не используйте в качестве основы проекта готовый и работающий код. “Все удачные большие системы являются результатом перепроектирования некоторых меньших работающих систем. Я не знаю исключений из этого правила. Можно привести множество примеров проектов, закончившихся неудачей, над которыми мучились годами, тратили большие средства, и наконец успешно заканчивали, но спустя годы после намеченного срока.” (Б. Страуструп)
2. Никогда не размышляйте в процессе дизайна приложения. Найдите какой-нибудь список правил для проектировщика и безоговорочно ему следуйте. Любые решения, принятые самостоятельно, - это риск создать успешный проект.
3. Никогда не тестируйте свой код или откладывайте это до последнего. Программы, которые не тестировали, не работают. Чем позже вы начнете тестировать свой проект, тем больше вероятность, что он так никогда и не заработает должным образом.
4. Откладывайте релиз настолько, насколько это вообще возможно. Ведь вы разработчик и только вы знаете, что должен представлять собой ваш проект. Мнение пользователей, особенно на ранних стадиях, только вредит разработке вашего проекта.
5. Добавляйте в код все “фичи”, которые только можете вообразить. Создавайте ветвистые диалоги настройки, где для изменения любой опции нужно проделать не менее десяти шагов. Пользователи будут искренне рады каждой крутой возможности, которую они так никогда и не найдут.
6. Используйте готовые библиотеки только в самом крайнем случае. Всегда лучше написать все самостоятельно. Если перед вами стоит выбор между использованием готовой работающей библиотеки, которую нужно лишь слегка подправить, и написанием собственной, не задумываясь выбирайте последнее. Как известно, все библиотеки пишут люди, на самом деле ничего не смыслящие в программировании.
7. С первых же строчек занимайтесь оптимизацией. Если вы где-то прочитали, что двойные кавычки медленнее одинарных, используйте везде только одинарные кавычки. Не стоит задумываться об оптимизации на уровне дизайна приложения. Это не потребуется, если вы будете заниматься микро-оптимизацией. Запомните: “несвоевременная оптимизация - корень всех зол” (Д. Кнут). Только с помощью такого рода оптимизаций вы сможете создать проект, который потом можно будет запустить только на суперкомпьютерах.
8. Никогда не документируйте свой код. Если же вас прижмет начальство, то пишите что-то вроде “This function do various stuff. See source code for more information.” Код, соответсвенно, запутывайте как это только возможно. Не дай бог кто-то, кроме вас, сможет в нем разобраться!
9. Выберите одного самого ценного заказчика и добавляйте только те возможности, которые он потребует. На пожелания остальных клиентов не обращайте ни малейшего внимания.
10. Не придусматривайте расширение возможностей вашей программы. Ведь вы создали самостоятельный продукт, прекрасный в своей завершенности. После окончательного релиза, устроившего вашего самого ценного заказчика (см. выше) можно смело стирать исходный код: добавить к вашему творению больше нечего
