суббота, 4 декабря 2010 г.

Языки программирования как религии

Нашёл забавную вещь:
языки программирования как религии

Итого, я сейчас мусульманин, который часто занимается сатанизмом, а также ищет к себе в секту ещё по паре мормонов, католиков и мусульман. :)

Вот если бы ещё в этом перечне было отражено общение с бизнесс-аналитиками... Хотя это скорее всего "общение с Внеземным Разумом" ;)
Так что я ещё на полставки являюсь ещё охотником за НЛО :)

А что получилось у Вас? 

Вопрос об интерфейсах

Похоже, что я нашёл самый сложный вопрос для собеседований по C++ - полностью правильного ответа ещё ни разу не слышал, а ведь не junior'ов собеседую...
Звучит он приблизительно так:
Есть такие понятия в ООП как "наследование реализации" и "наследование интерфейса"... Как Вы понимаете "наследование интерфейса" и есть ли оно в C++?

Т.е. вопрос вроде бы простой...
И вот самое странное, что почти у всех кандидатов при ответе обнаруживается некая каша из ключевого слова interface, понятия абстрактного класса, понятия класса реализующего некий интерфейс, собственно понятия интерфейса и иногда даже COM-интерфейса. Т.е. каждый приходит со своими ингридиентами к каше :) В таких условиях ожидать идеально правильного ответа невозможно, зато это позволяет "залезть в голову" кандидату.

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

 
А теперь доберёмся до приблизительно правильного ответа как его вижу я.

пятница, 17 сентября 2010 г.

Null Object и проблемы, которые он может принести

У Степанова в его лекциях по программированию мимоходом рассказывается о проблеме, которую привносит в template algorithm'ы STL'я и в обобщённое программирование на C++, требование IEEE стандарта к наличию специального значения в диапазонах double/float( NaN - Not a Number).

Подробности можно прочитать в Notes from the lectures of Programming by Alexandr Stepanov, но суть проблемы следующая:

Любая операция сравнения, которая выполняется с NaN, должна возвращать false. Такое требование закладывает мину практически во все алгоритмы из библиотеки STL, которые опираются на операции сравнения.

Степанов заявляет, что так как это случай редкий и касается только 1 типа, то можно его проигнорировать. Но здесь на сцену выходят Фаулер и Кириевски с их идеей рефакторинга "Introduce Null Object", и мы по сути получаем проблему, которую Степанов считал малозначащей, только перенесённую уже и в другие языки программирования, а не только на C++.

Дальше чуть более подробно мои размышления на эту тему...

суббота, 4 сентября 2010 г.

Спасибо Reddit - набрёл на чудную вещь:
10 things i hate about OOP

Часть изложеного - именно соль взаимоотношений с OOP. но оставшиеся процентов 20-30 такие забавные :)

"О языках" - всё красиво и подняло настроение, но почему вообще не вспомнили C#?  наверное он был слишком молод :)
Ну и конечно методология Чак Нориса ...

понедельник, 24 мая 2010 г.

Прочитав статью, зацепился за несколько моментов, которые заставили более чётко сформулировать чеклист о том, как входить в команду уже работающую на проекте.

Этот чеклист (хотя он получился чеклистом с приоритетами, а не линейным чеклистом) и идёт ниже.

воскресенье, 25 апреля 2010 г.

Хорошая статья о процессах разработки ПО

Хорошая статья о процессах разработки ПО:
Уокер Ройс о процессах разработки ПО
Как интересный вывод из статьи - скоро будет что-то новое в этой области

Отсебятина:
Процессы разработки ПО: IBM and Toyota - за этими именами почти всё сделанное в этой области.
Waterfall, RUP - свои области применимости нашли, Agile заканчивает свою эволюцию (он всегда стремился к легковестности, а что может быть легковесней Kanban - уж не знаю), так что действительно стоит ожидать чего-то нового. Но будет ли появление этого нового с большим бумом - не понятно.

вторник, 20 апреля 2010 г.

PDP: чтение книг

На предыдущем проекте просто рекомендовал книги к прочтению. Без упора на обязательность. Эффект давало - особенно, на тех кто сам хотел учиться, но просто не знал что стоит изучать. Но поскольку это было "добровольно", то рекомендацию иногда (часто) игнорировали. Что ослабляло общий эффект.

Сейчас "уговорил" (назовём это так) всех членов команды выбрать себе 4 книги для обязательного прочтения в течении года. Magic Number внаглую стырил из примера PDP МакКоннела и рекомендации в Pragmatic Programmer.

Естественно, будем сверять и делиться кто и что почерпнул из книг в течении этого года. Т.е. будем строить нормальный PDP.

Зачем я это сделал:
  • Для менеджмента? - Строим нормальный PDP процесс. Улучшаем проффесионализм команды, а значит работа будет делаться качественне и быстрее. 
  • Для самой команды? - Сможем решать часть задач быстрее. Будем чётче понимать последствия наших дизайнерских решений. Структурируем уже полученные знания. Сможем претендовать на более высокую оплату труда.
  • Для себя? - А хз! Скорее всего, не хочу засыпать в болоте - а это просто один из способов растормошить и себя, и окружающих.

Посмотрим, что из этого вырастет через год...

P.S.
А кто у себя внедрял обязательное чтение книг членами команды? И что это дало Вам?

воскресенье, 14 марта 2010 г.

Approved Final Committee Draft for C++

Approved Final Committee Draft (FCD) for C++0x - Ура, товарищи!!! 
Теперь ожидаются только багфиксы и редакторские правки (займёт около года). Так что у нас будет стандарт C++0xB.

