Читать!

Up ] Джоэл о программном обеспечении ] Эрик Синк о малом софтверном бизнесе ]


Joel On Software

Джоэл закончил Йель, отслужив до этого в Израильском десанте. Он работал в Microsoft над спецификацией макроязыка для Excel (впоследствии это стало называться VBA). Теперь у него небольшая софтверная компания в Нью-Йорке со странным названием и он регулярно делится со всем миром своим видением путей развития индустрии ПО, регулярно публикуя эссе на своём сайте JoelOnSoftware.com. Джоэл умён и любопытен, он умеет задавать правильные вопросы. Часто это важнее, чем знание ответов. Кроме того, он ещё и хорошо пишет.

 


Джоэл о программном обеспечении

Джоэл Спольски.

Джоэл о программировании

-М,: Символ-Плюс, 2006. 352 с.
ISBN 5-93286-063-4

Оригинал вышел в 2004-м в издательстве Apress:

Joel Spolsky

JOEL ON SOFTWARE

And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity

ISBN 1-59059-389-8.

 

В июне 2008 года в издательстве Apress вышло продолжение бестселлера -

More Joel on Software

Further Thoughts on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity.

By Joel Spolsky

ISBN10: 1-4302-0987-9
ISBN13: 978-1-4302-0987-4

320 pp.

 

 


Отрывки

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

Во всех программах, кроме самых тривиальных, в API, операционных системах и библиотеках классов следует избегать ASCIZ-строк, как заразы. Почему?
Стр. 22

Именно это имеется в виду, когда говорят, что некая программа имеет уязвимость в виде переполнения буфера. Это было главной причиной взломов и червей в те достопамятные времена, когда Microsoft Outlook ещё не сделал хакинг доступным даже подросткам.
Стр. 26

... нельзя основываться на XML, если требуется высокая производительность и объём данных велик.
Стр. 30

Я испытываю совершенное отвращение к многочисленным программам обучения, в которых Java принят в качестве хорошего начального языка, потому что он "прост"... Такое преподавание ведёт нас к катастрофе.
Стр. 30

... при прочих равных условиях, если эти 12 пунктов выполняются, значит, у вас есть дисциплинированная команда, способная стабильно выдавать готовый продукт.
Стр. 33

... в любой момент времени устранение ошибок имеет более высокий приоритет, чем написание нового кода. И вот почему.
Стр. 36

Во всяком случае следует неукоснительно соблюдать правило, гласящее, что "код нельзя писать без спецификации".
Стр. 39

В первоклассных командах не принято мучить программистов.
Стр. 41

Даже если у вас отсутствуют навыки проектирования интерфейса пользователя, заставьте себя выполнить "коридорное" тестирование юзабилити (которое ничего не будет вам стоить), и вы значительно улучшите интерфейс.
Стр. 43

Если вы заметите, что слишком много времени тратите на установку и конфигурирование гигантских систем программной методологии или неких пакетов под названием "Визуальное нечто, архитектор масштаба предприятия", или постоянно обучаете своих разработчиков то экстремальному программированию, то UML, пока у них голова не начнёт идти кругом, будьте готовы к неприятностям.
Стр. 44.

Некоторые пребывают в заблуждении, считая, что Unicode является просто 16-разрядным кодом, в котором, следовательно, может быть 65536 различных символов. Но на самом деле это неверно. Это самый распространенный миф о Unicode, поэтому не расстраивайтесь, если вы тоже так думали.
Стр.49

Строка не имеет никакого смысла, если вы не знаете в какой кодировке она записана. Не прячьте голову в песок и не делайте вид, что "обычный" текст - это ASCII. Нет такого понятия, как простой текст.
Стр. 53

Прежде всего, отсутствие спецификации - это самый крупный и совершенно ненужный риск, который вы берете на себя, принимаясь за программный проект. ... Я считаю, что в любом нетривиальном проекте (то есть требующем больше недели кодирования или более одного программиста) отсутствие спецификации всегда приводит к потерям времени и снижению качества кода. Объясню почему.
Стр. 57

Очень распространенная ошибка - обсуждать, как сделать что-то, а затем не принять никакого решения. У Брайана Валентайна, ведущего разработчика Windows 2000, был знаменитый лозунг: "либо решение принимается в течении 10 минут, либо вопрос снимается с повестки". Очень часто в фирмах, создающих программное обеспечение, при обсуждении проекта никто не берёт на себя смелость принять решение, обычно из политических соображений. Поэтому программисты работают только над тем, что не вызывает споров. В результате время идёт, а трудные решения откладываются на конец. Такие проекты - первые кандидаты на провал.
Стр. 62

Ещё архитектурные астронавты очень любят изобрести какую-нибудь новую архитектуру и утверждать, что она решает некую проблему. Java, SOAP, XML-RPC, HailStorm, .NET, Jini - нет сил продолжать. И это только в течении одного года.
Стр. 121

