Лорд Палмерстон в программировании

Автор: Джоэл Сполски

Переводчик: Федор Иркашов

Декабрь 11, 2002

Были времена, когда если вы прочли Питера Нортона, вы знали все, что можно было знать о программировании IBM-PC. За последние 20 лет программисты во всем мире много проработали, выстраивая обобщение над обобщением на IBM-PC, что бы сделать программирование легким и более мощным.

Но закон гласит, что даже если они строят обобщения позволяющие сделать программирование проще, количество вещей которые вы должны знать, что бы быть отличным программистом все время возрастает.

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

Я проработал с ASP и VBScript, с тех пор как они только появились. VBScript изящнейший язык на земле и ASP программирование состоит в изучении пяти классов, только два из которых используются достаточно часто. И только сейчас наконец я по видимому знаю лучший способ построения ASP/VBScript приложений. Я думаю, что узнал, наконец, где лучшее место размещения кода для доступа к базе данных, лучший способ использования ADO для получения наборов данных, лучший способ разделить HTML и код и так далее. И я в довершение всего использую регулярные выражения вместо специальных на каждый случай функций работы со строками. Только на последней неделе я научился выгружать COM объекты из памяти, для того чтобы перекомпилировать их (без перезапуска всего COM сервера).

Fog Creek слишком мала что бы иметь узких специалистов, таким образом когда мне понадобилось написать по настоящему хороший инсталлятор для , нашего основанного ASP/VBScript продукта, мне понадобилось несколько лет опыта в C++/MFC и годы опыта с различными Windows API, а также хорошие навыки работы с Corel PhotoPaint для того чтобы нарисовать подходящую картинку в углу диалогового окна мастера. Тогда для того чтобы FogBUGZ отлично работал с Unicode, мне понадобилось написать маленький ActiveX элемент управления с использованием C++ и ATL, для чего понадобились годы опытов в С++ и COM и неделя или около того обучения кодировкам символов в то время, как я реализовывал этот код для CityDesk.

Таким образом, когда мне встретилась непонятная ошибка, проявлявшаяся только в Windows NT 4.0, мне понадобилось только 3 минуты отладки, потому что я знал, как использовать VMWare, и у меня была чистая предустановленная NT 4.0 для VMWare, также я знал, как выполнять удаленную отладку в Visual C++ и я знал, что надо заглянуть в EAX регистр для получения, возвращаемого функцией значения. Тому, кому это все в новинку понадобилось бы час или более что бы отладить ту же самую проблему, а я уже знал огромное количество “штучек” которым я учился, по существу, с 1982 года когда я получил мой первый IBM-PC и ту самую книгу Питера Нортона.

Неудержимые абстракции ведут к тому, что мы живем с очень резкой кривой обучения: вы можете выучить 90% того, что вы используете каждый день за неделю обучения. Но что бы разобраться в остальных 10% займет еще пару лет. Это то, чем по настоящему опытные программисты отличаются от людей, которые говорят ”не важно, что вы хотите, что бы я сделал, я могу открыть книгу и научиться делать это”. Если вы строите команду, это нормально иметь множество менее опытных программистов для написания больших участков кода с использованием обобщенных инструментов, но команда не может начать работать, если у вас нет нескольких по настоящему опытных членов команды для выполнения действительно сложной работы.

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

Все, по существу, что вы могли бы назвать Windows программированием. Да, я писал Unix код и Java код, но не очень много. Моя квалификация в Windows программировании проистекает оттого, что я знаю не только базовые технологии, но и всю поддерживающую инфраструктуру. Таким образом, я утверждаю, что я действительно хорош в Windows программировании, потому что я также знаю COM, ATL, C++, 80x86 Ассемблер, различные Windows API, IDispatch (OLE Automation), HTML, DOM, объектную модель Internet Explorer, внутренности Windows NT and Windows 95, LAN Manager и сетевую работу в NT, включая безопасность (ACEs, ACLs, и все остальные вещи), SQL и SQL Сервер, Jet и Access, JavaScript, XML, и несколько других о площади гипотенузы. Когда я не смог добиться от StrConv функции того чего я хотел, я сварганил элемент управления COM что бы попасть в C++ с помощью ATL и вызвать MLang функции, что бы не оказаться побежденным. Мне понадобились годы, что бы достичь этого.