P.S.
А CodeBubbles показывают как будет выглядеть IDE в будущем. 

среда, 10 марта 2010 г.

Working Effectively with Legacy Code - впечатления от книги

Наконец-то прочитал Working Effectively with Legacy Code - дождался таки её выхода на русском и прочитал. Общее впечатление от книги - "must read" для тех, кто работает с maintanence.

"Красной нитю через всё произведение проходит" идея о необходимости покрытия кода юнит-тестами. С этой идеей я целиком и полностью согласен, т.к. не так давно приняли LC систему, у которой нет каких-либо тестов (только ручные по сценариям) и с знанием только по общей логике работы программы у предыдущего разработчика - проблема классическая для LC системы - время проверки правильности изменений может занимать до 3-х рабочих дней просто из-за того, что все проверки проходятся вручную.

Что ещё приятно в этой книге, так это то, что автор не навязывает какой-то подход (чем часто грешат метологи аджайла - "юнит тесты ВСЕГДА перед кодом" - блин, это же гибкие методологии разработки! ну как так можно?), он просто показывает как эффективно работать с унаследованным кодом.

Т.е. плюсы книги не заканчиваются на описании TDD, как можно было бы понять из вступления и 1-х глав. Для меня разбор следующих тем является большим плюсом в этой книге:
  1. описываются способы внесения изменений, которые позволяют снизить риск внесения ошибки практически до 0, в случае если нельзя прикрепить тесты к системе из-за каких-то ограничений (архитектурных, например).
  2. какие тесты лучше иметь перед внесением своих изменений и как их лучше подсунуть в систему
  3. какие изменения понадобятся в архитектуре системы для добавления тестов в такой-то области и к чему они приведут
  4. плюсы и минусы различных способов реализации заглушечных функций и объектов для тестов.

Ну а то, что Майкл Физерс является автором CppUnit, является приятной фенечкой этой книги ;)

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

Я бы посоветовал её читать тем кто работает с унаследованными системами где-то через полгода после прочтения Рефакторинга Фаулера и Паттернов Банды Четырёх, по следующим причинам:
  • читать надо после них, т.к. терминология из них активно используется,
  • читать надо с задержкой, чтобы сформировался свой собственный взгляд и понимание maintanence - т.к. чтение "потому что дядя сказал" даст значительно меньше пользы.

Я читал её значительно позже чем советую - об этом сейчас сожалею. Прочитал бы вовремя - сэкономили бы командой кучу времени/нервов на изобретение велосипедов и избежали бы части просчётов в разработке.

Очень бы советовал прочитать "Refactoring to Patterns" by Joshua kirievski на том же этапе, что и Working Effectively with Legacy Code - они прекрасно дополняют друг друга и освещают работу с уже работающими системами с разных точек : Working Effectively with Legacy Code - это больше тактика внесения изменений(изменения в коде), а "Refactoring to Patterns" - это больше стратегия низкого уровня внесения изменений в системы (изменения в дизайне на уровне классов).

ЗЫ
а стратегия высокого уровня внесения изменений в системы - это уже просто перепроектирование системы :p

понедельник, 22 февраля 2010 г.

WPF в Visual Studio 2010: причины

Здесь рассказали о причинах, по которым в Visual Studio 2010 был использован WPF. Если опускать всю воду, то получается следующий список (в порядке описания разработчиком Visual Studio):

  1. надо было использовать WPF в каком-то известном приложении MS по маркетинговым причинам;
  2. архитектура Visual Studio, продолжашая эволюционировать с Visual C++6, начала мешать добавлению новых возможностей в студию.
Если 2-ю причину я могу принять и понять - нужно отбрасывать старое и развязывать логику и пользовательский интерфейс, чтобы удобней было жить потом. То 1-я причина (использование студии для раскрутки WPF) вызывает некоторый дискомфорт в мозгах - "Юзают мой любимый инстумент для раскрутки какой-то технологии, которую я из c++ и попробовать-то не могу!". 
А дальнейшее разъяснение, что использование WPF в студии, так и не было доведено до конца, начинает уже ставить большие знаки вопроса - зачем браться и делать на условных "62%". 

В целом странные ощущения от студии 2010 - реализация части функционала из C++0x, унифицированая система сборки проектов, и в то же время странное решение о использовании WPF для IDE.

суббота, 6 февраля 2010 г.

Статья Саттера об асинхронном API

Недавно вышла новая статья Herb Sutter'а "Prefer Futures to Baked-In "Async APIs" , в которой он анализирует различные варианты как предоставлять асинхронность операций API. В конце статьи Саттер приходит к выводу, что лучше такого не предоставлять отдельное асинхронное API, т.к. любая реализация будет мешать пользователю библиотеки, и тогда разработчик, который пользуется этой библиотекой, сможет сделать асинхронность так, как удобно именно ему, а не какому-то стороннему дяде (привет Adobe с их C++ PDF API), и только для тех функций, которые нужны ему в асинхронном виде. Как один из плюсов такого подхода, Саттер приводит остановку бессмысленного раздувания программных библиотек.

Вот интересно, а сам Саттер понимал, что его статья подтолкнёт программистов, которые используют сторонние библиотеки, к удобной им реализации асинхронности функций, даже в ущерб уже доступному асинхронному API? И зная Саттера с его стремлением к concurrent коду и эффективной реализации многопоточности, можно сказать, что он сознательно провоцирует на это.

Читайте Саттера, кто этого ещё не делает, и обдумывайте прочитанное - возможно самое вкусное вы пока не заметили.