Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Хороший программист — это тот, кто смотрит в обе стороны, переходя дорогу с односторонним движением.
Ух ты! Всегда так делаю. Но я тестер, мне иначе и нельзя…
Мы, как тестеры, еще под ноги, вверх смотрим. Обязательно пару раз проверим, потом все равно заведем баг на то, что кирпич висит криво и надо бы перевесить.
а то не на того упадет? )
Вверх, вниз, вправо, влево, вперед и назад по временнОй оси. Ну и не забыть заглянуть в пару тройку параллельных реальностей. Тяжкий труд, за который команда вам признательна.
Тестер сначала идет.
Потом смотрит и идет.
И так далее от простого к сложному.
Пока там до «кирпича» дело дойдёт… шансов выжить в реальной жизни мало, в общем.
Потом смотрит и идет.
И так далее от простого к сложному.
Пока там до «кирпича» дело дойдёт… шансов выжить в реальной жизни мало, в общем.
Ну надеюсь поход в туалет проходит без таких долгих проверок? :)
Программист, ложась спать, ставит рядом два стакана: первый — полный, с водой; второй — пустой.
Первый на случай, если захочет пить.
Второй, если не захочет.
PS: Переходя дорогу, всегда смотрю в обе стороны
Первый на случай, если захочет пить.
Второй, если не захочет.
PS: Переходя дорогу, всегда смотрю в обе стороны
По-моему, в России почти все так делают =)
Отсюда такой процент конвертации граждан в программисты :)
В китае с переходом дороги все намного хуже чем в России
Закономерность? www.youtube.com/watch?v=RjrEQaG5jPM
Некоторые, даже переходя трамвайные пути смотрят не едет ли трамвай по встречке…
Ну, еще тогда анекдот из той же серии, раз про стаканы с водой уже написали ниже.
Салат рекурсивный: огурцы, помедоры, салат!
Теперь это анекдотпост!
Салат рекурсивный: огурцы, помедоры, салат!
Теперь это анекдотпост!
Почти всегда так делаю, но это уже привычка.
в нашей стране иначе и нельзя, а то под колёсами окажешься особо умных, которые авриечку включают и задним ходом…
В тексте у вас «шаблона MVS», поправьте пожалуйста на MVC — (Model View Controller)
Пункт 1-ый можно еще трактовать как «не бойтесь изобратеть велосипеды» =) Изобретение очередного велосипеда как раз таки помогает пощупать и понять основы.
- Получить проблему
- Найти существующее решение
- Построить свой велосипед.
- Сравнить с существующим решением
- Понять почему реализовано именно так так
- Составить список недочетов в своем велосипеде, и исправить их
- Повторить...
Так они учатся.
Но для коммерческого программирования данный алгоритм работы не проходит.
Следствие: при коммерческом программировании имеет смысл строго разделять работу и учебу или выбрать другой алгоритм обучения.
Ни то чтобы не подходит, нужно просто знать меру.
И конечно понимать, на чьей же стороне вы находитесь. Либо вы менеджер и тогда предложение потратить 2 дня на фунционал, который можно взять готовым в виде сторонней библиотеки, покажется вам кощунственной тратой бюджета. Либо вы программер и трезво оцениваете влияние вашего велосипедо-строения на сроки проекта, и по-мимо выгод для компании ищите выгоды для себя, собственного развития, собственной стоимости на рынке труда.
И конечно понимать, на чьей же стороне вы находитесь. Либо вы менеджер и тогда предложение потратить 2 дня на фунционал, который можно взять готовым в виде сторонней библиотеки, покажется вам кощунственной тратой бюджета. Либо вы программер и трезво оцениваете влияние вашего велосипедо-строения на сроки проекта, и по-мимо выгод для компании ищите выгоды для себя, собственного развития, собственной стоимости на рынке труда.
Хм… На чьей стороне…
На стороне реализуемого проекта конечно. Вне зависимости от занимаемой позиции. И как менеджер и как проектировщик и как кодировщик (ох давно было это веселое времечко) я всегда должен отдавать себе отчет, что я делаю для проекта, а что для себя.
Учусь я, скорее, для себя, решение клепаю для проекта. Эти вещи нужно очень четко разделять.
Иногда же народ путает обучение методом сравнительного велосипедостроения и реализацию функционала для проекта.
Объяснять, показывать, не действует — наказывать.
С уважением к вашему мнению.
На стороне реализуемого проекта конечно. Вне зависимости от занимаемой позиции. И как менеджер и как проектировщик и как кодировщик (ох давно было это веселое времечко) я всегда должен отдавать себе отчет, что я делаю для проекта, а что для себя.
Учусь я, скорее, для себя, решение клепаю для проекта. Эти вещи нужно очень четко разделять.
Иногда же народ путает обучение методом сравнительного велосипедостроения и реализацию функционала для проекта.
Объяснять, показывать, не действует — наказывать.
С уважением к вашему мнению.
Так было раньше. Теперь познавать основы на практике проще всего, участвуя в opensource-разработках.
Сейчас для этого есть очень удобные сайты и инструменты(github.com, bitbucket.org).
При этом вы не только изучаете, что и как устроено, но и учитесь на чужом коде.
Сейчас для этого есть очень удобные сайты и инструменты(github.com, bitbucket.org).
При этом вы не только изучаете, что и как устроено, но и учитесь на чужом коде.
Участие в OpenSource проектах — это прекрасно. Но это, как выше писалось, личное время программиста. Я считаю, что иногда не грех, работая на компанию, использовать возможности для собственного профессионального роста, в том числе и через игнорирование готовых решений и написания собственного кода… в разумных пределах, без фанатизма.
ИМХО это зависит от того, сможет ли компания использовать результаты вашего обучения в дальнейшем. Термин «иногда» подвержен очень сильному размыванию, к сожалению.
Безусловно, технари учатся и во время реализации поставленных задач. И ПМ, и архитекты, и кодеры, все. Но нужно отдавать себе отчет: «Сейчас я учусь, а вот сейчас я работаю.»
В то же время любая адекватная прогерская контора (наверное так должно быть) выделяет время на самостоятельные исследования, типа академических дней на старших курсах и в аспирантуре в советское время.
Не верное, на мой взгляд использовать контору для своего обучения, забывая что цель конторы — прибыль.
Не верно, на мой же взгляд, заставлять разработчиков пахать, как Стаханов в шахте, не давая возможности оглядеться по сторонам и не предоставляя времени на учебу
Безусловно, технари учатся и во время реализации поставленных задач. И ПМ, и архитекты, и кодеры, все. Но нужно отдавать себе отчет: «Сейчас я учусь, а вот сейчас я работаю.»
В то же время любая адекватная прогерская контора (наверное так должно быть) выделяет время на самостоятельные исследования, типа академических дней на старших курсах и в аспирантуре в советское время.
Не верное, на мой взгляд использовать контору для своего обучения, забывая что цель конторы — прибыль.
Не верно, на мой же взгляд, заставлять разработчиков пахать, как Стаханов в шахте, не давая возможности оглядеться по сторонам и не предоставляя времени на учебу
это да, но все же мысль верная — opensource проекты дают опыт в понимании чужого кода, ответственности за свой код(!), и, конечно, просто повышают скиллы. И что немаловажно — дают удовлетворение от своей работы, если твой код попал в свежий релиз
// Пошел искать какой-нить opensource-проект
// Пошел искать какой-нить opensource-проект
> Участие в OpenSource проектах — это прекрасно. Но это, как выше писалось, личное время программиста.
Это потому, что вы пишете чисто коммерческий код. Опенсорс очень часто допиливают под свои задачи, а потом выкладывают, или просто пишут, а потом выкладывают.
Это потому, что вы пишете чисто коммерческий код. Опенсорс очень часто допиливают под свои задачи, а потом выкладывают, или просто пишут, а потом выкладывают.
По поводу KISS есть хорошая цитата от Брайана Кернигана:
«Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. „
«Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. „
Спасибо за цитаты. На мой взгляд, они должны стать в коллективе правилами!
Начал автор правильно, а в конце, как мне кажется «сдал» — создалось впечатление выдумывал с головы лишь бы дотянуть количество правил до десятки. Я бы немного видоизменил и переформулировал некоторые правила. Например, изменил бы полностью 9 пункт:
9. Никогда не доверяйте документации и тем более не полагайтесь на нее. Этому правилу меня научил мой зав. кафедры xx лет назад. За мою xx летнюю карьеру это правило работало всегда и везде от мелких проектов до крупных, причем даже там, где казалось бы всё должно быть совершенно «по плану». Нифига.
Кроме того я бы изменил 10 пункт, просто потому что он совершенно не работает. Нет, не смотреть чужой код совсем — нельзя, но сформулировать можно и так:
10. Чужой код может ПЛОХОМУ научить. Самое худшее что может к вам привязаться, это чужая плохая привычка. Что я имею ввиду, любой проект всегда имеет какие-то рамки, вы не знаете, что конкретно сподвигло человека писать это и именно это. Обычно люди не пишут в комментариях — «тут ко мне подошел шеф и заставил сократил срок сдачи до завтрашнего утра, поэтому, ув. читатель моего кода, с этого момента качество моего кода немного упадет, так что учтите этот фактор при дальнейшем прочтении». Такое не пишут. По моему опыту, чем опытнее программист, тем больше он ИСПРАВЛЯЕТ в чужом коде, чем его ЧИТАЕТ. Поэтому такое правило, ну вы знаете, на ваш страх и риск.
И последнее. 7 пункт, я бы тоже изменил примерно вот так:
7. Не пугайтесь, но и в тоже время ИЗБЕГАЙТЕ быстрой смены технологий. Потому что с годами понимаешь, это ни к чему не приводит.
В целом с иными пунктами я целиком и полностью согласен с автором.
9. Никогда не доверяйте документации и тем более не полагайтесь на нее. Этому правилу меня научил мой зав. кафедры xx лет назад. За мою xx летнюю карьеру это правило работало всегда и везде от мелких проектов до крупных, причем даже там, где казалось бы всё должно быть совершенно «по плану». Нифига.
Кроме того я бы изменил 10 пункт, просто потому что он совершенно не работает. Нет, не смотреть чужой код совсем — нельзя, но сформулировать можно и так:
10. Чужой код может ПЛОХОМУ научить. Самое худшее что может к вам привязаться, это чужая плохая привычка. Что я имею ввиду, любой проект всегда имеет какие-то рамки, вы не знаете, что конкретно сподвигло человека писать это и именно это. Обычно люди не пишут в комментариях — «тут ко мне подошел шеф и заставил сократил срок сдачи до завтрашнего утра, поэтому, ув. читатель моего кода, с этого момента качество моего кода немного упадет, так что учтите этот фактор при дальнейшем прочтении». Такое не пишут. По моему опыту, чем опытнее программист, тем больше он ИСПРАВЛЯЕТ в чужом коде, чем его ЧИТАЕТ. Поэтому такое правило, ну вы знаете, на ваш страх и риск.
И последнее. 7 пункт, я бы тоже изменил примерно вот так:
7. Не пугайтесь, но и в тоже время ИЗБЕГАЙТЕ быстрой смены технологий. Потому что с годами понимаешь, это ни к чему не приводит.
В целом с иными пунктами я целиком и полностью согласен с автором.
Недоверие документации? А как тогда вообще сопровождать чужой большой проект? Я согласен, документация всегда требует беспристрастного и не догматического подхода, но обходиться без нее по принципу тотального недоверия? По мне — такое вряд ли разумно, тем более в разветвленном проекте.
Чужой код всегда поддается анализу, если только мыслить логически.
По поводу пункта 7 соглашусь: экспериментально подтвердил необходимость на шаг отставать от развития технологий с целью не участвовать во всеобщей (не всегда успешной) обкатке нового решения.
Чужой код всегда поддается анализу, если только мыслить логически.
По поводу пункта 7 соглашусь: экспериментально подтвердил необходимость на шаг отставать от развития технологий с целью не участвовать во всеобщей (не всегда успешной) обкатке нового решения.
Документация проекта и сопровождение проекта, — это две совершенно не согласуемые вещи. Документация пишется почти всегда (кто бы и чтобы не говорил) в таком аврале и в таком урезаном времени, и она может быть:
а)не актуализирована — такое случается наиболее часто в оч. больших проектах(пример то что я видел своими глазами — документация трейдинга крупнейших бирж мира, нарочно пишут ахинею, как было лет 10 назад ) — верить такой документации? У нас одна поверила, уволили, чтоб «глаза разувала чаще».
б)сделана не профессионально. Технические спецы вообще не умеют писать документы и это совсем не преувеличение. 1 на 100 умеет рисовать, 1 на тысячу умеет вставлять таблицы там где нужно структурировать, инфографику вы не найдёте вообще в документации, сделаной программистами. Я уже не говорю про простенькую типографику,- я этих «док», «вик», «спек» насмотрелся раз в 100 больше чем этот «j2ee индус с 8 годами» непонятно где.
в)не согласована. Вот бывает такое есть два документа от двух отделов на одно и то же почти. Один на вики, второй авторизованый pdf. В двух источниках — взаимоисключающая информация. Кому верить?
Какой выход? Думать всегда головой своей. Разбираться в проекте глубоко, ТЩАТЕЛЬНО взвешивать любую входную информацию, АНАЛИЗИРОВАТЬ ее. Потому что люди, которые полагаются на документацию — только потому что «я забрал ее из cvs/svn а дальше меня ничего не интересует», прикрывают сугубо свою собственную задницу(это мое имхо), и по моему опыту работу, им глубоко начхать на проект, для них главное — не взять на себя ответственность.
а)не актуализирована — такое случается наиболее часто в оч. больших проектах(пример то что я видел своими глазами — документация трейдинга крупнейших бирж мира, нарочно пишут ахинею, как было лет 10 назад ) — верить такой документации? У нас одна поверила, уволили, чтоб «глаза разувала чаще».
б)сделана не профессионально. Технические спецы вообще не умеют писать документы и это совсем не преувеличение. 1 на 100 умеет рисовать, 1 на тысячу умеет вставлять таблицы там где нужно структурировать, инфографику вы не найдёте вообще в документации, сделаной программистами. Я уже не говорю про простенькую типографику,- я этих «док», «вик», «спек» насмотрелся раз в 100 больше чем этот «j2ee индус с 8 годами» непонятно где.
в)не согласована. Вот бывает такое есть два документа от двух отделов на одно и то же почти. Один на вики, второй авторизованый pdf. В двух источниках — взаимоисключающая информация. Кому верить?
Какой выход? Думать всегда головой своей. Разбираться в проекте глубоко, ТЩАТЕЛЬНО взвешивать любую входную информацию, АНАЛИЗИРОВАТЬ ее. Потому что люди, которые полагаются на документацию — только потому что «я забрал ее из cvs/svn а дальше меня ничего не интересует», прикрывают сугубо свою собственную задницу(это мое имхо), и по моему опыту работу, им глубоко начхать на проект, для них главное — не взять на себя ответственность.
Пример относительно проблем с «актуальностью» документацией:
Не так давно (осень 2010) мы внедряли IBM WebSphere MQ на CentOS + PHP. Вроде бы всё сделали по документации, вроде всё настроили по инструкции, а вот на обещанные мощности так и не смогли выйти. Начали общаться и грузить тех поддержку. Через два часа конференции у их (IBM) программиста появляется вопрос, «А почему вы используете listener которые мы не поддерживаем с 2004 года?». Наш ответ: «Так написано в документации по настройках MQ на Linux?» Программист: «Упс… мы забыли обновить инструкцию для Linux, воспользуйтесь инструкцией для Windows Server или Solaris?»
Вывод: Документация по установки IBM WebSphere MQ на Linux в супер «актуальном» состоянии. Последние изменения были где-то в 2003-2004. Дело было осенью 2010го
Не так давно (осень 2010) мы внедряли IBM WebSphere MQ на CentOS + PHP. Вроде бы всё сделали по документации, вроде всё настроили по инструкции, а вот на обещанные мощности так и не смогли выйти. Начали общаться и грузить тех поддержку. Через два часа конференции у их (IBM) программиста появляется вопрос, «А почему вы используете listener которые мы не поддерживаем с 2004 года?». Наш ответ: «Так написано в документации по настройках MQ на Linux?» Программист: «Упс… мы забыли обновить инструкцию для Linux, воспользуйтесь инструкцией для Windows Server или Solaris?»
Вывод: Документация по установки IBM WebSphere MQ на Linux в супер «актуальном» состоянии. Последние изменения были где-то в 2003-2004. Дело было осенью 2010го
Внезапно вспомнил, что встречался с совершенно аналогичными вещами, и как раз в документации IBM по MQ!
Фраза, которая почему-то врезалась мне в память:
www.google.ru/search?&q=%22can+someone+check+the+wording+of+this+step%22
Мне кажется, круче было бы только оставить в документе Lorem Ipsum.
Чего уж говорить о прочих прелестях громадных проектов для тех, кто только пользуется их плодами. Например, о логах внутри дистрибутивов одного программного продукта от HP, а в логах чудо-даты, учетная запись с индийским именем, и имя машины, видимо, на которой этот дистрибутив и собирали.
Фраза, которая почему-то врезалась мне в память:
www.google.ru/search?&q=%22can+someone+check+the+wording+of+this+step%22
Мне кажется, круче было бы только оставить в документе Lorem Ipsum.
Чего уж говорить о прочих прелестях громадных проектов для тех, кто только пользуется их плодами. Например, о логах внутри дистрибутивов одного программного продукта от HP, а в логах чудо-даты, учетная запись с индийским именем, и имя машины, видимо, на которой этот дистрибутив и собирали.
Уу, я думал, что только мне так не повезло с IBM WebSphere MQ — месяц беспрерывного дебагинга с гуглом в обнимку — доки и примеры очень скудные.
Сделать вывод — если кто-то что-то там понял и реализовал, то его реализация продается как очень дорогое готовое решение. Маркетинг чистой воды, заставляющий программистов проталкивать IBM WebSphere MQ с целью получения выгоды!
Сделать вывод — если кто-то что-то там понял и реализовал, то его реализация продается как очень дорогое готовое решение. Маркетинг чистой воды, заставляющий программистов проталкивать IBM WebSphere MQ с целью получения выгоды!
Вам еще повезло. Я PHP к нему прикручивал, через SAM модуль. В SAMConnect всего 8 функций: connect, disconnect, send, receive, receiveAll, peak, peakAll, isDebug. И как вот с этим работать? Никакой диагностики, документации и примеров. Всё писалось в слепую.
Итог: 2 месяца разработки и внедрения, 4 месяца QA и дебагинга.
Итог: 2 месяца разработки и внедрения, 4 месяца QA и дебагинга.
А логи от WebShere как будто очень понятные. Эта вещь плодить у меня в home директории бесполезные лог файлы каждую минут. Как отключить так и не нашел :(
1. Насчёт документации: документирование всегда + в помощь к качественному коду. Имхо: преподаватели глупости говорят иногда… зачастую даже не специалисты в своей области.
2. Чужой код может научить как хорошему так и плохому, взависимости от индивидуальной восприимчивости ;). Да, и я пишу в комментах если меня «вынудили» что-то сделать… уже были прицинденты благодарности за описание написанной проблемы. — да это может плохо воспринимается заказчиком, но пока никто нежаловался.
2. Чужой код может научить как хорошему так и плохому, взависимости от индивидуальной восприимчивости ;). Да, и я пишу в комментах если меня «вынудили» что-то сделать… уже были прицинденты благодарности за описание написанной проблемы. — да это может плохо воспринимается заказчиком, но пока никто нежаловался.
хороший код сразу видно…
Соглашусь по поводу десятого пункта. Довольно долго у меня была мечта — посмотреть на действительно хороший код на C++. мечта исполнилась много лет назад, когда я посмотрел в исходники Qt. А все что я смотрел до этого делилось на две группы — ужас и тихий ужас. К чему я это? К тому, что очень сложно найти ХОРОШИЙ код, посмотрев на который можно бы было чему-то научиться.
На тему 7-ого пункта есть очередной бородатый анекдот.
Чем отличается программист с опытом работы 1 год от программиста с опытом работы 10 лет?
Программист с опытом работы 1 год: «Нет такой технологии, которую я не смогу изучить».
Программист с опытом работы 10 лет: «Нет такой технологии, без которой я не смогу обойтись».
Чем отличается программист с опытом работы 1 год от программиста с опытом работы 10 лет?
Программист с опытом работы 1 год: «Нет такой технологии, которую я не смогу изучить».
Программист с опытом работы 10 лет: «Нет такой технологии, без которой я не смогу обойтись».
11. Пользуйтесь солнцезащитными кремами. Oh, come on.
Хороший программист ИМХО должен быть талантлив не только в кодировании/программировании. Нужно множество навыков, чтобы уметь работать в коллективе, понимать важность того или иного решения, уметь анализировать и видеть далеко и глубоко. В общем, самая творческая профессия…
Да и вообще — users.livejournal.com/akme_/154221.html
Теперь количество хороших программистов значительно увеличится. Возьму на заметку!
...12. И презервативами, for additional safety.
из опыта.
1. адепты самодокументирующегося БЕЗ КОММЕНТАРИЕВ кода идут нахуй. я обладаю памятью помнить слова на страницах, которые посещал лет пять назад, и так нахожу их в гугле. так и в проекте, где несколько тысяч файлов, коммент со словами в начале файла, что он делает, позволяет найти за долю секунды поисковиком, в то время как в коде без комментов вы потратите явно больше.
2. не все подходы работают одинаково. я вот, например, с точки зрения выпускника ВМК — хрен с горы. так как по образованию инженер-робототехник. мне не читали про конечные автоматы и многое другое. с другой стороны, потом читал сам.
так вот, за счет минимализма теоретических знаний, я всегда учил других, как репетитор, и сам работаю, на основе интуиции. наш мозг — великая штука. я беру задачу, и делаю ее САМ. на бумаге. по ходу дела вырабатываю алгоритм, анализирую, как я ее решал бы.
и так получаются сложнейшие бинарные поиски и так далее.
постепенно, за счет того, что я читаю много книг, алгоритмы оседают в подсознанию, и затем всплывают, комбинируясь. но да, пипец — я программист, к которому алгоритмы приходят, как к поэту строки — за счет обращения к Силе.
3. сильные стороны — это так. у нас у всех набор рэндомных качеств, по одним мы лучше других, по другим — хуже. поэтому нет лучших и худший, если сами термины не определены однозначны. грубо говоря, математически задача «быть лучшим» не имеет смысла, но мозг этого не осознает, за счет общественных догм и предрассудков.
мое имхо — рулят итерации
— познал себя глубже
— прокачал достоинства, убрал/сгладил недостатки
— goto 1
4. программисты — одна из самых великих профессий на земле. мы и творческие люди, и ремесленники. в нашем мозгу умещаются сведения о работе компьютеров, бизнес-логики, других людей, технологиях и так далее. мы моделируем в сознании десятки объектов, в подсознании — тысячи. разбираемся в сотнях тесно связанных областей и без проблем осваиваем новое. создаем то, что облегчает жизнь другим людям, при этом имея свободу выражения как в плане реализации, так и в плане инструмента. всегда нужны, всегда востребованы, очень много путей для развития.
за нами — будущее.
1. адепты самодокументирующегося БЕЗ КОММЕНТАРИЕВ кода идут нахуй. я обладаю памятью помнить слова на страницах, которые посещал лет пять назад, и так нахожу их в гугле. так и в проекте, где несколько тысяч файлов, коммент со словами в начале файла, что он делает, позволяет найти за долю секунды поисковиком, в то время как в коде без комментов вы потратите явно больше.
2. не все подходы работают одинаково. я вот, например, с точки зрения выпускника ВМК — хрен с горы. так как по образованию инженер-робототехник. мне не читали про конечные автоматы и многое другое. с другой стороны, потом читал сам.
так вот, за счет минимализма теоретических знаний, я всегда учил других, как репетитор, и сам работаю, на основе интуиции. наш мозг — великая штука. я беру задачу, и делаю ее САМ. на бумаге. по ходу дела вырабатываю алгоритм, анализирую, как я ее решал бы.
и так получаются сложнейшие бинарные поиски и так далее.
постепенно, за счет того, что я читаю много книг, алгоритмы оседают в подсознанию, и затем всплывают, комбинируясь. но да, пипец — я программист, к которому алгоритмы приходят, как к поэту строки — за счет обращения к Силе.
3. сильные стороны — это так. у нас у всех набор рэндомных качеств, по одним мы лучше других, по другим — хуже. поэтому нет лучших и худший, если сами термины не определены однозначны. грубо говоря, математически задача «быть лучшим» не имеет смысла, но мозг этого не осознает, за счет общественных догм и предрассудков.
мое имхо — рулят итерации
— познал себя глубже
— прокачал достоинства, убрал/сгладил недостатки
— goto 1
4. программисты — одна из самых великих профессий на земле. мы и творческие люди, и ремесленники. в нашем мозгу умещаются сведения о работе компьютеров, бизнес-логики, других людей, технологиях и так далее. мы моделируем в сознании десятки объектов, в подсознании — тысячи. разбираемся в сотнях тесно связанных областей и без проблем осваиваем новое. создаем то, что облегчает жизнь другим людям, при этом имея свободу выражения как в плане реализации, так и в плане инструмента. всегда нужны, всегда востребованы, очень много путей для развития.
за нами — будущее.
1. Как-то написал просто шелл на шелле для работы с почтовиком, решил вместо документации и USAGE написать небольшую историю со стихами, знаете лучше пошло :D. Хотя да, в крупных проектах не писать доки и комменты кощунство
Кто теперь скажет что хабр не торт, пусть укусит Cord'a за блестящий металлический зад.
1. Комментарии в коде должны описывать зачем что-то делается, а не что именно делается. Что делается должно быть понятно из кода (самодокументированного).
я аж прослезился с четвертого пункта!
нет, правда, без иронии, красиво закрутил :)
нет, правда, без иронии, красиво закрутил :)
Keep it simple and short — это ужасный вариант. Простота кода в большинстве случаев гарантируется заложенной избыточностью.
Хорошее правило — не экономьте на символах.
Хорошее правило — не экономьте на символах.
вообще то я видел другой, более распространенный вариант — keep it simple, stupid… имхо оно уместнее…
Есть такая характеристика кода — «concise code». Это значит «давать много информации малым набором слов, быть кратким, но полным». Это совсем не значит писать магические однострочники, это значит лишать код лишних сущностей, которые не отвлекают от основной цели программы.
Scala по сравнению с Java — яркий пример увеличения «conciseness». При практически одинаковом подходе к программированию (в Scala все еще доминирует императивный ООП) в Scala-коде значительно меньше «шума».
Scala по сравнению с Java — яркий пример увеличения «conciseness». При практически одинаковом подходе к программированию (в Scala все еще доминирует императивный ООП) в Scala-коде значительно меньше «шума».
к чему сравнивать синтаксиса языков, при разработке это третьестепенная вещь. я, например, ненавижу синтаксис php, но пишу на нём, потому что он позволяет быстро и эффективно решать задачи.
посмотри как ты дал определение, а затем добавил избыточную информацию, чтобы её пояснить. вот и в программировании так же, если код недостаточно выразительно указывает что он делает, то нужно его отрефакторить добавив избыточности, выделить блоки в подметоды с выразительным названием и т.д.
посмотри как ты дал определение, а затем добавил избыточную информацию, чтобы её пояснить. вот и в программировании так же, если код недостаточно выразительно указывает что он делает, то нужно его отрефакторить добавив избыточности, выделить блоки в подметоды с выразительным названием и т.д.
Я сравниваю не синтаксис, а семантику. Синтаксис в понимании кода играет небольшую роль, хотя если он не однозначный и не гомогенный, то это может значительно усложнить понимание.
>> выделить блоки в подметоды с выразительным названием и т.д.
То, что ты описываешь — не избыточность, а наоборот абсолютно правильный подход. Избыточность — это когда ты используешь цикл for с переменной для того чтобы пройтись по коллекции (то есть, вводишь лишние сущности: 1) эту самую переменную 2) вызов метод взятия элемента из коллекции по индексу). Или использовать одноразовый анонимный класс, чтобы передать куда-нибудь функцию как аргумент. И так далее.
>> выделить блоки в подметоды с выразительным названием и т.д.
То, что ты описываешь — не избыточность, а наоборот абсолютно правильный подход. Избыточность — это когда ты используешь цикл for с переменной для того чтобы пройтись по коллекции (то есть, вводишь лишние сущности: 1) эту самую переменную 2) вызов метод взятия элемента из коллекции по индексу). Или использовать одноразовый анонимный класс, чтобы передать куда-нибудь функцию как аргумент. И так далее.
Не согласен! Хороший программер 5 часов — думает, 5 мин — пишет… В результате КИСС и получается.
А если не экономить на символах — то получите просто задержки в обработке. Ведь Вам самому(… как и компу...) — проще прочитать одну умную и понятную крылатую фразу, чем читать листов на тему размышлений о ней ;)
А если не экономить на символах — то получите просто задержки в обработке. Ведь Вам самому(… как и компу...) — проще прочитать одну умную и понятную крылатую фразу, чем читать листов на тему размышлений о ней ;)
учу основы, задаю вопросы, пишу простой и понятный код… один хрен программирование проносит ежедневную боль… от осознания что кучи вещей (даже простых) как бы не старался а так никогда и е осознаешь… смотрю на свой код написанный неделю, месяц, год назад и удивляюсь как хватило сил такое написать, при том что это самый примитив… а ведь люди как то ядро ведь пишут…
Насчет пункта 8 про костыли я бы поспорил. Это предложение: «всегда говори правду, но иногда можешь соврать» я бы изменил на такое: «всегда говори правду, но когда понимаешь, что лучше соврать — ври», звучит, наверное, немного цинично, но в разработке коммерческих приложений полностью себя оправдывает. Я не раз видел как поклонник метода «лучше сделать правильно и расширяемо» — проваливал сроки. Иногда, костыли, это нужная и полезная вещь. Лучше написать код который будет где-то и кривой и выпустить приложение, чем провалить сроки и упустить момент.
А почему не дали ссылку на оригинал?
Workarounds это чаще всего немного о другом — об обходе багов, недоработок и нелогичностей используемых фреймворков. Например, трудно писать на джаваскрипте, не используя костыли для обхода peculiarities зоопарка браузеров.
Обычно руководствуюсь простым правилом — делать только такие костыли, которые можно без проблем убрать, когда нижележащий фреймворк приведут в порядок.
Обычно руководствуюсь простым правилом — делать только такие костыли, которые можно без проблем убрать, когда нижележащий фреймворк приведут в порядок.
Я не программист, поэтому скажу мнение со стороны работодателя. для его самое важное качество программиста — это его умение доводить начатое до релиза в поставленные сроки. Даже если где-то код будет кривой это в дальнейшем можно поправить…
обратная сторона медали в том, что иногда сроки ставятся такие, что без костылей не обойтись.
Может я конечно и сильно ошибаюсь, но вот именно из-за таких мнений, увеличивается процент «быдлокодеров» (не нравится мне это слово, но так понятней).
По-моему, ситуация когда нужно «скорее быстро, чем качественно» должна быть исключением, а не правилом.
>Хороший программист — это тот, кто смотрит в обе стороны, переходя дорогу с односторонним движением.
Главное, чтоб не вперед и назад
Главное, чтоб не вперед и назад
я долго не работаю
Я бы озаглавил, не 10 способов стать хорошим программистом, а минимум 10 качеств необходимых для того, чтобы стать хорошим программистом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 способов стать хорошим программистом