class City
{
public:
City( int x, int y, Country* owner );
~City(void);
struct Transfer
{
int id_country;
int summa;
};
void Init( int nCountries );
void Task();
void Trans( Transfer* transfer );
void ExecuteTransfers();
protected:
void SendTransfers( City* city );
void ClearOfListOfTypeTransfers();
CList<Transfer*, Transfer*> ListOfTypeTransfers;
CList<Transfer*, Transfer*> ListOfOutTransfers;
CList<Transfer*, Transfer*> ListOfInTransfers;
int x, y;
int nCountries;
Country* owner;
bool CityCompleted;
CMap<int,int,int,int> ListOfMotifs;
};
Комментирование исходных текстов
Цитата:
Originally posted by sq_deep
Мне программа понравилась.
Вот если бы в код добавить комментариев, то даже Янукович не смог бы помешать IBM взять вас на работу ;)
Мне программа понравилась.
Вот если бы в код добавить комментариев, то даже Янукович не смог бы помешать IBM взять вас на работу ;)
Да то не в IBM. то в одну киевскую компанию ( они там решили 50 лучших программистов набрать ). Судя по их реакции я в эти программисты не попадаю. Вот сделаю свою контору я им устрою оторванные годы. (Еще одна компания попала в мой персональный черный список). А такой код я называю самодокументированным. :)))
Самодокументированный код такой, который не требует описаний. Комментарии в нём всё равно должны быть. Код
никак таковым не является. Например, назначение переменной CityCompleted из этого кода совершенно не ясно.
Я уже писал раньше, что на вопрос какой оператор должен чаще всего использоваться в программе на любом языке? правильным ответом является "оператор комментария".
Код:
Я уже писал раньше, что на вопрос какой оператор должен чаще всего использоваться в программе на любом языке? правильным ответом является "оператор комментария".
Цитата:
Originally posted by sq_deep
Самодокументированный код такой, который не требует описаний. Комментарии в нём всё равно должны быть. Код
никак таковым не является. Например, назначение переменной CityCompleted из этого кода совершенно не ясно.
Я уже писал раньше, что на вопрос какой оператор должен чаще всего использоваться в программе на любом языке? правильным ответом является "оператор комментария".
Самодокументированный код такой, который не требует описаний. Комментарии в нём всё равно должны быть. Код
Код:
class City
{
public:
City( int x, int y, Country* owner );
~City(void);
struct Transfer
{
int id_country;
int summa;
};
void Init( int nCountries );
void Task();
void Trans( Transfer* transfer );
void ExecuteTransfers();
protected:
void SendTransfers( City* city );
void ClearOfListOfTypeTransfers();
CList<Transfer*, Transfer*> ListOfTypeTransfers;
CList<Transfer*, Transfer*> ListOfOutTransfers;
CList<Transfer*, Transfer*> ListOfInTransfers;
int x, y;
int nCountries;
Country* owner;
bool CityCompleted;
CMap<int,int,int,int> ListOfMotifs;
};
{
public:
City( int x, int y, Country* owner );
~City(void);
struct Transfer
{
int id_country;
int summa;
};
void Init( int nCountries );
void Task();
void Trans( Transfer* transfer );
void ExecuteTransfers();
protected:
void SendTransfers( City* city );
void ClearOfListOfTypeTransfers();
CList<Transfer*, Transfer*> ListOfTypeTransfers;
CList<Transfer*, Transfer*> ListOfOutTransfers;
CList<Transfer*, Transfer*> ListOfInTransfers;
int x, y;
int nCountries;
Country* owner;
bool CityCompleted;
CMap<int,int,int,int> ListOfMotifs;
};
Я уже писал раньше, что на вопрос какой оператор должен чаще всего использоваться в программе на любом языке? правильным ответом является "оператор комментария".
Гмс... несложный анализ показывает что переменная CityCompleted имеет тип bool а потому является флагом что этот город уже completed. Введен для того что один город не генерировал событие о своем completed больше одного раза.
Цитата:
Originally posted by PitxBull
Гмс... несложный анализ показывает что переменная CityCompleted имеет тип bool а потому является флагом что этот город уже completed. Введен для того что один город не генерировал событие о своем completed больше одного раза.
Гмс... несложный анализ показывает что переменная CityCompleted имеет тип bool а потому является флагом что этот город уже completed. Введен для того что один город не генерировал событие о своем completed больше одного раза.
Вот и я про то же. Про несложный анализ.
Слабо было добавить
// to prevent the city from being analyzed twice :???:
Тогда и "анализ" не понадобился бы. И код был бы самодокументированным.
Я за свою жизнь успел поработать на многих разных заказчиков и могу сказать, что в случае серьёзной коммерческой разработки такие шутки с самодокументированием не проходят. В приличной фирме есть quality control, который это всё отслеживает, причём строго. Давно известно, что вбивание комментариев есть не расходование, а экономия времени.
В качестве примера приведу файл, прошедший quality control в фирме, занимающейся генетикой. Заметьте, что, несмотря на хорошие имена, переменные всё же имеют описания. Например, рядом с m_cyUpperHeightMin написано // Navigation pane MIN height. Тем не менее не факт, что этот код прошёл бы в IBM или Microsoft.
Работайте. Вам ещё есть куда развиваться.
Цитата:
Originally posted by sq_deep
Вот и я про то же. Про несложный анализ.
Слабо было добавить
// to prevent the city from being analyzed twice :???:
Тогда и "анализ" не понадобился бы. И код был бы самодокументированным.
Я за свою жизнь успел поработать на многих разных заказчиков и могу сказать, что в случае серьёзной коммерческой разработки такие шутки с самодокументированием не проходят. В приличной фирме есть quality control, который это всё отслеживает, причём строго. Давно известно, что вбивание комментариев есть не расходование, а экономия времени.
В качестве примера приведу файл, прошедший quality control в фирме, занимающейся генетикой. Заметьте, что, несмотря на хорошие имена, переменные всё же имеют описания. Например, рядом с m_cyUpperHeightMin написано // Navigation pane MIN height. Тем не менее не факт, что этот код прошёл бы в IBM или Microsoft.
Работайте. Вам ещё есть куда развиваться.
Вот и я про то же. Про несложный анализ.
Слабо было добавить
// to prevent the city from being analyzed twice :???:
Тогда и "анализ" не понадобился бы. И код был бы самодокументированным.
Я за свою жизнь успел поработать на многих разных заказчиков и могу сказать, что в случае серьёзной коммерческой разработки такие шутки с самодокументированием не проходят. В приличной фирме есть quality control, который это всё отслеживает, причём строго. Давно известно, что вбивание комментариев есть не расходование, а экономия времени.
В качестве примера приведу файл, прошедший quality control в фирме, занимающейся генетикой. Заметьте, что, несмотря на хорошие имена, переменные всё же имеют описания. Например, рядом с m_cyUpperHeightMin написано // Navigation pane MIN height. Тем не менее не факт, что этот код прошёл бы в IBM или Microsoft.
Работайте. Вам ещё есть куда развиваться.
Файл (по оформлению) очень похож на исходники MFC. Именно перегруженность коментариями меня всегда и доставала. Я считаю дублирование информации в исходниках означает дублирование времени на разработку со всеми вытекающими отсюда последствиями. А если кто то не до конца прочуствовал все нюансы задачи то я не знаю... Я считаю код решения любой задачи всегда может быть очень простым и нуждаться в комментариях только как в логических разделителях текста программы.
Цитата:
Я уже писал раньше, что на вопрос какой оператор должен чаще всего использоваться в программе на любом языке? правильным ответом является "оператор комментария".
А я, однако, не соглашусь. Есть код, который достаточно просто понять, и комментировать его нужно блоками.
Кроме того, исходный текст, где комментариев больше чем самого кода читать совсем не удобно. Запутаешься, пока прокручивать будешь.
Кроме того, на разных языках комментировать код нужно по разному. Хотя есть два общих правила:
1. Комментарий должен быть кратким и емким.
2. Тривиальный код лучше не описывать, а вот объявление переменных, описание структур и классов, в также структуру баз данных, нужно описывать особенно четко.
Точняк, Mike правее правых=)ъ Я вообще ничего не комментирую:) И в конторы не рвусь ^^
Цитата:
Originally posted by Shiizoo
Точняк, Mike правее правых=)ъ Я вообще ничего не комментирую:) И в конторы не рвусь ^^
Точняк, Mike правее правых=)ъ Я вообще ничего не комментирую:) И в конторы не рвусь ^^
Ничего не комментировать нельзя. Это неуважение к себе и к своим "наследникам".
Цитата:
Originally posted by mike
А я, однако, не соглашусь. Есть код, который достаточно просто понять, и комментировать его нужно блоками.
Кроме того, исходный текст, где комментариев больше чем самого кода читать совсем не удобно. Запутаешься, пока прокручивать будешь.
Кроме того, на разных языках комментировать код нужно по разному. Хотя есть два общих правила:
1. Комментарий должен быть кратким и емким.
2. Тривиальный код лучше не описывать, а вот объявление переменных, описание структур и классов, в также структуру баз данных, нужно описывать особенно четко.
А я, однако, не соглашусь. Есть код, который достаточно просто понять, и комментировать его нужно блоками.
Кроме того, исходный текст, где комментариев больше чем самого кода читать совсем не удобно. Запутаешься, пока прокручивать будешь.
Кроме того, на разных языках комментировать код нужно по разному. Хотя есть два общих правила:
1. Комментарий должен быть кратким и емким.
2. Тривиальный код лучше не описывать, а вот объявление переменных, описание структур и классов, в также структуру баз данных, нужно описывать особенно четко.
С вашими утверждениями, mike, я по сути совершенно согласен.
Комментировать код надо блоками. Согласен.
Слишком обширные комментарии мешают. Согласен.
На разных языках надо комментировать по-разному. Разве что это относится к синтаксису, к сути — нет.
Краткость — сестра таланта. Это уже было.
Комментарий "присвоим Х значение 0" рядом с оператором "Х=0" писать не надо. Согласен.
Вводишь объект — напиши зачем. Согласен.
Однако, код, приведённый PitxBullем, абсолютно не соответствует Вашему определению, mike. Согласны?
Если знаешь ответ - не спрашивай=)ъ А-то пойдут лишние комментарии ^^ блоками-блоками;)
http://pear.php.net/manual/en/standards.sample.php - это ужасно. Я лучше на пальцах объясню человеку что/где/как или даже краткометражный документальный фильм сниму, но таким идиотизмом заниматься не буду=)ъ
http://pear.php.net/manual/en/standards.sample.php - это ужасно. Я лучше на пальцах объясню человеку что/где/как или даже краткометражный документальный фильм сниму, но таким идиотизмом заниматься не буду=)ъ
Цитата:
Originally posted by Shiizoo
http://pear.php.net/manual/en/standards.sample.php - это ужасно.
http://pear.php.net/manual/en/standards.sample.php - это ужасно.
Это не ужас, это УЖАС-УЖАС-УЖАС
Цитата:
Originally posted by Shiizoo
Если знаешь ответ - не спрашивай=)ъ А-то пойдут лишние комментарии ^^ блоками-блоками;)
http://pear.php.net/manual/en/standards.sample.php - это ужасно. Я лучше на пальцах объясню человеку что/где/как или даже краткометражный документальный фильм сниму, но таким идиотизмом заниматься не буду=)ъ
Если знаешь ответ - не спрашивай=)ъ А-то пойдут лишние комментарии ^^ блоками-блоками;)
http://pear.php.net/manual/en/standards.sample.php - это ужасно. Я лучше на пальцах объясню человеку что/где/как или даже краткометражный документальный фильм сниму, но таким идиотизмом заниматься не буду=)ъ
Это не ужасно. Это не исходник. Это документация по тому как строить файл. Стильизовано под исходник.
В свое время в моде был перевод конфига апача.
Так в том и дело, что зачастую исходники в таком виде и идут=)ъ Понимаю в perl'е POD-доки, это даже очень удобно. А все остальное хрень:) Чтобы переделать код - нужно в него вникнуть, а чтобы вникнуть необходимо его просмотреть от и до и связать это все между собой где-то в недрах черепной коробки. Назначение переменных, объектов и всего прочего это капля в море. Другое дело как это все между собой взаимосвязано, что на что влияет и почему оно это делает и делает так, а не эдак. Если все это расписать получится полноценная документация, но не писать же документации на всё и вся!! Значит.. ээ.. Всё или ничего!=)ъ Мне второе больше нравится;)
--
Вот назначение констант комментировать нужно, если конечно имена не говорящие. Может быть еще функции/методы, да и то далеко не все (опять же, кратко - бестолково, объемисто - нецелесообразно, если конечно за документацию отдельно не платят ^^).
--
Вот назначение констант комментировать нужно, если конечно имена не говорящие. Может быть еще функции/методы, да и то далеко не все (опять же, кратко - бестолково, объемисто - нецелесообразно, если конечно за документацию отдельно не платят ^^).
Ой, в общем удалите меня флудера, ну меня в пень, речи мои желчи подобны и вообще это все лень и тунеядство меня отрешаться от комментарев заставляют ^^
Цитата:
Originally posted by mike
Это не ужасно. Это не исходник. Это документация по тому как строить файл. Стильизовано под исходник.
Это не ужасно. Это не исходник. Это документация по тому как строить файл. Стильизовано под исходник.
А как вы думаете, почему Винда такая? Исходники у нее именно такие. Видели, знаем. ;)
=) это шутка такая была? ^^
Цитата:
Originally posted by Shiizoo
=) это шутка такая была? ^^
=) это шутка такая была? ^^
Абсолютно серьезно. Неспроста же ее исходники по Инету бродили.
Кстати, мое предположение подтвердилось. Я давно считал, что ее исходники должны быть именно такими, особенно после поверхностного знакомства с исходниками MFC или чего-то в этом роде - не помню уже.
Из виндового Блокнота я даже одну функцию на Дельфи портировал и в проекте применил. Кстати, так и не понял, как она работает. Просто в лоб перевел с Си на Паскаль, разбираться времени не было. А коллег за подобные макароны всегда ругаю.
мы друг друга непоняли в общем =))) я не то имел ввиду, лан, замяли=)ъ
Цитата:
Originally posted by sq_deep
Вводишь объект — напиши зачем. Согласен.
Вводишь объект — напиши зачем. Согласен.
Т. е. дай ему "говорящее" имя - я понимаю это именно так. Самодокументирующйся код - forever!
Ой, а там притглашения на gmail раздают аж с 2004-го года=) а я только недавно про gmail вообще узнал... ХЫ..
http://isnoop.net/gmail/index.php - заходим и получаем (кто еще не получал, есть такие?).
ps: куль=)ъ
http://isnoop.net/gmail/index.php - заходим и получаем (кто еще не получал, есть такие?).
ps: куль=)ъ
Цитата:
Originally posted by Freeman
А как вы думаете, почему Винда такая? Исходники у нее именно такие. Видели, знаем. ;)
А как вы думаете, почему Винда такая? Исходники у нее именно такие. Видели, знаем. ;)
Ну я бы не был столь категоричен.
Во-первых, ОС Windows слишком большой проект и исходников там много разных, в т.ч. и от других ОС, в частности от BSD.
Во-вторых, все же не комментарии являются причинами ошибок и нестабильности... На сколько мне известно, в конечный продукт они не попадают... :D
В-третих, не такая уж и плохая ОС... Вы посмотрите исходники линуха, вот уж там кто во что горазд...
Цитата:
Originally posted by Green
На сколько мне известно, в конечный продукт они не попадают...
На сколько мне известно, в конечный продукт они не попадают...
Ну, эт я фигурально. Согласись, каждый день читать подобные исходники в рамках должностных обязанностей - не сахар. Я бы не смог. Писать - вообще абзац. Убивает программистское творчество на корню.
Цитата:
Originally posted by Freeman
Ну, эт я фигурально. Согласись, каждый день читать подобные исходники в рамках должностных обязанностей - не сахар. Я бы не смог. Писать - вообще абзац. Убивает программистское творчество на корню.
Ну, эт я фигурально. Согласись, каждый день читать подобные исходники в рамках должностных обязанностей - не сахар. Я бы не смог. Писать - вообще абзац. Убивает программистское творчество на корню.
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Программистское творчество уже давно убито. В одной хорошей книге недавно прочитал примерно следующее.
В начале XX века, когда большинство людей не умело ни читать, ни писать, профессия станочника (токаря и т.п.) была очень творческой и уважаемой. Ещё бы: они умели читать не только прокламации, но даже чертежи, и это было за пределами понимания окружающих. Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
Это рассуждение легко применить к программированию.
Я ещё застал время, когда на программиста смотрели примерно так, как в книге «Понедельник начинается в субботу». Работа была весьма творческая и интересная. Сегодня проекты стали таковы, что в них заняты десятки и сотни программистов, каждый из которых делает изо дня в день одну и ту же довольно специализированную работу. Пройдёт ещё лет 10, и программирование будет окончательно поставлено на конвейер, как на заводе Форда. И тогда работа программиста будет мало отличаться от работы валяльщика валенок. Развитие в этом направлении очевидно.
Конечно, во все времена будут самородки, которые в гараже делают самолёты, но только у них всего два пути. Первый — продолжать делать самолёты в гараже в виде хобби и тратить на это свои деньги. Второй — приобретя опыт, влиться в авиастроительную корпорацию и там заняться зарабатыванием денег. Но в последнем случае они уже не будут делать самолёты, а скорее всего станут руководить теми, кто делает их малые ничего не значащие части.
Так что тут у каждого есть выбор. Либо заняться творчеством задаром, либо ерундой за деньги.
Сегодня программирование ещё сохраняет творческое начало, но по сравнению с 1980 годом его стало намного меньше. Ну а лет эдак через десяток оно совершенно потеряет престиж. Одно название останется. Вроде как доярку называют "оператором машинного доения", а продавца — "менеджером по продаже".
А потому, господа, см. subj. И выбирайте что-нибудь более творческое. А программирование можете оставить в виде хобби. Оно намного более полезно для здоровья, чем пиво и водка, и менее опасно, чем альпинизм.
точняково. я видимо еще только, но уже, делаю в гараже вилосипеды ^_^ да, как хобби программинг лучше не придумаешь. ехать никуда не нужно, денег многов вкладывать тоже (та же оракля вон для себя любимого ничего не стоит, а для бизнеса денежка уже внушительная) и остановиться, выйти из-за компа и заняться чем-то другим действительно проще, чем спуститься с Эвереста =))) Хтя, я вот потихоньку начинаю делать на этом деньги.. Но блин, может на хобби можно и деньги делать? Хотя вот до сих пор сомневаюсь, стоит ли обучаться в эту сторону, а затем и работать до седины в этой сфере. Вопрос и вправду спорный;)ъ Мож в повары пойти? В токари уже предлагали ^^ !!!!
ps: от компа зуба сыплются, это тоже положительным эффектом не назовешь:D
ps: от компа зуба сыплются, это тоже положительным эффектом не назовешь:D
Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
ОЧЕНЬ удивился бы, если бы узнал что у Вас 8-й разряд...
Ну а высказывать суждения, не разбираясь в предмете - это для кого?
Впрочем, прогнозы, конечно, имеют под собой почву, но они основаны на существующей тенденции,
которая, вообще говоря, тоже может измениться...
Ну а уж раз зашел разговор о комментариях и навигации по коду, думаю, не лишним будет вспомнить про, как мне кажется, весьма симпОтичную программку:
http://doxygen.org
ОЧЕНЬ удивился бы, если бы узнал что у Вас 8-й разряд...
Ну а высказывать суждения, не разбираясь в предмете - это для кого?
Впрочем, прогнозы, конечно, имеют под собой почву, но они основаны на существующей тенденции,
которая, вообще говоря, тоже может измениться...
Ну а уж раз зашел разговор о комментариях и навигации по коду, думаю, не лишним будет вспомнить про, как мне кажется, весьма симпОтичную программку:
http://doxygen.org
Цитата:
Originally posted by craftyfox
думаю, не лишним будет вспомнить про, как мне кажется, весьма симпОтичную программку:
http://doxygen.org
думаю, не лишним будет вспомнить про, как мне кажется, весьма симпОтичную программку:
http://doxygen.org
Программы вроде JavaDoc, не имеющие поддержки со стороны среды программирования (IDE), приносят больше вреда чем пользы. Если написания большого количества обычных комментариев можно избежать, то программы автоматического документирования исходников заставляют писать большое число служебных комментариев, делая исходники полностью нечитабельными.
Лучше, если система документирования исходников встроена в среду программирования, вроде Visual Studio или BDS.
Цитата:
Originally posted by Freeman
Программы вроде JavaDoc, не имеющие поддержки со стороны среды программирования (IDE), приносят больше вреда чем пользы. Если написания большого количества обычных комментариев можно избежать, то программы автоматического документирования исходников заставляют писать большое число служебных комментариев, делая исходники полностью нечитабельными.
Лучше, если система документирования исходников встроена в среду программирования, вроде Visual Studio или BDS.
Программы вроде JavaDoc, не имеющие поддержки со стороны среды программирования (IDE), приносят больше вреда чем пользы. Если написания большого количества обычных комментариев можно избежать, то программы автоматического документирования исходников заставляют писать большое число служебных комментариев, делая исходники полностью нечитабельными.
Лучше, если система документирования исходников встроена в среду программирования, вроде Visual Studio или BDS.
Я её ипользую (точнее, то что с помощью неё получено) для навигации по ATL+WTL (ну и для некоторых своих вещей), разумеется, ничего в исходники не добавляя: они (сами) просто перегоняются в html или chm, создаются списки
классов, class members, файлов, функций и т.п.
с соотв. ссылками.
Ну а специальные комментарии нужны только если требуется получить документацию alla MSDN, или нужно что-то пояснить (они, кстати, мало отличаются от "обычных").
Цитата:
Originally posted by sq_deep
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Бурю заказывали?! :D
Негодование не мой стиль, но и твоя "правда" не правда. Как известно идеальной (всеобщей) истины не бывает, а поэтому посмотрим с разных сторон.
К любому делу можно подойти творчески, а можно просто "тянуть лямку". Это зависит от заведеного порядка, но больше от человека.
Как пример, могу привести своего деда (прошу прощения за нескромность).
Он как раз токарь. Последнее время работал в ЛОНИИС (эти НИИ связи), до этого где-то в оборонке. На его счету штук 150 рацух и 5 патентов, он обладал личным знаком качества (т.е. его продукция не проверялась ОТК) и собственной мастерской, где стояло штук пять различных станков. Его послушать, нет ничего интереснее, чем вытачить деталь для какого-нибудь автомата бомбометания для стратегического бомбардировщика. Есть конечно оговорочка: он делал изделия в штучном количестве, но это все же профессия токаря.
Если тебя устраивает положение "чернорабочего" или тебе лень учится и повышать квалификацию(ежедневно), то "нечего пинять на зеркало...".
Если же ты по складу искатель - тогда ищи. Естественно, что энергии потребуется больше, но кто сказал, что это будет просто?
Если тебя зажимают рамки, заведенные в компании, у тебя есть два выхода: один - через отдел кадров, второй - против течения.
Я - не революционер (ну может, совсем немного), поэтому я выбрал первый путь, и работаю там, где коллектив более "живой". Мы пытаемся применять некоторые из практик XP и ( даже:) ) практикуем парное программирование.
Мне кажется, что сейчас, когда многое стало более доступным (во всех областях), люди просто стали ленивее (ну или что-то подобное) и трусливее.
Путешественников (настоящих, а не "пятизведночных") стало меньше, но не потому, что открывать и изучать стало нечего. Ребята ведь на полюсе работают, да и Конюхов бороздит просторы далеко не Большого театра.
А свое подобие лени и трусости прикрывают рутиной: "некогда", "нет денег", "надо побыстрее сделать", "некогда эксперементировать" и т.п.
Хочешь быть чернорабочим - будь им!
А я уж лучше буду искать и бороться... пусть даже с ветрянными мельницами.
Цитата:
Originally posted by sq_deep
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Программистское творчество уже давно убито. В одной хорошей книге недавно прочитал примерно следующее.
В начале XX века, когда большинство людей не умело ни читать, ни писать, профессия станочника (токаря и т.п.) была очень творческой и уважаемой. Ещё бы: они умели читать не только прокламации, но даже чертежи, и это было за пределами понимания окружающих. Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
Это рассуждение легко применить к программированию.
Я ещё застал время, когда на программиста смотрели примерно так, как в книге «Понедельник начинается в субботу». Работа была весьма творческая и интересная. Сегодня проекты стали таковы, что в них заняты десятки и сотни программистов, каждый из которых делает изо дня в день одну и ту же довольно специализированную работу. Пройдёт ещё лет 10, и программирование будет окончательно поставлено на конвейер, как на заводе Форда. И тогда работа программиста будет мало отличаться от работы валяльщика валенок. Развитие в этом направлении очевидно.
Конечно, во все времена будут самородки, которые в гараже делают самолёты, но только у них всего два пути. Первый — продолжать делать самолёты в гараже в виде хобби и тратить на это свои деньги. Второй — приобретя опыт, влиться в авиастроительную корпорацию и там заняться зарабатыванием денег. Но в последнем случае они уже не будут делать самолёты, а скорее всего станут руководить теми, кто делает их малые ничего не значащие части.
Так что тут у каждого есть выбор. Либо заняться творчеством задаром, либо ерундой за деньги.
Сегодня программирование ещё сохраняет творческое начало, но по сравнению с 1980 годом его стало намного меньше. Ну а лет эдак через десяток оно совершенно потеряет престиж. Одно название останется. Вроде как доярку называют "оператором машинного доения", а продавца — "менеджером по продаже".
А потому, господа, см. subj. И выбирайте что-нибудь более творческое. А программирование можете оставить в виде хобби. Оно намного более полезно для здоровья, чем пиво и водка, и менее опасно, чем альпинизм.
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Программистское творчество уже давно убито. В одной хорошей книге недавно прочитал примерно следующее.
В начале XX века, когда большинство людей не умело ни читать, ни писать, профессия станочника (токаря и т.п.) была очень творческой и уважаемой. Ещё бы: они умели читать не только прокламации, но даже чертежи, и это было за пределами понимания окружающих. Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
Это рассуждение легко применить к программированию.
Я ещё застал время, когда на программиста смотрели примерно так, как в книге «Понедельник начинается в субботу». Работа была весьма творческая и интересная. Сегодня проекты стали таковы, что в них заняты десятки и сотни программистов, каждый из которых делает изо дня в день одну и ту же довольно специализированную работу. Пройдёт ещё лет 10, и программирование будет окончательно поставлено на конвейер, как на заводе Форда. И тогда работа программиста будет мало отличаться от работы валяльщика валенок. Развитие в этом направлении очевидно.
Конечно, во все времена будут самородки, которые в гараже делают самолёты, но только у них всего два пути. Первый — продолжать делать самолёты в гараже в виде хобби и тратить на это свои деньги. Второй — приобретя опыт, влиться в авиастроительную корпорацию и там заняться зарабатыванием денег. Но в последнем случае они уже не будут делать самолёты, а скорее всего станут руководить теми, кто делает их малые ничего не значащие части.
Так что тут у каждого есть выбор. Либо заняться творчеством задаром, либо ерундой за деньги.
Сегодня программирование ещё сохраняет творческое начало, но по сравнению с 1980 годом его стало намного меньше. Ну а лет эдак через десяток оно совершенно потеряет престиж. Одно название останется. Вроде как доярку называют "оператором машинного доения", а продавца — "менеджером по продаже".
А потому, господа, см. subj. И выбирайте что-нибудь более творческое. А программирование можете оставить в виде хобби. Оно намного более полезно для здоровья, чем пиво и водка, и менее опасно, чем альпинизм.
Это называется Да здарствует дилетантизм!!!. Ну - ну. Вперед.
Программирование как было искуством, так им и остается. И кстати писать хороший код с хорошими коментариями это искуство. И ни какой самодокументированный код здесь не поможет. Критерий простой. Берете исходник 10 - летней давности и пробуете разобраться. Время ушедшее на "элементарный" анализ кода и есть критерий хорошо откоментированной программы.
2Green - супер. Я бы лучше не сказал
Согласен с Вами, Freeman. Один из своих проектов я делал с использованием DOC++ (по требованию заказчика, конечно, не по собственному желанию). Исходники получились практически нечитаемыми.
Пока удовлетворял бухгалтерию, буря свершилась. Но я знал, что это будет.
Я много слышал об интеллигентных слесарях, в основном в советское время. Не спорю, слесарь может быть интеллектуалом. Вот только престиж его профессии не слишком-то высок. Да и заработать этим делом не просто. Кто не согласен?
И то же самое будет с профессией программиста, причём скоро. Творчество там останется, но не более, чем в профессии слесаря.
Вы можете, конечно, со мной спорить, но, как говорил Кот Бегемот, «история нас рассудит». Причём — скоро. Уже сейчас это практически так. Поверьте, мне есть с чем сравнивать. Кто не верит, может заглянуть в моё резюме.
Я много слышал об интеллигентных слесарях, в основном в советское время. Не спорю, слесарь может быть интеллектуалом. Вот только престиж его профессии не слишком-то высок. Да и заработать этим делом не просто. Кто не согласен?
И то же самое будет с профессией программиста, причём скоро. Творчество там останется, но не более, чем в профессии слесаря.
Вы можете, конечно, со мной спорить, но, как говорил Кот Бегемот, «история нас рассудит». Причём — скоро. Уже сейчас это практически так. Поверьте, мне есть с чем сравнивать. Кто не верит, может заглянуть в моё резюме.
Цитата:
Originally posted by sq_deep
Я много слышал об интеллигентных слесарях, в основном в советское время. Не спорю, слесарь может быть интеллектуалом. Вот только престиж его профессии не слишком-то высок. Да и заработать этим делом не просто. Кто не согласен?
И то же самое будет с профессией программиста, причём скоро. Творчество там останется, но не более, чем в профессии слесаря.
Вы можете, конечно, со мной спорить, но, как говорил Кот Бегемот, «история нас рассудит». Причём — скоро. Уже сейчас это практически так. Поверьте, мне есть с чем сравнивать. Кто не верит, может заглянуть в моё резюме.
Я много слышал об интеллигентных слесарях, в основном в советское время. Не спорю, слесарь может быть интеллектуалом. Вот только престиж его профессии не слишком-то высок. Да и заработать этим делом не просто. Кто не согласен?
И то же самое будет с профессией программиста, причём скоро. Творчество там останется, но не более, чем в профессии слесаря.
Вы можете, конечно, со мной спорить, но, как говорил Кот Бегемот, «история нас рассудит». Причём — скоро. Уже сейчас это практически так. Поверьте, мне есть с чем сравнивать. Кто не верит, может заглянуть в моё резюме.
1. По поводу престижа. Самый высокий конкурс и самый престижный факультет в г. Воронеже это ПММ (специальность Программирование и администрирование Информационных систем).
2. Настоящих профессионалов (не зависимо от рода деятельности) уважают всегда и "облизывают".
3. Любая профессия позволяет заработать столько, на сколько ты умеешь делать. С Вашим подходом, и на нефтяной трубе ничего не заработаешь.
4. Моего дохода хватает мне на безбедную жизнь и возможность отдыхать там, где я желаю.
Цитата:
Originally posted by AlexandrVSmirno
Программирование как было искуством, так им и остается. И кстати писать хороший код с хорошими коментариями это искуство.
Программирование как было искуством, так им и остается. И кстати писать хороший код с хорошими коментариями это искуство.
Здесь согласен.
Как никакая "Фабрика N" не заменит музыки проверенной временем.
Цитата:
Originally posted by AlexandrVSmirno
И ни какой самодокументированный код здесь не поможет. Критерий простой. Берете исходник 10 - летней давности и пробуете разобраться. Время ушедшее на "элементарный" анализ кода и есть критерий хорошо откоментированной программы.
И ни какой самодокументированный код здесь не поможет. Критерий простой. Берете исходник 10 - летней давности и пробуете разобраться. Время ушедшее на "элементарный" анализ кода и есть критерий хорошо откоментированной программы.
Здесь не согласен.
Видимо, ты не видел самодокументированного кода.
Вот берем код (недесятилетней, но все же не новый):
Код:
bool ExportEngineImpl::processExport(const char* gsfFileName, const char* sbfFileName) {
if( !loadGSF(gsfFileName) ) {
return false;
}
processGsfRefs();
prepareDebugInfo();
prepareExporters();
registerExporters();
registerExportItemLinks();
if( !openOutputFile(sbfFileName) ) {
return false;
}
exportData();
closeOutputFile();
return true;
}
if( !loadGSF(gsfFileName) ) {
return false;
}
processGsfRefs();
prepareDebugInfo();
prepareExporters();
registerExporters();
registerExportItemLinks();
if( !openOutputFile(sbfFileName) ) {
return false;
}
exportData();
closeOutputFile();
return true;
}
Этот код не претендует на звание абсолюта самодокументации, но IMHO коментарии здесь излишни. И поверь что остальные методы в таком же стиле.
Цитата:
Originally posted by AlexandrVSmirno
Самый высокий конкурс и самый престижный факультет в г. Воронеже это ПММ (специальность Программирование и администрирование Информационных систем).
Самый высокий конкурс и самый престижный факультет в г. Воронеже это ПММ (специальность Программирование и администрирование Информационных систем).
Дело не в конкурсе, а в количестве. Если факультет каждый год набирает студентов и недобора не ощущается, не надо забывать, что скоро они станут выпускниками и пополнят собой армию программистов. Специалистами они будут разными, но из-за количества профессия программиста рано или поздно нивелируется. Разумеется престиж мастеров своего дела всегда будет, но в целом...
Программирование имеет очень важное отличие от искусства, касательно образования - при поступлении не надо выполнять задание, выявляющее талант. Соответственно, процент ремесленников от программирования достаточно высок.
Правда, еще не все так плохо. Наша отрасль быстро меняется. Возможно, через некоторое время появятся машины нового поколения, и традиционные программисты будут не нужны. А для повышения квалификации надо иметь голову. Вот и будет естественный отбор.
Цитата:
Originally posted by Green
Здесь не согласен.
Видимо, ты не видел самодокументированного кода.
Вот берем код (недесятилетней, но все же не новый):
Этот код не претендует на звание абсолюта самодокументации, но IMHO коментарии здесь излишни. И поверь что остальные методы в таком же стиле.
Здесь не согласен.
Видимо, ты не видел самодокументированного кода.
Вот берем код (недесятилетней, но все же не новый):
Код:
bool ExportEngineImpl::processExport(const char* gsfFileName, const char* sbfFileName) {
if( !loadGSF(gsfFileName) ) {
return false;
}
processGsfRefs();
prepareDebugInfo();
prepareExporters();
registerExporters();
registerExportItemLinks();
if( !openOutputFile(sbfFileName) ) {
return false;
}
exportData();
closeOutputFile();
return true;
}
if( !loadGSF(gsfFileName) ) {
return false;
}
processGsfRefs();
prepareDebugInfo();
prepareExporters();
registerExporters();
registerExportItemLinks();
if( !openOutputFile(sbfFileName) ) {
return false;
}
exportData();
closeOutputFile();
return true;
}
Этот код не претендует на звание абсолюта самодокументации, но IMHO коментарии здесь излишни. И поверь что остальные методы в таком же стиле.
Код достаточно прозрачный и вобщем приблизительно понятно, что он делает, но все-же:
1. Необходимо достаточно хорошее знание английского. Всетаки ExportEngineImpl это не очень понятно в сочетании с возращаемым bool это разрешить экспорт, или выполнить экспорт? Engine это мотор? или установка? или что?
2. Префиксы gsf и sbf не прозрачны.
Я бы всетаки несколько комментариев добавил. Но повторяюсь это на мой вкус и цвет.
Берем двух веб-девелуперов занимающихся проектами разной направленности и меняем местами. Один допустим работал с корпоративным сайтом, другой с крупной поисковой системой (ну естесно я не имею ввиду что они водиночку этим занималися, неважно чем именно ^^). Это будет, ну не столь ужасно как первый случай, но все же весьма жестоко.
Комментарии в коде за редчайшим исключением нафик не нужны, потому как если кодер не понимает того что видет, значит он не кодер, либо язык для него чужой (ну вот склад ума такой, кому C, а кому JAVA). Другое дело если предоставить общее описалово к отдельному сырцу и наверное ко всему проекту в целом. Задача, методы реализации каких-то неотъемлимых механизмов.. ну в общих чертах всего понемногу не касаясь никаких кода вообще. Вот это действительно нужно. Думаю все когда-нибудь кому-нибудь с чем-нибудь помогали (ухх). Как выглядит просьба? "Мне нужно сделать то-то, для того-то, я попробывал вот так, но не особо получилось" Открываешь сырец, думаешь, кодишь и т.д. И чем меньше кода (символов вообще, надо ж все прочитать, я к примеру читаю всегда проговаривая "про себя", не выходит у меня как Ленин учил) тем быстрее ты закончишь. Естественно в разумных пределах. Я никак не согласен с индивидумами вырезающими все "лишние" пробелы из кода. Код должен быть структуризован. И кстати не только на уровне сырцов, каждый индивидуально, но и в целом на уровне проекта. Это опять же огромный плюс к скорости интерпретации это кода программерской головешкой (думаю всем понятно, что бардак не несет с собой плюсов).
И выходит:
Если структура кода, иерархии все из этой серии выглядит должным образом,..
Если имеется четкое представления о задачи, которую этот код уже способен выполнять, или же призван это делать,..
Если самодокументирование в коде присутствует на должном уровне, но опять же НЕ ЗАШКАЛИВАЕТ,..
То, полагаю, любой кодер, чей уровень познаний достаточен для реализации полноцнного аналога, без труда в нем разберется.
ИзвинитЯ, не особо граммотно вышел план повествование, точнее его и вовсе нет. Устал седня, сплю наполовину, а ответить захотелось немедля. В общем о чем писал того и придерживаюсь. Конечно зачастую перевешивает лень (касательно ридмишек), но опять же только от того, что писать их по большей части приходится для людей далеких от программинга в любом виде, а граммотно подобрать манеру повествования довольно сложно, журналист бы из меня точно не получился бы=)ъ Все остальное должно быть, и быть должно на максимально высоком уровне.
ps: ой-ой, если попутаны падежи или запитых вообще нет, эт знач в момент написания мой брэйн активно ребутился;)
Комментарии в коде за редчайшим исключением нафик не нужны, потому как если кодер не понимает того что видет, значит он не кодер, либо язык для него чужой (ну вот склад ума такой, кому C, а кому JAVA). Другое дело если предоставить общее описалово к отдельному сырцу и наверное ко всему проекту в целом. Задача, методы реализации каких-то неотъемлимых механизмов.. ну в общих чертах всего понемногу не касаясь никаких кода вообще. Вот это действительно нужно. Думаю все когда-нибудь кому-нибудь с чем-нибудь помогали (ухх). Как выглядит просьба? "Мне нужно сделать то-то, для того-то, я попробывал вот так, но не особо получилось" Открываешь сырец, думаешь, кодишь и т.д. И чем меньше кода (символов вообще, надо ж все прочитать, я к примеру читаю всегда проговаривая "про себя", не выходит у меня как Ленин учил) тем быстрее ты закончишь. Естественно в разумных пределах. Я никак не согласен с индивидумами вырезающими все "лишние" пробелы из кода. Код должен быть структуризован. И кстати не только на уровне сырцов, каждый индивидуально, но и в целом на уровне проекта. Это опять же огромный плюс к скорости интерпретации это кода программерской головешкой (думаю всем понятно, что бардак не несет с собой плюсов).
И выходит:
Если структура кода, иерархии все из этой серии выглядит должным образом,..
Если имеется четкое представления о задачи, которую этот код уже способен выполнять, или же призван это делать,..
Если самодокументирование в коде присутствует на должном уровне, но опять же НЕ ЗАШКАЛИВАЕТ,..
То, полагаю, любой кодер, чей уровень познаний достаточен для реализации полноцнного аналога, без труда в нем разберется.
ИзвинитЯ, не особо граммотно вышел план повествование, точнее его и вовсе нет. Устал седня, сплю наполовину, а ответить захотелось немедля. В общем о чем писал того и придерживаюсь. Конечно зачастую перевешивает лень (касательно ридмишек), но опять же только от того, что писать их по большей части приходится для людей далеких от программинга в любом виде, а граммотно подобрать манеру повествования довольно сложно, журналист бы из меня точно не получился бы=)ъ Все остальное должно быть, и быть должно на максимально высоком уровне.
ps: ой-ой, если попутаны падежи или запитых вообще нет, эт знач в момент написания мой брэйн активно ребутился;)
Так-с.. Попытаюсь зарефакторить содержимое предыдущего поста.
Составляющие ПОНЯТНОГО кода/проекта:
1. Логичная систематизация, иерархия на уровне отдельно взятых исходников и проекта вцелом.
2. Чистый код, граммотное оформление и возможно логичное использование тех или иных типов/операторов/функций и т.п.
3. Достаточное и неизбыточное самодокументирование.
4. Описание содержащее четкую формулирову целей/поставленных задач, методов реализации тех или иных механизмов для каждого отдельного исходника и проекта вцелом.
По-моему всё, разве еще что-то нужно? Думаю развернутых ответов по каждому из пунктов не требуется. Это чисто мое имхо, и хочу заметить, никаких комментариев в коде я не упоминал, потому как я против этого и считаю комментирование излишней тратой времени. Есть конечно и исключения, к примеру какие-либо фиксы, не факт что человек взявшийся за модифицирование кода осведомлен о той или иной уязвимости в используемом языке, протоколе и т.д.
Всё=)ъ
added:
Нет, не всё. Забыл еще одну важную деталь - ЕДИНСТВО СТИЛЯ (тут я подразумеваю единую систему обозначений, оформления функций и т.п., полагаю у любого серьезного кодера есть своя собственная такая система, выработанная за долго время кодинга и динамично развивающаяся в ногу с развитием той сферы программирования, в которой кодер занят). Вот со мной бывало такое, когда разбирая или юзая какой-нить сырец я не мог понять, о чем говорит конкретное возвращаемое значение тем или иным методом. К примеру если в одном сырце флагом неуспешности операции считалось значение -1, то и в остальных лучше придерживаться того же стиля. Понимаю что это простая истина, но частенько убеждаюсь что все-таки не всем такой манер оформления понятен.
Составляющие ПОНЯТНОГО кода/проекта:
1. Логичная систематизация, иерархия на уровне отдельно взятых исходников и проекта вцелом.
2. Чистый код, граммотное оформление и возможно логичное использование тех или иных типов/операторов/функций и т.п.
3. Достаточное и неизбыточное самодокументирование.
4. Описание содержащее четкую формулирову целей/поставленных задач, методов реализации тех или иных механизмов для каждого отдельного исходника и проекта вцелом.
По-моему всё, разве еще что-то нужно? Думаю развернутых ответов по каждому из пунктов не требуется. Это чисто мое имхо, и хочу заметить, никаких комментариев в коде я не упоминал, потому как я против этого и считаю комментирование излишней тратой времени. Есть конечно и исключения, к примеру какие-либо фиксы, не факт что человек взявшийся за модифицирование кода осведомлен о той или иной уязвимости в используемом языке, протоколе и т.д.
Всё=)ъ
added:
Нет, не всё. Забыл еще одну важную деталь - ЕДИНСТВО СТИЛЯ (тут я подразумеваю единую систему обозначений, оформления функций и т.п., полагаю у любого серьезного кодера есть своя собственная такая система, выработанная за долго время кодинга и динамично развивающаяся в ногу с развитием той сферы программирования, в которой кодер занят). Вот со мной бывало такое, когда разбирая или юзая какой-нить сырец я не мог понять, о чем говорит конкретное возвращаемое значение тем или иным методом. К примеру если в одном сырце флагом неуспешности операции считалось значение -1, то и в остальных лучше придерживаться того же стиля. Понимаю что это простая истина, но частенько убеждаюсь что все-таки не всем такой манер оформления понятен.
Цитата:
Originally posted by sq_deep
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Программистское творчество уже давно убито. В одной хорошей книге недавно прочитал примерно следующее.
В начале XX века, когда большинство людей не умело ни читать, ни писать, профессия станочника (токаря и т.п.) была очень творческой и уважаемой. Ещё бы: они умели читать не только прокламации, но даже чертежи, и это было за пределами понимания окружающих. Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
Это рассуждение легко применить к программированию.
Я ещё застал время, когда на программиста смотрели примерно так, как в книге «Понедельник начинается в субботу». Работа была весьма творческая и интересная. Сегодня проекты стали таковы, что в них заняты десятки и сотни программистов, каждый из которых делает изо дня в день одну и ту же довольно специализированную работу. Пройдёт ещё лет 10, и программирование будет окончательно поставлено на конвейер, как на заводе Форда. И тогда работа программиста будет мало отличаться от работы валяльщика валенок. Развитие в этом направлении очевидно.
Конечно, во все времена будут самородки, которые в гараже делают самолёты, но только у них всего два пути. Первый — продолжать делать самолёты в гараже в виде хобби и тратить на это свои деньги. Второй — приобретя опыт, влиться в авиастроительную корпорацию и там заняться зарабатыванием денег. Но в последнем случае они уже не будут делать самолёты, а скорее всего станут руководить теми, кто делает их малые ничего не значащие части.
Так что тут у каждого есть выбор. Либо заняться творчеством задаром, либо ерундой за деньги.
Сегодня программирование ещё сохраняет творческое начало, но по сравнению с 1980 годом его стало намного меньше. Ну а лет эдак через десяток оно совершенно потеряет престиж. Одно название останется. Вроде как доярку называют "оператором машинного доения", а продавца — "менеджером по продаже".
А потому, господа, см. subj. И выбирайте что-нибудь более творческое. А программирование можете оставить в виде хобби. Оно намного более полезно для здоровья, чем пиво и водка, и менее опасно, чем альпинизм.
Ожидаю бурю негодования по поводу нижеследующего... однако, это правда, и никуда от этого не денешься.
Программистское творчество уже давно убито. В одной хорошей книге недавно прочитал примерно следующее.
В начале XX века, когда большинство людей не умело ни читать, ни писать, профессия станочника (токаря и т.п.) была очень творческой и уважаемой. Ещё бы: они умели читать не только прокламации, но даже чертежи, и это было за пределами понимания окружающих. Сегодня профессия токаря уже... как бы это сказать... ну, не совсем для дебилов, но близко к тому.
Это рассуждение легко применить к программированию.
Я ещё застал время, когда на программиста смотрели примерно так, как в книге «Понедельник начинается в субботу». Работа была весьма творческая и интересная. Сегодня проекты стали таковы, что в них заняты десятки и сотни программистов, каждый из которых делает изо дня в день одну и ту же довольно специализированную работу. Пройдёт ещё лет 10, и программирование будет окончательно поставлено на конвейер, как на заводе Форда. И тогда работа программиста будет мало отличаться от работы валяльщика валенок. Развитие в этом направлении очевидно.
Конечно, во все времена будут самородки, которые в гараже делают самолёты, но только у них всего два пути. Первый — продолжать делать самолёты в гараже в виде хобби и тратить на это свои деньги. Второй — приобретя опыт, влиться в авиастроительную корпорацию и там заняться зарабатыванием денег. Но в последнем случае они уже не будут делать самолёты, а скорее всего станут руководить теми, кто делает их малые ничего не значащие части.
Так что тут у каждого есть выбор. Либо заняться творчеством задаром, либо ерундой за деньги.
Сегодня программирование ещё сохраняет творческое начало, но по сравнению с 1980 годом его стало намного меньше. Ну а лет эдак через десяток оно совершенно потеряет престиж. Одно название останется. Вроде как доярку называют "оператором машинного доения", а продавца — "менеджером по продаже".
А потому, господа, см. subj. И выбирайте что-нибудь более творческое. А программирование можете оставить в виде хобби. Оно намного более полезно для здоровья, чем пиво и водка, и менее опасно, чем альпинизм.
Гмс.... приведем пример из автомобильной индустрии : кто то рабочим на конвеере закручивает гайки на серийных автомобилях для среднстатистического обывателя, а кто то в "мастерской" вручную собирает такие машины как Ferrari. Что самое интересное люди собирающие Ferrari, не любят варианты этой машины спроектированные под идиотские запросы богатых клиентов ( в частности из америки ). Тебе как разработчику коммерческого софта на заказ эта ситуация должна быть известна , но если тебе нравиться удовлетворять своего заказчика в разных позах то это ваше дело, только просьба не навязывать такую жизнненую позицию остальным. Так что каждый сам выбирает кем ему быть. А насчет коммерческого успеха софта написанного по собственной иництиаве то скоро ты убедишься в обратном, как правило именно штамповки ничего не зарабытвают, и только по настоящему творческий подход может дать сногшибательный еффект. Я счас заканчиваю собственный проект, файловый менеджер, и он однозначно будет превосходить все остальные файловые менеджеры, причем в тех местах где большиство уже уверенно что там дальше развиваться некуда. А после этого я соберу под свои знамена полчища программистов и мы пойдем войной на Microsoft и остальные корпорации построенные по западному образцу. Ура!!!!!!!!!!!!
))))))))))))))))))))))))))))))
Цитата:
Originally posted by PitxBull
и только по настоящему творческий подход может дать сногшибательный еффект.
и только по настоящему творческий подход может дать сногшибательный еффект.
В развитие моего поста про Воронежский...
Чем больше будет посредственности, тем больше будут ценить профессионалов.
Цитата:
Originally posted by Freeman
В развитие моего поста про Воронежский...
Чем больше будет посредственности, тем больше будут ценить профессионалов.
В развитие моего поста про Воронежский...
Чем больше будет посредственности, тем больше будут ценить профессионалов.
Я чето не догнал ... ты согласен со мной или нет ?
Врядли творческий подход можно охарактеризовать как посредственный:D
Вообще что спорим, дело ведь в том, что чем больше народу мы убедим в том что работая нужно включать смекалку и воображение, принимать нестандартные решения и зачастую идти против течения, тем меньше долек горбушки останется нам родимым =))) Вы уж как хотите, а я в данном контексте за развитие конвееров в ит-индустрии и помножение числа заурядных кодеров!!!
Вообще что спорим, дело ведь в том, что чем больше народу мы убедим в том что работая нужно включать смекалку и воображение, принимать нестандартные решения и зачастую идти против течения, тем меньше долек горбушки останется нам родимым =))) Вы уж как хотите, а я в данном контексте за развитие конвееров в ит-индустрии и помножение числа заурядных кодеров!!!