Я уже достаточно давно читаю блог Элдара Мусаева "Мысли которые не удалось удержать в голове". Читать собственно начал с того момента как прослушал его замечательный ролик на русском Channel 9 - "Про маразм и program management", зашел на блог ... да так там и остался :-) Рекомендую!
Обнаружил две интересные статьи. В частности они касаются некоторых вопросов, которые обсуждались в моих постах про "Дао Русского программиста", про то как научиться программировать и про то какие знания необходимы программисту.
Почитайте, интересно:
Я уже довольно давно читаю блог команды разработчиков Visual C++ и должен сказать что это довольно таки занудный блог. Но вот последняя статья в нем - буквально таки жемчужина. // a.h – share class definition (code has been corrected from original post) #pragma once class Test_A { Test_A(){ c = 'X'; data = 0; } ~Test_A(){ if(data) delete [] data; } char c; }; void Test_A_Loader(Test_A&); // loader.cpp - loader defn. void Test_A_Loader(Test_A& a) { a.c = 'p'; } // main.cpp - main program #include "a.h" int main(){ Test_A a; }
Не очень часто мы сталкиваемся с проблемой неодинакового выравнивания одних и тех же классов в разных единицах трансляции. Проблему трудно диагностировать и даже очень трудно. Так вот статья рассказывает про замечательный и конечно же НЕ документированный и не поддерживаемый ключ компилятора:
/d1reportSingleClassLayoutXXX, где XXX - интересующее нас имя класса.
При компиляции с этим ключом, компилятор показывает, как с его точки зрения "разложился" класс XXX. Вот код из статьи:
public:
char* data;
#include
#include "a.h"
a.data = new char[10];
strcpy(a.data, "3.14159");
#include
Test_A_Loader(a);
printf("%c : %c %c %c %c\n", a.c, a.data[0], a.data[1], a.data[2], a.data[3]);
cl main.cpp /Zp2 /c
cl loader.cpp /Zp1 /c
link main.obj loader.obj
При этом конечно возникает ошибка с выравниванием, поскольку класс Test_A выровнен по разному в единице трансляции main.cpp и в единице трансляции loader.cpp.
А вот вывод компилятор при использовании волшебного ключика '/d1reportSingleClassLayoutTest_A' (почему то в статье вывод компилятора целиком не приведён, а мне кажется что это интересно):
1>------ Build started: Project: ClassLayout, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>Compiling...
1>loader.cpp
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>Compiling...
1>ClassLayout.cpp
1>class Test_A size(6):
1> +---
1> 0 | c
1> | <alignment member> (size=1)
1> 2 | data
1> +---
1>class Test_A size(6):
1> +---
1> 0 | c
1> | <alignment member> (size=1)
1> 2 | data
1> +---
1>Linking...
1>Embedding manifest...
1>Build log was saved at "file://l:\ClassLayout\Debug\BuildLog.htm"
1>ClassLayout - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
Я сегодня выступаю в не очень привычном для себя жанре. Этот пост - ответ.
Я думаю что Максима Кононенко, также известного как Mr.Parker знают все. Ну если и не знают, то слышали про него уж точно очень многие. Он - создатель популярного сайта Владимир Владимирович™, известный блоггер, сетевой писатель и журналист. А также программист. Вот я как раз про это. Некоторое время назад вышел пост Максима под названием: Путь без конца или Дао русского программиста. Именно этот пост я и хочу здесь разобрать. Так что уж не обессудьте, для того чтобы читать дальше придётся сначала сначала прочитать исходный пост.
(замечание: данный ответ также опубликован и как комментарий к самому посту Максима - только без вступительной части)
К вопросу о терминологии
Похоже, что в исходном посте термин "программирование" понимается совсем не так как понимаю его например я. В моей голове есть несколько терминов, несколько "ролей", нужных например для того чтобы организовать компанию, которая производит и продаёт программы. Вот этот (скорее всего неполный) список:
Умеете ли вы программировать? Сам факт того, что вы сейчас читаете данный текст, скорее всего означает что вы имеете какое-то отношение к программированию. И уж точно у вас есть к нему интерес, иначе вы бы просто не знали про существование этого блога. Ну или в крайнем случае у вас есть друзья или знакомые программисты. Так или иначе многие сейчас задаются вопросом "как научиться программировать?".
Это сложный вопрос и я конечно не смогу на него ответить, так что я разочарую тех, кто надеялся получить какой-то готовый рецепт. Когда-то давно я прочитал замечательное эссе Питера Норвига на эту тему. Эссе называется "Научитесь программировать за 10 лет". Его можно прочитать в первоисточнике, а также в русском переводе. Эссе посвящено тому, как по мнению Норвига нужно подходить к (само)обучению программированию, а название это естественно пародия на многочисленные книги типа "Научитесь XXX за 21 день".
Сегодня я ещё раз перечитал это эссе, и заметил там для себя что-то, чего не замечал раньше. Ну, точнее замечал, но как-то не придавал должного внимания. А именно, отношение Норвига к поверхностному обучению. В самом начале эссе, он в шутку разбирает что бы могло на самом деле обозначать название книги "Изучите Паскаль за 3 дня". В частности, Норвиг пишет: "... за три дня вы можете получить только поверхностное представление о языке, а не глубокое понимание. Как говорил Александр Поуп - "Недостаточное обучение - это очень опасная вещь".
Это очень верное замечание, на которое стоит обратить внимание. Именно поэтому в одном из своих предыдущих постов, посвящённом вопросам на собеседовании, я и писал что необходимо проверять базовые знания. Задавать "простейшие" вопросы(в кавычках, поскольку это вопросы на самом деле не простые, просто мы настолько привыкли давать на них ответы-"отписки", что не очень задумываемся о сути). Проверять именно глубину знаний. Проверять что человек умеет программировать, и не впадёт в ступор, когда закон
"закон дырявых абстракций" (The law of leaky abstractions") покажет себя.
Перечитайте ещё раз статью Норвига (ну или прочитайте её, если не читали раньше). На самом деле она ведь не только про программирование ;-)
Про вопросы на собеседовании очень многие уже писали. Но мне кажется все писали неправильно :-) Вообще-то я глубоко убеждён в том, что собеседование - процесс практически безнадёжный и что единственный способ понять подходит ли человек для работы - это поработать с ним. Ну поскольку этот способ слишком дорогой, то приходится прибегать к собеседованию.
Все соображения на тему "Как проводить собеседование" напоминают мне одну известную шутку.
Молодую девушку пригласили на свидание и она спрашивает маму - "Как вести беседу?" Мам отвечает - "Ну поговорите сначала о погоде, потом, к примеру, о музыке, а потом скажи что-нибудь остренькое". Во время свидания сразу же после встречи девушка и говорит: "Какая чудная погода, училась музыке три года, бритва."
Так, вот не хочу чтобы так проводились собеседования. На мой вкус самое главное что стоит попробовать проверить - это понимание основ. (Я пишу конечно только про программистов). Просто программист без основ, на мой взгляд, невозможен.
Поэтому я просто приведу примеры вопросов, которые могли бы спровоцировать дискуссию, раскрыть насколько хорошо человек понимает основы (не сгруппированы по тематике):
blog: 
LinkedIn
Мой Круг