Такого рода людей я называю архитектурными астронавтами. Очень трудно посадить их писать код или проектировать программы, потому что они непрерывно размышляют об архитектуре. ... Это настоящие астронавты, потому что они настолько выше содержащей кислород атмосферы, что непонятно, чем  они дышат. Они стараются работать в очень крупных компаниях, которые могут себе позволить содержать массу ничего не производящих людей с высокими званиями, ничего не вносящих в конечные результаты.
Стр. 121

Помните, что эти архитекторы решают те проблемы, которые, как им кажется, они могут решить, а не те проблемы, которые было бы полезно решить. Возможно SOAP+WSDL - это самая горячая новость, но с её помощью вы не сделаете ничего такого, чего не могли делать раньше с помощью других технологий... если вам это действительно было нужно.
Стр. 123

Когда я был в Израиле парашютистом, один генерал произнес перед нами небольшую речь по поводу стратегии. Когда пехота ведёт бой, сообщил он нам, у неё может быть только одна стратегия: огонь и движение. ... И это работает. ... Мне понадобилось ещё 15 лет, чтобы понять, что по принципу "огня и движения" вы достигаете целей в жизни. Надо хоть немного продвигаться вперёд, каждый день.
Стр. 126

Посмотрите на историю стратегий доступа к данным, вышедшим из недр Microsoft. ODBC, RDO, DAO, ADO, OLEDB, а теперь ADO.NET - все новые! Что это - технологическая необходимость? Результат некомпетентности проектировщиков, вынужденных каждый год изобретать новый способ доступа к данным? (Весьма возможно, что именно так.) Но конечный результат - это огонь прикрытия.
Стр. 127

Найти хороших тестеров очень трудно. С ними, как с программистами: лучшие из них на порядок выше средних.
Стр. 183

Они (Netscape) совершили самую тяжелую стратегическую ошибку, которую может сделать компания-разработчик программного обеспечения: они решили переписать весь код заново.
Стр. 190

Мысль о  том, что новый код лучше, чем старый, явно абсурдна.
Стр. 192

... единственный способ компетентно справляться с дырами, это изучить как действуют эти абстракции и от чего они нас абстрагируют. Поэтому абстракции дают возможность тратить меньше времени на работу, но не  дают возможность тратить меньше времени на учебу. Всё это приводит к парадоксу: средства программирования поднимаются на всё более высокий уровень, и абстракции становятся всё лучше, а стать искусным программистом становится всё труднее.
Стр. 206.

Чтобы стать специалистом, настоящим экспертом лишь в отдельной области программирования, нужны годы. Конечно, есть масса толковых подростков, которые за неделю осваивают Delphi, ещё за неделю Python, ещё за неделю Perl, после чего они считают себя знатоками. При этом у них нет даже самого отдаленного представления о том, сколь многого они не знают.
Стр. 208

Итак, на сегодняшний день мой совет следующий: не беритесь за новый проект, не располагая хотя бы одним архитектором с несколькими годами серьезной работы с языком, классами, API и платформами, для которых вы делаете продукт.
Стр. 214

Если хотите знать моё мнение, а оно предвзятое, то никакая софтверная компания не может добиться успеха, если у руля в ней не стоит программист. Все живые до сих пор свидетельства подтверждают мой вывод.
Стр. 222

Я думаю, достаточно очевидно, что блюда голого повара лучше, чем гастрономические изыски от Макдоналдс. Хотя это звучит глупо, но стоит на минуту задуматься почему. Это не такой глупый вопрос. Почему крупная компания с неизмеримыми ресурсами, огромными масштабами, возможностью привлечь лучших гастрономов, каких только можно купить за деньги, и неистощимыми финансами не может производить отличную еду?
...
Подведём итог сказанному:
1. Чтобы действительно хорошо делать некоторые вещи, нужен талант.
2. Талант трудно масштабировать.
3. Один из способов масштабирования таланта - предложить его носителю написать инструкции, которые должны выполнять те, у кого таланта нет.
4. Качество получаемого продукта очень низкое.
Абсолютно такая же ситуация имеет место в ИТ-консалтинге.
Стр. 243

ПО туманных обещаний означает предложение всевозможных функций и продуктов, которых вам не продадут, потому что в действительности их не существует. Но .NET ещё хуже... Я не хочу сказать, что в .NET нет ничего нового. Я хочу сказать, что там нет ничего вообще.
Стр. 316

Очень похоже, что Microsoft .NET, не удовлетворяя ни единой потребности клиентов, удовлетворяет потребность Microsoft занять чем-то 10 000 программистов на ближайшие десять лет.
Стр. 319

Отлаженный код не является бесплатным, находится он в чьей-то собственности или он открыт. Даже если за него не платят наличными, у него есть стоимость упущенных возможностей и стоимость времени.
Стр. 283

 


More Joel

03.03.2010. В марте закроется программистский блог Joel on Software.

 

 
 

Joel On Software - Джоэл о программном обеспечении

This page was first published on August 08, 2007. 
This page was last updated on March 3, 2010.


© 2007-2010 Евгений Ахунджанов. Все права сохранены.
www.transcriber.ru | Послать письмо автору