9 фактов, которые знают программисты, и не знают все остальные

Программисты ребята прямые. Это вы еще с девушками-программистами не общались.

Цитата (YuEXP @ 9.03.2015 - 02:42)

Вот и пошли личные переписки с оскорблениями. Товарищи программисты и остальные благоразумные, призываю вас не вестись на провокации и отвечать только по существу. Либо по существу и с иронией. Цитата Факт 4 Программирование – это размышление, а не печатание

Поддерживаю. Самоирония и самокритичность - признаки хорошего программиста

А кое-кто здесь, не будем показывать пальцем, просто "быдлокодер пафосный" - он просто кю!

Цитата

1 не более чем оправдание собственных костылеориентированных велосипедов

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

По колено в коде — Говнокод.ру
http://govnokod.ru/

На любой вкус и запах!!

Цитата (vodka00121 @ 9.03.2015 - 01:59)

Цитата 1 не более чем оправдание собственных костылеориентированных велосипедов количество костылей прямопропорционально велечине проекта. винда вообще собрана костылями и кривыми руками хорошо, если просто костыли, а то сейчас говнокодингом модно заниматься

Давайте про винду не будем.. Платформа nt это самая качественная поделка от мелкософт.. Ее на критически важные системы ставить не гнушаются. А девяностопятая вЕнда, про которуюьваше утверждениетсправедливо - давным давно сдохла...

ПыСы не однократно убеждался, если nt ушла в синий экран - значить апаратура сбоит...

бля...завтра опять формошлёпить :(

Цитата (pollackj @ 9.03.2015 - 01:51)

Цитата (YuEXP @ 9.03.2015 - 02:42) Вот и пошли личные переписки с оскорблениями. Товарищи программисты и остальные благоразумные, призываю вас не вестись на провокации и отвечать только по существу. Либо по существу и с иронией. Цитата Факт 4 Программирование – это размышление, а не печатание Поддерживаю. Самоирония и самокритичность - признаки хорошего программиста А кое-кто здесь, не будем показывать пальцем, просто "быдлокодер пафосный" - он просто кю!

Поправил карму. В тему - 10-й факт: любая программа развивается, пока ее сложность не превысит способности программиста )

Некоторым строкам поражался, т.к. казалось, что _это_я_сам_говорил.

Кстати насчет решения во время сна. У меня это была сигарета выкуренная в подъезде. Т.е. я шел курить и в этот момент мне приходило решение (как правило настолько простое, что хотелось ткнуть себя по лбу).

С запретом курения в подъездах (и установкой вытяжки дома), КПД от перекура спало в разы и теперь на решения трачу куда больше времени - факт

Цитата (RomioAT03 @ 9.03.2015 - 02:15)

Почему бы не сделать простой,понятный язык програмирования ,на базе знаний современных программеров.?"забыл добавить,технологий.Програмисты,не обижайтесь,вы тоже на чьём то знании начинали работать.До вас ,по нисходящей ,до ламп.А то у вас прям секта какая то.

Хочешь офигеть от удивления? Язык запросов SQL был разработан для бухгалтеров, аналитиков и других не-технарей. Крайне понятный и простой, но эти клавы не могут запомнить десяток ключевых слов.

И еще: 11 и 12 (честно скопипастил):

Законы мира ЭВМ по Голубу
11. Неточно спланированная программа требует в три раза больше времени, чем предполагалось; тщательно спланированная - только в два раза.
12. Работающая над программой группа питает отвращение к еженедельной отчетности о достигнутых результатах, поскольку она слишком явно свидетельствует об отсутствии таковых.

Цитата

Давайте про винду не будем.. Платформа nt это самая качественная поделка от мелкософт.. Ее на критически важные системы ставить не гнушаются. А девяностопятая вЕнда, про которуюьваше утверждениетсправедливо - давным давно сдохла...

а вот вы путаете костыли и баги :)
костылей может быть много, а багов мало или вообще ноль

Еще один факт насчет костылей:

В начале программа (у нормального прогера) идеальна. В ней все, как я люблю выражаться по отношению к такому коду: "Красиво и стильно".
Такой код хочется распечатать и повесить в рамочку, ровно так же, как другие вешают картины известных художников (вы находите их прекрасными и гармоничными, мы находим прекрасным и гармоничным тот код, к которому нельзя при@баться в плане разумности и форматирования).
Но вернемся к костылям и косякам... они появляются в 2х случаях:
1. Смена ТЗ заказчика или дополнение
2. Выпуск новой версии, особенно когда выпущено уже с 10 обновлений (в процессе обновлений, любой код "из рамочки" требует доработки для поддержки оных). Кто то даже говорил, что при выходе новой версии проги, исправляют 2 ошибки, но 10 появляются (пусть и не всегда и не сразу заметные).