Существует множество других областей программирования. Скажем люди, разрабатывающие для BEA Weblogic, которые знают J2EE, Oracle и всевозможные Java штучки, о которых я не знаю достаточно даже для того чтобы их перечислить. Или твердое ядро разработчиков для Macintosh, которые знают CodeWarrior, MPW, Toolbox программирование in System 6 через X, Cocoa, Carbon, и даже такие такую милую устаревшую вещь как OpenDoc, которая не может больше помочь.

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

Но учиться вы должны.

Люди отчасти , когда они приходят на собеседование и получают отказ, потому что они не имеют опыта в Win32 (или в J2EE, или в Mac программировании, или чем-нибудь еще). Или они раздражаются, потому что идиоты рекрутеры, которые не узнали бы MSMQ даже если бы он пинал их под зад, звонят им и спрашивают “Имеют ли они 5 лет опыта в MSMQ ”.

До тех пор пока вы не посвятите Windows программированию множество времени, вы можете думать, что Win32 это всего-навсего библиотека, похожая на многие другие библиотеки, вы прочитаете книжку, выучите ее и будете вызывать, когда она вам понадобится. Вы можете думать, что основу программирования составляют ваши превосходные C++ знания 90%, а различные API это только 10%-ый пушок, в котором вы сможете разобраться за несколько недель. Этим людям я скромно подсказываю: времена изменились. Соотношение изменилось на противоположное.

Очень немного людей работает над низкоуровневыми C алгоритмами, которые только перемещают байты и не более того. Большинство из нас проводит все наше время эти дни, вызывая различные API, а, вовсе не перемещая байты. Каким бы превосходным C++ кодировщиком ни был человек без опыта в API, он знает только около 10% того, что он должен использовать каждый день для написания кода запускаемого на API. Когда дела в экономике , это не имеет значения. Вы все еще имеете работу и наниматели платят стоимость вашего обучения соответствующей платформе. Но когда в и 600 человек подают заявления на каждую открытую вакансию, наниматели могут позволить себе удовольствие выбирать программистов которые уже эксперты в интересующей их области. Например, программистов, которые могут назвать четыре пути заслать файл по FPT из кода на Visual Basic и слабые и сильные стороны каждого из них.

Огромные пространства всех этих областей ведут к бесцельным зажигательным войнам (flame wars) чей мир лучше. Вот такой самодовольный комментарий сделал кто-то анонимно на моей доске обсуждений:

“Еще одна причина почему мне нравится жить в ‘свободном мире’. Свобода слова (практически полная) и свобода от засилья таких вещей как установочные программы и реестр – я упомянул лишь немногие из них.”

Я думаю этот человек хотел сказать, что в Linux он не должен писать установочные программы. Ну, ненавижу разочаровывать вас, но вы имеете кое-что гораздо более осложненное: imake, make, config files и все эти штуки, и когда вы заканчиваете, вы должны распространять приложения с 20Kb INSTALL файлами полных остроумных инструкций типа “Вам понадобится zlib” (что это?) или “Это может занять некоторое время. Идите возьмите каких-нибудь сморчков(runts)” (сморчки это тип конфет, я думаю). И реестр — вместо одного большого улья (hive) имя/значение пар, вы имеете тысячи разных файловых форматов, по одному на приложение, .whateverrc и foo.conf расплодившимися повсюду. Emacs принуждает вас изучать, как программировать на Лиспе, если вы захотите изменить настройки, также каждая оболочка (shell) принуждает вас изучать ее персональный диалект shell script программирования если вы захотите изменить настройки и так далее, и так далее.

