Книга довольно старая (эпохи, кажется, Windows 2000) и очень плохо переведена (есть глава “Мой исходный текст съел кот Мурзик”).
Набор инструментов типичен для того времени - C++, CORBA, Perl и т.п.
Внимательно читать не стоит, а вот просмотреть - надо. В книге есть мысли, которые просто в голову не приходили.
Полезное:
1. Предлагать варианты решения проблемы, а не отговорки.
2. “Закон разбитых окон” выполняется и для программ. Если есть ошибки и нестабильности - очень скоро их станет намного больше.
3. Качество должно быть одним из требований.
4. Читайте по одной технической книге ежеквартально. И другие книги - не относящиеся к технической литературе.
5. Экспериментируйте с различными операционными системами.
6. Оставайтесь в курсе событий - интернет и т.п.
(Советует журналы и news-группы - в духе времени. Сейчас закрылись и основной журнал по C++, и The Perl Journal. Статьи из последнего можно найти в Интернете по метке TPJ).
и критически осмысляйте всё, что нашли и услышали.
7. “Лучше быть проигнорированным, чем недооценённым”. Беседуйте с гуру и с потребителями.
8. Принцип для выступлений WISDOM:
- Чему вы хотите научить?
- Какова их заинтересованность?
- Насколько искушена аудитория?
- Насколько детальным должно быть выступление?
- Кто должен обладать информацией?
- Как мотивировать слушателей?
9. DRY - Don’t repeat yourself. Важно писать код так, чтобы его было легко использовать повторно. Тогда отпадает большинство эпизодов с дублированием.
10. Ортогональность - следует исключать взаимодействие между объектами, не относящимися друг к другу. Искать баги становится легче, код -- более удобным для повторного использования, и немного возрастает производительность.
11. Из 10 - подобные функции могут быть объеденены в Strategy, а глобальные данные - в Singletone
12. Обратимость. Вытекает из предыдущего. Помним, что не существует окончательных решений. Если чтобы заменить MS SQL на Oracle надо переписывать всё - это не порядок.
13. Чтобы стрелять ночью прицельно, используют трассирующие пули, которые светятся в темноте. Куда попадёт трассирующая - попадёт и обычная. Используйте “трассирующие” предложения, чтобы понять, что от вас хотят.
14. Прототипы (не работает, но показать можно):
- Архитектуры (классы-заглушки)
- Новых функциональных возможностей для системы (интерфейс, который не работает)
- Структуры или содержания внешних данных
- Компонентов
- Рабочих характеристик
- Интерфейса
15. “Границы моего языка есть границы моего мира”.
(Неспроста Хайдеггер искал истину в языке, иногда получая слова в духе Хлебникова)
Программируйте как можно ближе к предметной области вашей задаче. Если команды можно упаковать в классы-“пакеты” - пакуйте! Т. ж. хорошо писать мини-языки, там, где они могут пригодиться.
Если язык парсится, его лучше описать в BNF, которая годится для всех контекстно-свободных грамматик (Perl, например,ей не опишешь)
Т.к. срок службы большинства прикладных программ превышает ожидаемый, лучше, чтобы язык был гибче и удобочитаемей. Ближе к настройкам rc, чем к настройкам sendmail.
16. Проводите оценки по следующим градациям:
1-15 дней - дни
1 - 8 недель - недели
8 - 30 недель - месяцы
> 30 недель - надо хорошенько подумать
Если вы уверены, что проект займёт 125 рабочих дней (= 25 недель) - говорите “примерно 6 месяцев).
Если просят оценить сразу - говорите “надо подумать”. Ведите журнал оценок, чтобы знать свою точность. И по возможности сдвигайте график в ходе проекта - по мере работы он не растягивается, а уточняется.
Набор инструментов типичен для того времени - C++, CORBA, Perl и т.п.
Внимательно читать не стоит, а вот просмотреть - надо. В книге есть мысли, которые просто в голову не приходили.
Полезное:
1. Предлагать варианты решения проблемы, а не отговорки.
2. “Закон разбитых окон” выполняется и для программ. Если есть ошибки и нестабильности - очень скоро их станет намного больше.
3. Качество должно быть одним из требований.
4. Читайте по одной технической книге ежеквартально. И другие книги - не относящиеся к технической литературе.
5. Экспериментируйте с различными операционными системами.
6. Оставайтесь в курсе событий - интернет и т.п.
(Советует журналы и news-группы - в духе времени. Сейчас закрылись и основной журнал по C++, и The Perl Journal. Статьи из последнего можно найти в Интернете по метке TPJ).
и критически осмысляйте всё, что нашли и услышали.
7. “Лучше быть проигнорированным, чем недооценённым”. Беседуйте с гуру и с потребителями.
8. Принцип для выступлений WISDOM:
- Чему вы хотите научить?
- Какова их заинтересованность?
- Насколько искушена аудитория?
- Насколько детальным должно быть выступление?
- Кто должен обладать информацией?
- Как мотивировать слушателей?
9. DRY - Don’t repeat yourself. Важно писать код так, чтобы его было легко использовать повторно. Тогда отпадает большинство эпизодов с дублированием.
10. Ортогональность - следует исключать взаимодействие между объектами, не относящимися друг к другу. Искать баги становится легче, код -- более удобным для повторного использования, и немного возрастает производительность.
11. Из 10 - подобные функции могут быть объеденены в Strategy, а глобальные данные - в Singletone
12. Обратимость. Вытекает из предыдущего. Помним, что не существует окончательных решений. Если чтобы заменить MS SQL на Oracle надо переписывать всё - это не порядок.
13. Чтобы стрелять ночью прицельно, используют трассирующие пули, которые светятся в темноте. Куда попадёт трассирующая - попадёт и обычная. Используйте “трассирующие” предложения, чтобы понять, что от вас хотят.
14. Прототипы (не работает, но показать можно):
- Архитектуры (классы-заглушки)
- Новых функциональных возможностей для системы (интерфейс, который не работает)
- Структуры или содержания внешних данных
- Компонентов
- Рабочих характеристик
- Интерфейса
15. “Границы моего языка есть границы моего мира”.
(Неспроста Хайдеггер искал истину в языке, иногда получая слова в духе Хлебникова)
Программируйте как можно ближе к предметной области вашей задаче. Если команды можно упаковать в классы-“пакеты” - пакуйте! Т. ж. хорошо писать мини-языки, там, где они могут пригодиться.
Если язык парсится, его лучше описать в BNF, которая годится для всех контекстно-свободных грамматик (Perl, например,ей не опишешь)
Т.к. срок службы большинства прикладных программ превышает ожидаемый, лучше, чтобы язык был гибче и удобочитаемей. Ближе к настройкам rc, чем к настройкам sendmail.
16. Проводите оценки по следующим градациям:
1-15 дней - дни
1 - 8 недель - недели
8 - 30 недель - месяцы
> 30 недель - надо хорошенько подумать
Если вы уверены, что проект займёт 125 рабочих дней (= 25 недель) - говорите “примерно 6 месяцев).
Если просят оценить сразу - говорите “надо подумать”. Ведите журнал оценок, чтобы знать свою точность. И по возможности сдвигайте график в ходе проекта - по мере работы он не растягивается, а уточняется.
Комментариев нет:
Отправить комментарий