Category: дизайн

Category was added automatically. Read all entries about "дизайн".

Default

Вилки Эпла



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

Update. Производитель реабилитирован. В комментариях мне показали фото шнура, который решает и проблему и который не поставляется в комплекте айпада.
Default

Документация программного кода

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

Честно говоря, меня это довольно сильно обескуражило. С одной стороны - мое участие в проекте ограничено считанными днями, не в последнюю (если не в первую) очередь из-за моей дороговизны, из-за чего я стараюсь выжать из себя за эти дни как можно больше работающего и оттестированного кода, с другой - оказывается, часть этого времени стоит посвятить написанию комментариев. Не юнит-тестов, а комментариев.

Не могу не процитировать: "Design is documented by creating unit tests as working examples of how to use each part of the code." Robert Martin a.k.a. Uncle Bob.

Именно это я и делаю. Тесты пишутся не только для проверки корректности алгоритма. Часть тестов пишется как пример использования API. Причем в отличие от комментария, тест не может незаметно устареть.

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

P.S. Don't get me wrong. Комментарии необходимы для пояснения неочевидных выборов или отклонений от стандартных ходов. Но по моему личному опыту на такое приходится не больше 10 процентов кода, вот это и надо комментировать, а не все подряд.
Default

Тарковский в Скандинавии

Вчера на корпоративной пьянке молодой дизайнер из Швеции признался мне в любви к Тарковскому. Любви необъятной - он все фильмы его смотрел-пересмотрел, но так и не насмотрелся. Еще он влюблен в Эйзенштейна.

Не первый раз я встречаю у молодых (именно молодых) скандинавов обожествление Тарковского. На прошлой работе был парень лет двадцати, который в свои годы знал всего Тарковского. И мое удивление встретил удивлением - а как же не знать-то?

Интересно, что буквально несколько дней назад я увидел, что Оля отнесла к себе в комнату два ДВД: с "Андреем Рублевым" и "Сталкером". Которые я купил несколько лет назад (издание Criterion, с английскими субтитрами) и которые у нее так и не было времени посмотреть. До прошлой недели, когда ей посоветовали это сделать друзья. Такие же, как она - по 18-19 лет.
Default

Exception handling revisited

Сегодня, переписав все наши программы с заменой кодов ошибки на исключения (exceptions), могу констатировать, что решение, обсуждавшееся несколько месяцев назад, было верным. Никаких кодов ошибок, только исключения!

Интересно (и ободряюще) было узнать, насколько этот подход совпадал с идеями, изложенным Джеффри Рихтером в его презентации на Devscovery:

- When designing a type, you imagine how the type will be used and implement an interface accordingly

- Each member's name is a verb
Methods: "Transfer", "Add", "Lookup", "Enter", etc.
Constructors: "Create" and object
Properties: "Get", "Set"
Events: "Add", "Remove"


- If method can't do what it says it will do (for any reason), throw an exception

- Good mind set: An exception indicates a member-level failure, not an application-level "bug"!
A designer can't imagine all the ways their type will be used
ONLY the caller can know if an attempted usage is a "bug"


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

Статистика успехов программных проектов

По материалам Standish Group, только 26% процентов разработок компьютерных программ, завершаются успешно. 28% заканчиваются неудачей, 46% - не дают ожидаемых результатов, но по тем или иным причинам не закрываются.

Некоторые другие цифры:

Средний перерасход средств - 189%
Проекты, требующие коренной переработки дизайна - 94%
Средний перерасход времени - 222%
Количество реализованных функций по сравнению со спецификацией - 61%

UPDATE. piggymouse поправил, что нынешняя статистика улучшилась. Другие результаты - http://www.standishgroup.com/sample_research/index.php.