Люди который знают только одну область программирования становятся действительно ограниченными и всякий раз когда они слышат о осложнениях в других областях, это заставляет их думать что их область не имеет осложнений. Но они есть. Вы минуете их потому, что умеете это делать. Эти области очень большие и сложные в сравнении с чем бы то ни было. Лорд Палмерстон: “Шлезвиг-Гольштейн вопрос настолько осложнен, что только три человека в Европе вообще понимают его. Один был Принц Альберт, который умер. Второй был немецкий профессор, который сошел с ума. Я третий и я уже забыл все, что знал о нем”. Различные области программного обеспечения настолько огромны и имеют настолько много аспектов, что когда я вижу других умных людей пишущих сообщения об ошибках (blog entry) говорящие что-то , например “Microsoft это плохая операционная система”, откровенно говоря, это выглядит глупо. Вообразите попытку охватить миллионы строк кода с сотнями основных областей созданных тысячами программистов за одно или два десятилетия, тогда как нет ни одного человека, который мог бы разобраться даже в большей части этого. Я также не защищаю Microsoft, я только говорю что слишком большие обобщения сделанные с позиции большого невежества это одна из самых больших потерь времени в сети сегодня.

Постоянные читатели, к этому времени заметили, что я думал о проблеме возможности выпуска приложений для Linux, Macintosh, и Windows без необходимости несоразмерно платить за Linux и Macintosh версии. Для этого вам нужна какая-нибудь кросс - платформенная библиотека.

Java была такой, но Sun не понимала пользовательский интерфейс настолько хорошо, что бы выпустить действительно гладкие естественно ощущающиеся приложения. Подобно тому как из Звездного пути смотрящие на землю через телескопы, они знали точно на что человеческая еда должно быть похожа, но они не понимали что она должна иметь вкус как у человеческой еды. E У Java приложений меню расположены в правильном месте, но они работают совсем не так, как в других Windows приложениях. А их диалоги с закладками выглядят довольно страшно. И нет пути, не важно как усердно ты трудишься, сделать их меню выглядящим точно как Excel меню. Почему? Потому что Java не дает тебе достаточно хорошего пути обратится к родным возможностям платформы, так как это сломало бы обобщение. Когда вы программируете в AWT вы не можете выяснить HWND окна, вы не можете вызвать ни один из Microsoft API и вы естественно не можете перехватить WM_PAINT и обработать его по-своему. И Sun сделал это достаточно ясно, если вы попытаетесь сделать это то, не будете Чисты. Вы будете Испачканы, и черт с вами.

После нескольких хорошо освещенных провалов построить пользовательский интерфейс с использованием Java (т.е. Corel's Java Office suite и Netscape's Javagator), достаточно много людей решили держатся подальше от этой области. построил оконную библиотеку с самого основания используя только родные элемент управления, таким образом они могли писать Java код и при этом иметь приемлемый вид окон и ощущения от работы с ними.

Mozilla инженеры решили разрешить с помощью своего собственного изобретения названного XUL. До сих пор я впечатлен. Mozilla, наконец, добралась до момента, где она на вкус как настоящая еда. Даже мое любимое пугало Alt+Space N для минимизации окна работает в Mozilla. Это заняло у них достаточно много времени, но они сделали это.

Mitch Kapor, который основал Lotus и создал 123, в своем следующем приложении использовать нечто называемое wxWindows и wxPython для кросс платформенной поддержки.

Что лучше XUL, Eclipse's SWT, или wxWindows? Я не знаю. Все они настолько большие области, что я не могу по настоящему попробовать их и сказать. Не достаточно просто прочитать описание. Вы должны кровью и потом проработать с этими приложением год или два, перед тем как вы узнаете, что оно достаточно хорошо, либо поймете, что не имеет значения все ваши старания, вы не сможете придать вашему графическому интерфейсу вкус настоящей еды. К несчастью, для большинства проектов вы должны решить, какую область программирования вы будете использовать, перед тем как напишите первую строчку кода, а это уж точно момент, когда вы имеете меньше всего информации. В нашей предыдущей работе у нас была довольно плохая архитектура, потому что первые программисты учились программированию C++ и программированию под Windows в процессе работы над проектом. Старейший код был написан без всякого представления об управляемом событиями программировании. Базовый класс для представления строк (конечно, мы имели свой собственный класс) был взят из книжного примера и содержал все ошибки, которые вы можете сделать, проектируя C++ класс. В конце концов, мы вычистили и переработали множество этого старого кода, но он доставал нас время от времени.

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

В английском оригинале статья называется