Цитата (grably @ 9.03.2015 - 00:20)

Цитата (adm1nb3k @ 8.03.2015 - 23:05) «Родитель» может убить своих «детей», если их задача выполнена О, это я помню у нас ещё преподаватель ржал, что в программировании эти обороты безобидны, что тут не биология! зы: картинко

А как же "у меня мать сдохла, я из неё мозги вытащил и на помойку выкинул"?

Цитата (vodka00121 @ 9.03.2015 - 02:15)

Цитата Давайте про винду не будем.. Платформа nt это самая качественная поделка от мелкософт.. Ее на критически важные системы ставить не гнушаются. А девяностопятая вЕнда, про которуюьваше утверждениетсправедливо - давным давно сдохла... а вот вы путаете костыли и баги :) костылей может быть много, а багов мало или вообще ноль

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

Цитата (AlKoyot @ 9.03.2015 - 02:29)

Цитата (apprico @ 9.03.2015 - 01:20) Потому что деды говнокодят в точном соответствии с ТЗ... А ты - из лени и непонимания поставленных задач  Истинная правда. С некоторых пор взял за правило, после написания, разбирать ТЗ с разрабом. Все ли я правильно написал, нигде ли херни не сморозил? Другой вопрос, если кодер видит, что ТЗ некорректно или какой-то пункт можно двояко понять, то почему он вопрос сразу не задаст?

Потому что программист не телепат. 95% задач с которыми сталкиваешься - новые. Они либо новые по части технологий, либо новые по части своей логики, либо новые по части интеграции с существующими технлогиями\кодом.
К тому же ТЗ это не смета на готовый проект дома. ТЗ это что-то типа "а не забубените ли вы мне свой летательный аппарат. Я пока не знаю, как он должен летать, но точно лучше чем вот тот у Джона".
ТЗ вообще должен составлять только технический специалист, т.е. программист.
Вот некую пред-ТЗ, т.е. список хотелок в духе "хочу чтобы кнопочка была и табличка появлялся" - это да, это кто угодно. Но потом все равно тех. спец.
А лучше SCRUM и прототипирование. Эффективнее получается: дороже вначале, дешевле в итоге.

Это сообщение отредактировал artivenom - 9 мар 2015 в 03:02

Ой, тут перепись красноглазиков? Ну, тады принимайте и меня в свои ряды))

Цитата (Garret @ 9.03.2015 - 02:16)

Еще один факт насчет костылей: В начале программа (у нормального прогера) идеальна. В ней все, как я люблю выражаться по отношению к такому коду: "Красиво и стильно". Такой код хочется распечатать и повесить в рамочку, ровно так же, как другие вешают картины известных художников (вы находите их прекрасными и гармоничными, мы находим прекрасным и гармоничным тот код, к которому нельзя при@баться в плане разумности и форматирования). Но вернемся к костылям и косякам... они появляются в 2х случаях: 1. Смена ТЗ заказчика или дополнение 2. Выпуск новой версии, особенно когда выпущено уже с 10 обновлений (в процессе обновлений, любой код "из рамочки" требует доработки для поддержки оных). Кто то даже говорил, что при выходе новой версии проги, исправляют 2 ошибки, но 10 появляются (пусть и не всегда и не сразу заметные).

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

Самое главное от макконела:
13. Пиши код так, словно с ним будет работать программист-садист и маньяк, который знает где ты живёшь.

Цитата (artivenom @ 9.03.2015 - 02:19)

Самое главное от макконела: 13. Пиши код так, словно с ним будет работать программист-садист и маньяк, который знает где ты живёшь.

Вот с этим утверждением всегда был согласен! Это надо на лбу у всех "молодо-зелено" выжигать! )))

Цитата (ipv4 @ 9.03.2015 - 06:19)

