понедельник, 7 мая 2012 г.

Book: Программист-прагматик - 1. гл. 1-2

Книга довольно старая (эпохи, кажется, 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 месяцев).

Если просят оценить сразу - говорите “надо подумать”. Ведите журнал оценок, чтобы знать свою точность. И по возможности сдвигайте график в ходе проекта - по мере работы он не растягивается, а уточняется.

Комментариев нет:

Отправить комментарий