Питер Сейбел - Кодеры за работой. Размышления о ремесле программиста

Сейбел:Скажите, а пользователи требовали обобщенных типов? Кто-нибудь жаловался, что их отсутствие мешает писать программы?

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

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

Есть чудесное выступление Гослинга “The Feel of Java” (Почувствовать Java); в нем он говорит, что нужно трижды ощутить необходимость чего-то, прежде чем внедрять это. Нельзя добавлять программу только из-за ее красоты.

Но люди все равно добавляют. Что делают разработчики? Пишут код. И, работая над библиотекой или языком, они хотят добавить туда что-то свое. Некий внутренний голос должен подсказывать, какое сочетание свойств будет работать хорошо, что нужно добавлять, а чего не нужно. Ведь чаще всего вы можете добавить к языку больше, чем должны. Это означает не то, что ваши программы плохи, а лишь то, что надо правильно выбирать, не валя все в кучу.

Сейбел:Я читал книги “Java Puzzlers” и “Java Concurrency in Practice”. Меня удивило, что в языке, который изначально был очень простым, столько секретов.

Блох:Секреты есть, но это неизбежно, они есть во всех языках. Можно было бы написать книгу “Си: головоломки”.

Сейбел:Ну, этот язык - сплошная трудность.

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

Сейбел:Говоря о программировании, есть ли что-то, чему научила вас работа над Java и обдумывание его структуры?

Блох:Очень многому. Об одном я упоминал в своем посте “Nearly All Binary Searches and Mergesorts Are Broken” (Почти все двоичные поиски и сортировки слиянием сломаны): невероятно трудно правильно написать даже небольшую программу. Мы обманываем сами себя, считая, что наши программы более-менее свободны от ошибок. Это не так. Большей частью наши программы не содержат ошибок лишь настолько, чтобы справляться с возложенной на них задачей.

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

Я укрепился в своем мнении насчет того, что нужна качественная документация API. Javadoc во многом способствовал успеху платформы, хотя не все это замечают. Качественная документация API всегда была частью Java-культуры, как я считаю, потому что Javadoc присутствовал с самого начала.

Я также утвердился в своем мнении, что чем проще - тем лучше. Я наблюдаю все больше сложных добавлений, которые оказываются только вредными в долгосрочном плане, а иногда и в краткосрочном. Создавая программу, я включаю свой собственный “измеритель сложности”: если стрелка уходит в красную зону, пора переписывать.

Порой кто-нибудь говорит мне: “Джош, глупец, ты просто не улавливаешь, что тут происходит. Тут все именно так, как должно быть, и жаль, что ты этого не понимаешь!” Но я не покупаюсь на такие разговоры. Я считаю, что если программа становится слишком сложной, то с ней что-то не так и надо искать более простые пути.

Тони Хоар как-то на вручении премии Тьюринга блестяще сказал о том, что есть два способа проектировать систему: “Один - сделать ее настолько простой, что в ней совершенно очевидно не будет недостатков, второй - сделать ее настолько сложной, что в ней не будет очевидных недостатков”.

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