Цитата (Garret @ 9.03.2015 - 02:16) Еще один факт насчет костылей: В начале программа (у нормального прогера) идеальна. В ней все, как я люблю выражаться по отношению к такому коду: "Красиво и стильно". Такой код хочется распечатать и повесить в рамочку, ровно так же, как другие вешают картины известных художников (вы находите их прекрасными и гармоничными, мы находим прекрасным и гармоничным тот код, к которому нельзя при@баться в плане разумности и форматирования). Но вернемся к костылям и косякам... они появляются в 2х случаях: 1. Смена ТЗ заказчика или дополнение 2. Выпуск новой версии, особенно когда выпущено уже с 10 обновлений (в процессе обновлений, любой код "из рамочки" требует доработки для поддержки оных). Кто то даже говорил, что при выходе новой версии проги, исправляют 2 ошибки, но 10 появляются (пусть и не всегда и не сразу заметные). С 2 - не совсем согласен. Имхо, правильная архитектура выдерживает довольно много модернизаций без необходимости лепить костыли и, когда они появляются, это является показателем для рефэкторинга или редизайна.

Поэтому я и говорю, что после десятка обновлений лезут костыли пачками (сначала один "Ладно хрен с ним", а потом как лавина).
Точка отсчета (версия) появления костылей зависит от гибкости (продуманности) изначального кода и вносимых обновлений (всего предусмотреть на этапе разработки ядра невозможно).

Цитата (ipv4 @ 9.03.2015 - 03:19)

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

Маленькая поправочка, показателем для проведения рефакторинга всегда являются 2 вещи:
1. Новая задача (любых размеров)
2. Новый найденный баг.
Выполняется одно из этих условий - делать рефакторинг. Тогда это быстро и небольно.

-папа, а почему солнышко встает каждый день с одной и той же стороны?
-каждый день сынок?
-да папа.
- ничего не трогай в коде сына!
Это сообщение отредактировал kwachboba - 9 мар 2015 в 02:28

Цитата (artivenom @ 9.03.2015 - 02:23)

Цитата (ipv4 @ 9.03.2015 - 03:19) С 2 - не совсем согласен. Имхо, правильная архитектура выдерживает довольно много модернизаций без необходимости лепить костыли и, когда они появляются, это является показателем для рефэкторинга или редизайна. Маленькая поправочка, показателем для проведения рефакторинга всегда являются 2 вещи: 1. Новая задача (любых размеров) 2. Новый найденный баг. Выполняется одно из этих условий - делать рефакторинг. Тогда это быстро и небольно.

1. Далеко не всегда. Если архитектура предназначена для решения данного класса задач, то необходимости рефэкторинга нет.
2. Баги бывают разные (жидкие и газообразные, ога) - далеко не каждая ошибка является признаком неправильно спроектированного кода. )))
Это сообщение отредактировал ipv4 - 9 мар 2015 в 02:34

Цитата (kwachboba @ 9.03.2015 - 02:26)

-папа, а почему солнышко встает каждый день с одной и той же стороны? -каждый день сынок? -да папа. - ничего не трогай в коде сына!

программист сегодня никто - в данном случае сына и аналитик и двигатель прогресса, и генератор идей
ЗЫ мы так, швея мотористка

Цитата (ipv4 @ 9.03.2015 - 03:33)

Цитата (artivenom @ 9.03.2015 - 02:23) Цитата (ipv4 @ 9.03.2015 - 03:19) С 2 - не совсем согласен. Имхо, правильная архитектура выдерживает довольно много модернизаций без необходимости лепить костыли и, когда они появляются, это является показателем для рефэкторинга или редизайна. Маленькая поправочка, показателем для проведения рефакторинга всегда являются 2 вещи: 1. Новая задача (любых размеров) 2. Новый найденный баг. Выполняется одно из этих условий - делать рефакторинг. Тогда это быстро и небольно. 1. Далеко не всегда. Если архитектура предназначена для решения данного класса задач, то необходимости рефэкторинга нет. 2. Баги бывают разные (жидкие и газообразные, ога) - далеко не каждая ошибка является признаком неправильно спроектированного кода. )))

Всегда.
Другое дело, что об этом не много кто читал и знает, и потому "свой любимый велосипед продолжает толкать по льду".
Необходимость рефакторинга не может ограничиваться архитектурой решения.
Сама цель рефакторинга - уменьшение количества ошибок совершённых в дальнейшем (возможно др. людьми) за счет увеличения качества кода:
легкой читаемости, простоты понимания, однозначности трактовки, правильного именования, применения правильных шаблонов и типовых решений и т.д. Рефакторинг это не значит, что обязательно менять архитектуру, это менять код, приводя его к более ясному виду с уменьшением связанности.
газообразные жучки? Это что-то новенькое....
Про баги это демагогия. Будет конкретный пример - будет о чем говорить. У программистов баги это причина плохо написанного кода или архитектуры решения.
Это сообщение отредактировал artivenom - 9 мар 2015 в 03:03