Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 187
И правда «Десять заповедей разработчика»
Ахаха насмешил=)
оО нас учать прогать?) Третий курс а я все не заметил…
Другой ВМКшник=)
оО нас учать прогать?) Третий курс а я все не заметил…
Другой ВМКшник=)
По сути практика, лучшее образование! Я не ошибаюсь?!
В первую очередь ВУЗ учит читать маны, и если за 5 лет человек не научился читать книги, то никакая практика ему не поможет.
Ну серьезно, как можно такое утверждать? 5 лет учить читать?
дада, я слышал исповеди бывших студентов — «меня мой ВУЗ научил учиться» — бросьте, скажите честно — «5 лет здесь был, чему учили — не помню, но выкручиваться я умею в принципе.».
в наше время в РФ вузах ничему не учат в 95% времени — бесполезная трата времени.
я его(ВУЗ) провел тем что писал на КПК в блокноте код, который потом, кстати, обычно работал =)
а после диплома пошел заниматься тем, чему сам научился — создавать игры.
дада, я слышал исповеди бывших студентов — «меня мой ВУЗ научил учиться» — бросьте, скажите честно — «5 лет здесь был, чему учили — не помню, но выкручиваться я умею в принципе.».
в наше время в РФ вузах ничему не учат в 95% времени — бесполезная трата времени.
я его(ВУЗ) провел тем что писал на КПК в блокноте код, который потом, кстати, обычно работал =)
а после диплома пошел заниматься тем, чему сам научился — создавать игры.
В том то и дело, что ТЫ научился, а не тебя научили в Вузе. Однако есть куча людей, которые просто плывут по течению, они закончили школу, пошли в универ, закончили его, может и с хорошими оценками. А дальше пошли работать куда прийдется. И если под конец обучения человек не понял, что и после окончания вуза надо продолжать учиться, самосовершенствоваться и идти дальше, то он так и будет до конца своих дней работать админом в комп. клубе или клепать гавносайты за копейки.
Умение программировать дает во-первых желание этим заниматься и, во-вторых отсутствие ошибок сами знаете в чем
«Практика без теории слепа, а теория без практики мертва...» (Кант, если не ошибаюсь)
это не проблема, это главное отличие ВУЗа от ПТУ
странно… неужели там что-то изменилось с конца 90-х? :)
а значит, 4му пункту — нет? :)
А вот мне не хочется =) Я не крутой программист, но мне вседаки кажется, что автор (конечно, автор оригинальной статьи, и я обращаюсь к нему =) этой статьи в чем-то не прав, или выступает в роли кэпа. Позвольте пару комментариев:
Любой так называемый «открывающий глаза пост», обязательно должен смешать программиста с говном. Без этого никак. Абсолютно бесполезное и временами даже вредное утверждение. Очевидно, что не стоит думать, что ты прав и не слушать никого (и штука, в том, что это касается не только программистов) — вот только, зачем писать об этом каждый раз? Высокое эго у программистов? Да ладно вам… любой, кто имеет хоть минимальный опыт, уже знает, что он не господь бог.
А все, что может испортиться, испортится. Хорошие утверждение, вот только очень общее, и поэтому практически бесполезное. Даже вот не знаю, что еще сказать =) Здорово, вы так задвинули, по философски =) Можно наверно сказать, что вредно думать обо всем, что может сломаться, ибо не так и важно нам это «все». Нам важно, чтобы ниче не сломалось, на данном нам уровне абстракции. Остальное мы не тестируем, и никак не можем (и хотим ли?) на это повлиять. Мы, по умолчанию, принимаем то, что куча вещей не может испортится (что противоречит исходному утверждению =), и что более важно, как привило, это недалеко от истины. Если непонятно, то я имею ввиду: вряд ли кто-то программируя на PHP, заботится о том, как сетевая карта посылает туда сюда пакеты, возникают ли там ошибки, и как их исправлять.
Нет, не весь. Если весь ваш код говно — вы хреновый программист. Код перестает быть говном, как только программист говорит, что-то вроде: «Да вот, тут, и там, и здесь я лажанулся, но это можно исправить». Т.е когда не приходится переписывать всю программу заново(т.е. система очень грамотно разбита на модули). Мне кажется, что вседаки есть очень большая разница м/у дерьмовым кодом и не дерьмовым. На мой взгляд она принципиальна — хороший можно изменять, расширить и улучшать, а не переписывать.
Ну вряд ли бесконечное. Я тоже где-то в книжке это видел, но число ошибок точно конечно(хотя в больших программах, оно наверно настолько большое, что можно смело считать его бесконечным). Ну тут ведь тоже не все так просто, могут быть ошибки в методе, классе, модуле, или в интеграции модулей. И вот ошибок в методе, уже точно не может быть бесконечно много. Мне кажется корректней было бы утверждать, что шанс того, что в программе есть ошибка всегда не равен нулю =) Весь вопрос в том, чтобы сделать так, что этот шанс -> 0. И еще было бы круто, еслиб мы знали, где именно может возникнуть ошибка, и могли оценить ее значимость. Вот в винде и других ОС бесконечно возникают ошибки. И что? Всем плевать, ибо они ну ОЧЕНЬ редко выводят систему из строя (особенно в «других ОС»). Не стоит бояться, этого мифического «бесконечного числа ошибок», на самом деле это не так (чтобы меня не запинали, это конечно так, но всем пофиг =) В программе, конечно, что-то может пойти не так, но можно сделать так, чтобы ошибка скорее возникала в каком-то определенном месте, а не где-то в программе, и так же (что важно) можно на эту ошибку среагировать и восстановить программу.
Да, клиенту на это вообще плевать. Но, вот что забавно, ему будет не плевать, когда проект провалиться, из-за того что вы не использовали, современные методики/средства и пр. Программисты не пишут на асм, не из-за клиента, а из-за себя. Ведь именно им потом со всем этим работать. Технологии очень сильно влияют на продукт, и то что клиент этого не понимает (ему нет непосредственной или мгновенной пользы от этого) не должно играть никакой роли при их использовании.
Да и проще тоже — лучше =) Я не совсем понимаю этого тезиса, что имеют ввиду автор? Что не стоит заранее писать расширенную функциональность? Мб не стоит усложнять код? Или не стоит писать лишний (sic!) код? Не стоит предсказывать все возможные случаи? Тогда, да, пожалуй, всего этого делать не стоит =)
Да, заказчики, очень любят послушать программистское исполнение роли Гамлета. Главная задача программиста — писать код ( ну и кончено «отладку, тестирование», обсуждение). Общение с заказчиками, вряд ли требуется от рядового программиста (тут конечно тоже много нюансов, но лучше бы программисту общаться только с другим программистами). Вообще, мне кажется, что порой к программисту предъявляют слишком много требований, не удивительно, что по некоторым из них он не подходит (поэтому в больших проектах, роли всегда достаточно хорошо разделены, и никто не требует от программистов всего).
Да, поэтому и передумывают всякие методы разработки. Моглибы упомянуть об этом. Заказчик как и любой другой человек не может предсказать всего. Проект оживает, и когда заказчик это видит, вполне естественно, что в живую у заказчика сформировывается более точное и правильное мнение, как должна работать та, или иная функция. Т.е он как-бы смотрит: ага да вот оно как на самом дело-то будет, и думает, а точно ли он именно это хотел (заказчик со временем лучше узнает проект). Это раздражает, но от этого наверно нельзя уйти =)
Точно, и написано уже миллион раз. Но этот полюбому особенный.
1. Мы не правы
Любой так называемый «открывающий глаза пост», обязательно должен смешать программиста с говном. Без этого никак. Абсолютно бесполезное и временами даже вредное утверждение. Очевидно, что не стоит думать, что ты прав и не слушать никого (и штука, в том, что это касается не только программистов) — вот только, зачем писать об этом каждый раз? Высокое эго у программистов? Да ладно вам… любой, кто имеет хоть минимальный опыт, уже знает, что он не господь бог.
2. Все, что может сломаться, ломается
А все, что может испортиться, испортится. Хорошие утверждение, вот только очень общее, и поэтому практически бесполезное. Даже вот не знаю, что еще сказать =) Здорово, вы так задвинули, по философски =) Можно наверно сказать, что вредно думать обо всем, что может сломаться, ибо не так и важно нам это «все». Нам важно, чтобы ниче не сломалось, на данном нам уровне абстракции. Остальное мы не тестируем, и никак не можем (и хотим ли?) на это повлиять. Мы, по умолчанию, принимаем то, что куча вещей не может испортится (что противоречит исходному утверждению =), и что более важно, как привило, это недалеко от истины. Если непонятно, то я имею ввиду: вряд ли кто-то программируя на PHP, заботится о том, как сетевая карта посылает туда сюда пакеты, возникают ли там ошибки, и как их исправлять.
3. Весь код — дерьмо
Нет, не весь. Если весь ваш код говно — вы хреновый программист. Код перестает быть говном, как только программист говорит, что-то вроде: «Да вот, тут, и там, и здесь я лажанулся, но это можно исправить». Т.е когда не приходится переписывать всю программу заново(т.е. система очень грамотно разбита на модули). Мне кажется, что вседаки есть очень большая разница м/у дерьмовым кодом и не дерьмовым. На мой взгляд она принципиальна — хороший можно изменять, расширить и улучшать, а не переписывать.
4. В программе всегда есть баг
Ну вряд ли бесконечное. Я тоже где-то в книжке это видел, но число ошибок точно конечно(хотя в больших программах, оно наверно настолько большое, что можно смело считать его бесконечным). Ну тут ведь тоже не все так просто, могут быть ошибки в методе, классе, модуле, или в интеграции модулей. И вот ошибок в методе, уже точно не может быть бесконечно много. Мне кажется корректней было бы утверждать, что шанс того, что в программе есть ошибка всегда не равен нулю =) Весь вопрос в том, чтобы сделать так, что этот шанс -> 0. И еще было бы круто, еслиб мы знали, где именно может возникнуть ошибка, и могли оценить ее значимость. Вот в винде и других ОС бесконечно возникают ошибки. И что? Всем плевать, ибо они ну ОЧЕНЬ редко выводят систему из строя (особенно в «других ОС»). Не стоит бояться, этого мифического «бесконечного числа ошибок», на самом деле это не так (чтобы меня не запинали, это конечно так, но всем пофиг =) В программе, конечно, что-то может пойти не так, но можно сделать так, чтобы ошибка скорее возникала в каком-то определенном месте, а не где-то в программе, и так же (что важно) можно на эту ошибку среагировать и восстановить программу.
5. Наиболее важная вещь — это клиент
Да, клиенту на это вообще плевать. Но, вот что забавно, ему будет не плевать, когда проект провалиться, из-за того что вы не использовали, современные методики/средства и пр. Программисты не пишут на асм, не из-за клиента, а из-за себя. Ведь именно им потом со всем этим работать. Технологии очень сильно влияют на продукт, и то что клиент этого не понимает (ему нет непосредственной или мгновенной пользы от этого) не должно играть никакой роли при их использовании.
7. Меньше — лучше
Да и проще тоже — лучше =) Я не совсем понимаю этого тезиса, что имеют ввиду автор? Что не стоит заранее писать расширенную функциональность? Мб не стоит усложнять код? Или не стоит писать лишний (sic!) код? Не стоит предсказывать все возможные случаи? Тогда, да, пожалуй, всего этого делать не стоит =)
8. Кодирование занимает 20% времени
Да, заказчики, очень любят послушать программистское исполнение роли Гамлета. Главная задача программиста — писать код ( ну и кончено «отладку, тестирование», обсуждение). Общение с заказчиками, вряд ли требуется от рядового программиста (тут конечно тоже много нюансов, но лучше бы программисту общаться только с другим программистами). Вообще, мне кажется, что порой к программисту предъявляют слишком много требований, не удивительно, что по некоторым из них он не подходит (поэтому в больших проектах, роли всегда достаточно хорошо разделены, и никто не требует от программистов всего).
9. Заказчик НИКОГДА не знает, что он хочет
Да, поэтому и передумывают всякие методы разработки. Моглибы упомянуть об этом. Заказчик как и любой другой человек не может предсказать всего. Проект оживает, и когда заказчик это видит, вполне естественно, что в живую у заказчика сформировывается более точное и правильное мнение, как должна работать та, или иная функция. Т.е он как-бы смотрит: ага да вот оно как на самом дело-то будет, и думает, а точно ли он именно это хотел (заказчик со временем лучше узнает проект). Это раздражает, но от этого наверно нельзя уйти =)
10. Кто-то это уже делал
Точно, и написано уже миллион раз. Но этот полюбому особенный.
Поставил плюс за:
Точно, и написано уже миллион раз. Но этот полюбому особенный.
Точно, и написано уже миллион раз. Но этот полюбому особенный.
Нет, не весь. Если весь ваш код говно — вы хреновый программист.
Если Вы открываете свой код годовалой давности и не говорите: «Этот код — говно», Вы плохой программист.
Опять таки, если вы можете улучшить код годовалой давности, а не переписать проект заново, то это на мой взгляд не такой уж и плохой код. Да он не идеальный, и вы можете его улучшить, но это не тоже самое, что «весь код дерьмо». Часть кода уродлива, но в целом проект логичен, и поэтому поддаются расширению, улучшению и изменению.
Я открываю свой код шестилетней давности, пускаю скупую слезу и думаю: «Вашу мать! Шесть лет назад мы в два рыла с нуля нахерачили код, который до сих пор безукоризненно работает и который хочется использовать снова и снова!»
Не всегда.
На самом деле данное суждение зависит от множества факторов. Сразу предупреждаю, список неполный, перечислю то, что сразу приходит в голову.
Факторы:
1) Динамичность проекта. Если после написания кода прошел год и логика приложения и/или предметной области к тому времени существенно поменялась (требования заказчика изменились/расширились), то код конечно же будет некорректным, т.к. он не будет отражать существующего порядка. Тем не менее на момент написания он мог быть очень хорошим кодом.
2) Участие в проекте нескольких разработчиков. При этом каждый разработчик отчетливо представляет себе только часть системы. Вероятность внесения ошибок на границе ответственности довольно велика, и в итоге код со временем уже не справляется с поставленными перед ним задачами. Хотя в момент его написания все опять же могло быть хорошо.
X) Длительное отсутствие рефакторинга. Этот пункт излагается в конце, т.к. перед ним излагаются предпосылки, но по значимости он должен стоять в начале. Отсутствие рефакторинга приводит к тому, что со временем влияние вышеперечисленных факторов возрастает, и в конце-концов приводит к ужасному коду.
Перед пунктом X можно понаписать еще кучу причин, я назвал основные. Например, недостаточная квалификация отдельных разработчиков, невнимательность, реализация частных случаев вместо общих и т.д.
P.S. Те же причины приводят не только к говнокоду (что не хорошо, но терпимо), но и к появлению ошибок в программе, что гораздо более печально с точки зрения заказчика.
Напоследок приведу хорошую аналогию. Есть в комнате долго не делать уборку, то даже если там никто ничего не будет трогать, рано или поздно там станет настолько грязно, что противно будет зайти =)
На самом деле данное суждение зависит от множества факторов. Сразу предупреждаю, список неполный, перечислю то, что сразу приходит в голову.
Факторы:
1) Динамичность проекта. Если после написания кода прошел год и логика приложения и/или предметной области к тому времени существенно поменялась (требования заказчика изменились/расширились), то код конечно же будет некорректным, т.к. он не будет отражать существующего порядка. Тем не менее на момент написания он мог быть очень хорошим кодом.
2) Участие в проекте нескольких разработчиков. При этом каждый разработчик отчетливо представляет себе только часть системы. Вероятность внесения ошибок на границе ответственности довольно велика, и в итоге код со временем уже не справляется с поставленными перед ним задачами. Хотя в момент его написания все опять же могло быть хорошо.
X) Длительное отсутствие рефакторинга. Этот пункт излагается в конце, т.к. перед ним излагаются предпосылки, но по значимости он должен стоять в начале. Отсутствие рефакторинга приводит к тому, что со временем влияние вышеперечисленных факторов возрастает, и в конце-концов приводит к ужасному коду.
Перед пунктом X можно понаписать еще кучу причин, я назвал основные. Например, недостаточная квалификация отдельных разработчиков, невнимательность, реализация частных случаев вместо общих и т.д.
P.S. Те же причины приводят не только к говнокоду (что не хорошо, но терпимо), но и к появлению ошибок в программе, что гораздо более печально с точки зрения заказчика.
Напоследок приведу хорошую аналогию. Есть в комнате долго не делать уборку, то даже если там никто ничего не будет трогать, рано или поздно там станет настолько грязно, что противно будет зайти =)
Ну если за этот год Вы выросли как программист, то вполне вероятно, что по сравнению с текущими навыками тот код — говно :)
А философские тексты вы так же критикуете? =)
Сколько людей — столько и мнений. Кроме того, не забывайте, что автор живёт несколько в другой стране с другим менталитетом и несколько иным подходом к работе в принципе.
Сколько людей — столько и мнений. Кроме того, не забывайте, что автор живёт несколько в другой стране с другим менталитетом и несколько иным подходом к работе в принципе.
2. Все, что может сломаться, ломается
4. В программе всегда есть баг
6. Программа, изложенная на бумаге не работает
7. Меньше — лучше
Отправил как-то нечаянно.
Хотел сказать, что перечисленное нам преподавали в университете)
А вот многого другого – нет…
Хотел сказать, что перечисленное нам преподавали в университете)
А вот многого другого – нет…
6. Программа, изложенная на бумаге не работает
а мы экзамен по ассемблеру сдавали путем написания программы на бумажках
а мы экзамен по ассемблеру сдавали путем написания программы на бумажках
А мы на компах, переписывая с шпор которые сделали с лекций :)
И не работали, приходилось допиливать, а те кто не вкуривал по настоящему — впирался -))
И не работали, приходилось допиливать, а те кто не вкуривал по настоящему — впирался -))
2010 год, Радиофак УПИ. Экзамен по С++ сдаётся на бумажках.
Программирование нельзя выучить в школе или университете. Его истину можно познать лишь погрузившись с головою в этот огромный мир, полный чудес! :)
Программирование нельзя выучить в школе или университете. Его истину можно познать лишь погрузившись с головою в этот огромный мир, полный чудес! :)
девочка моя ты все уроки сделала уже?
Если ты не знаешь как преподу изложить алгоритм на бумаге может тебе погрузится лучше в прекрасный мир менеджеров?
Чудес там тоже навалом…
Если ты не знаешь как преподу изложить алгоритм на бумаге может тебе погрузится лучше в прекрасный мир менеджеров?
Чудес там тоже навалом…
Все же листики — это классная вещь, в блокноте можно много всего крутого нарисовать, от мокапа до прототипа, диаграммки дизайна, или просто почирикать для снятия напряжения :)
Для написания хорошего ОО-кода самым удачным вариантом будет использование UML, и тут нам листик снова может прийти на помощь :)
Вы забываете про диаграмму компонентов, которой можно показать дополнительные связи, а так же диаграммы последовательности и состояний, в которых можно один в один передать весь нужный код.
Другое дело, если экзамен по языку, а не по программированию, тогда преподавателям действительно будет нужен код :)
Другое дело, если экзамен по языку, а не по программированию, тогда преподавателям действительно будет нужен код :)
Доктор Кокс стайл?)
что из себя представлял экзамен? какие задачи были — от этого многое зависит
сам не люблю писать на бумажке, особенно в ООП программировании, но вот например просчитать какой-то немного сложный алгоритм — это стоит на бумаге
а насчёт универа, опять же повторюсь всё зависит от задачи и экзамена
понятное дело что например писать html, css, php код или какие-то большие описания классов в том же C++ на бумаге — бред
сам не люблю писать на бумажке, особенно в ООП программировании, но вот например просчитать какой-то немного сложный алгоритм — это стоит на бумаге
а насчёт универа, опять же повторюсь всё зависит от задачи и экзамена
понятное дело что например писать html, css, php код или какие-то большие описания классов в том же C++ на бумаге — бред
Задания, конечно, простиые были. Но это было бы нормально, если бы обучали хорошо и правильно, а не всё в куче довали, объясняя тему «Адреса и указатели» за пять минут. К тому же готовят не программистов, а радиоэлектронщиков.
Сам я баловался на бумажках. Во время скучной лекции как-то написал алгоритм расчёта площади и объёма фигуры заданных размеров из кубиков: festival.1september.ru/files/articles/52/5263/526312/img5.jpg (центральная).
Сам я баловался на бумажках. Во время скучной лекции как-то написал алгоритм расчёта площади и объёма фигуры заданных размеров из кубиков: festival.1september.ru/files/articles/52/5263/526312/img5.jpg (центральная).
У нас в универе радиоэлектронщикам дают QBasic или максимум Паскаль с абсолютно детскими задачками. Так что видимо программой так предусмотрено — что программирование не очень важно. Так что как вариант — это самообразование — если программирование действительно интересно. Тем более самообразование — лучше любого преподавателя и оно порой даже поможет избежать каких-то серьёзных ошибок в коде, всегда можно решить задачу, выложить её решение, а всякие гуру прокомментируют это всё дело лучше любого препода :)
Представил как программисты на берестяных грамотах гусиными перьями пишут кодъ. Ну и одежка подходящая…
2009 год, ФизТех УПИ. Экзамен по С++ — автомат, но те кто сдавали — … писали на бумажках.
Экзамен. На бумаге пишем запросы SQL, которые должны работать в C++ Builder'е, а это со всеми textedit'ами. А в правом-верхнем углу листка писать вымышленные свойства datasouce(!!!)
а у нас один препод принимал экзамен, только по распечатанному коду на Си++
и сам проверял))
не доверял он компам ))
и сам проверял))
не доверял он компам ))
У нас тоже по ассемблеру один аспирант в университете работы на бумаге принимал, когда турбоасм запускаться на машине не хотел. Самое забавное, что успешно сдавались даже нерабочие алгоритмы. Видимо, преподаватель хотел показать всем, какой он гуру в асме. :-) Как только мы просекли момент с зачтённым нерабочим алгоритмом, то в ход пошли все черновики, даже самые бредовые. Большая часть лабораторных работ в его мозгу успешно компилировалась в рабочий код. :-)
по-идее экзамен сданный и программа написанная — суть две разные вещи. как общее знание синтаксиса и подходов и практическое исполнение, или экзамен по ПДД и «сдать вождение». разница — ограмна.
П.С. я когда то сдавал экзамен по Коболу (на бумаге) — две тетради (!) формата А4 исписал полностью, судорога в руке… эх, золотые времена…
П.С. я когда то сдавал экзамен по Коболу (на бумаге) — две тетради (!) формата А4 исписал полностью, судорога в руке… эх, золотые времена…
МГТУ им. Баумана, 2й курс. Через три недели экзамен по ассемблеру — написать программу на бумажке -.-
придётся тренироваться)
придётся тренироваться)
Мы так же сдавали asm на 2м курсе на бумажках. На 1м на бумажках Pascal, на 2м Делфи. Преподы считают, что таким образом они могут объективно оценить наши знания, т.к. якобы нет компилятора, нет IDE (ошибки исправлять некому) — есть только наши знания по предмету. Считаю это ахинеей. Если я делаю ошибку на бумажке, только потому, что я забыл название какой-то стандартной функции, то все беда -балл стразу. И никого не волнует, что я в любой момент, имея комп смогу подсмотреть эту функцию в справочнике. Я вообще ненавижу контрольные, где надо написать программу за 40 минут, да еще и на бумажке — бред какой-то!
Получился несколько иной смысл (последний пункт), не так ли? ;)
А еще мы все умрем.
в вузе вообще много чего не преподается для программистов )
Зато мозг расшевеливается по части сообразить, успеть, выкрутиться и найти, где прочитать/списать.
Хорошо когда хоть что-то преподается. У меня в ВУЗе почти ничего.
Главное что заинтересовали и дали направление, на этом спасибо :)
Главное что заинтересовали и дали направление, на этом спасибо :)
Особенно если ВУЗ сельскохозяйственный.
в ВУЗах вообще много чего не преподается для всех профессий, к сожалению…
За несколько лет, пока пишу разного уровня программы, особенно прочувствовала пункты 4 и 10. Наизобретала кучу велосипедов, прежде чем начала искать готовые решения типичных задач. Хотя, в обучающих целях это полезно. А уж про баги… Комментарии излишни )
ну я согласен с фразой: плох тот интернет программист, который не пытался писать свою CMS. смотри п.1 :) Пользоваться чужими решениями и выбирать из них оптимальное — это тоже наука, для этого нужно по крайней мере представлять как бы ты это сделал и понимать, что за тебя сделали лучше :)
Согласна. Но, кстати говоря, в редких случаях бывает значительно быстрее и проще изобрести свой маленький велосипедик, чем найти готовое решение. Это когда надо автоматизировать какую-нибудь несложную операцию, и удобнее за час написать своё, чем за несколько часов отыскать какой-нибудь продукт с кучей функций, которые вообще не нужны. И ещё и Shareware для полного счастья.
Так оно и есть, а вообще в вузах учат не программистов, а просто учат студентов программированию и соотвественно эти вещи просто не нужны. Хотя конечно хотелось бы, чтобы маленько учили как не надо делать. А то как увидишь код среднестатистического студента, так плохо становится.
Та специальность на которой я учился так и называлась, системный программист. Ничему подобному там не учили.
Полностью согласен с вами, учат именно программированию и то бывает только синтаксис языка объяснят и не более того, хотя многое от преподавателя зависит, причём некоторые из них навязывают порой свои принципы, причём вдалбливают их и на это кучу времени уходит, а например
на тоже самое тестирование, отладку программ — вообще времени не было и не объясняли — это уж кто сам изучит и поймёт, либо просто пропустит
на тоже самое тестирование, отладку программ — вообще времени не было и не объясняли — это уж кто сам изучит и поймёт, либо просто пропустит
ну тут не соглашусь с вами немножко. Задача универа все же дать более общее образование и научить саморазвиваться, при этом универ не может научить всему сразу, но дает всего по чуть-чуть (это про объяснить синтаксис). У В моем универе картина почти такая же — вроде я знаю и кучу языков (ну проходили же), но полноценно писать могу только на 2-3 (которые мне больше пришлись по душе).
Если речь идет научить например вот меня или вас одному языку программирования, изучить области применения, показать на практике — тогад нужно создавать колледжы и ПТУ, где научат профессионально программировать, но это будет узкоспециализированное образование (я не про те ПТУ, что сейчас существуют) без лишней фигни в виде гуманитарных наук. Думаю со временем что-то пободнее все же будет.
Если речь идет научить например вот меня или вас одному языку программирования, изучить области применения, показать на практике — тогад нужно создавать колледжы и ПТУ, где научат профессионально программировать, но это будет узкоспециализированное образование (я не про те ПТУ, что сейчас существуют) без лишней фигни в виде гуманитарных наук. Думаю со временем что-то пободнее все же будет.
по большей части, студента, в среднестатистическом, не топовом, вузе учат где найти нужную методичку, а потом красиво, по госту, оформлять отчеты.
тут с вами согласен :)
на себе это почувствовал… никакая программа (простой сриптик на php за 40 минут) и красиво оформленная пояснительная записка дали возможность очень просто получить за курсовой проект высший бал… это нормально? я конечно радуюсь сейчас, но это не нормально и такого быть не должно…
на себе это почувствовал… никакая программа (простой сриптик на php за 40 минут) и красиво оформленная пояснительная записка дали возможность очень просто получить за курсовой проект высший бал… это нормально? я конечно радуюсь сейчас, но это не нормально и такого быть не должно…
Почему-то сначала в буржунете на всяких развлекательныйх сайтах, ну а в последнее время тут, стала популярной подобная форма публикаций. 10 способов как завязать шнурки, 20 вещей которые стоит иметь при себе, 15 способов почистить унитаз, ей-богу как-будто для домохозяек пишут, чтобы на их гладком мозгу не появилась случайно лишняя извилина.
И ведь каждый раз когда откроешь такой креатив, то если повезёт — прочитаешь очевидные факты на какую-нибудь тему (типа трава — зелёная), а если не повезёт то вообще бессмысленные и бесполезные утверждения.
И ведь каждый раз когда откроешь такой креатив, то если повезёт — прочитаешь очевидные факты на какую-нибудь тему (типа трава — зелёная), а если не повезёт то вообще бессмысленные и бесполезные утверждения.
Людям в розовых очках и высказывание вида:«трава — зелёная» полезны.
На хабре года 1.5 назад даже была обучающая статья о том, как и почему писать материалы в виде нумерованных списков, и что они дают лишний плюс в карму.
Многие вещи мы прекрасно знаем, но не достанем из закоулков своей памяти и не обратим на них внимания, пока не найдем им подтверждения в виде букв.
Так написано большинство книг. За примерами далеко ходить не надо, смотрите Библию.
Так написано большинство книг. За примерами далеко ходить не надо, смотрите Библию.
Увы, это следствие снекового мышления (от англ. snack — закуска). Люди, особенно молодые, привыкли быстро воспринимать информацию: клип по mtv идет всего 3 минуты, рекламный ролик несколько секунд, смска или твит занимают лишь десятки символов и так далее. Человек привыкает к этому, ему становится сложно воспринимать бОльшие объемы информации. Возникают комментарии из серии «ниасилил». Поэтому рождаются статьи, разбитые на несколько простых, коротких мыслей.
Однако это взаимосвязанный процесс — восприятие формирует образ мышления. Привыкнув потреблять маленькие порции информации, человек уже не стремиться производить ее в больших объемах. На мой взгляд, это ведет к упрощению мышления, ее ограниченности.
А такой расклад не сулит ничего хорошего.
Однако это взаимосвязанный процесс — восприятие формирует образ мышления. Привыкнув потреблять маленькие порции информации, человек уже не стремиться производить ее в больших объемах. На мой взгляд, это ведет к упрощению мышления, ее ограниченности.
А такой расклад не сулит ничего хорошего.
Структурированная информация быстрее и легче усваивается… Почему собственно бы и нет?
Те, у кого нет мозгов, всё равно не воспользуются, а те, у кого есть — найдут для себя что-то… (а те, у кого их до хрена, конечно же, итак всё знали :D)
Те, у кого нет мозгов, всё равно не воспользуются, а те, у кого есть — найдут для себя что-то… (а те, у кого их до хрена, конечно же, итак всё знали :D)
На самом деле есть только один пункт, который надо осознать — 1, а остальные это всего лишь следствие.
Можно я побуду занудой?
Хорошо бы топик переделать, как топик-перевод?
А статья клевая.
Хорошо бы топик переделать, как топик-перевод?
А статья клевая.
какая-то неоднозначная статья на мой взгляд
у меня вопрос к автору, например по пункту «Весь код — дерьмо», слишком как-то абстрактно написано,
речь идёт об оптимизации когда? красивом оформлении?
приведите пример кода самой высокой степени дерьмовости и самой низкой
у меня вопрос к автору, например по пункту «Весь код — дерьмо», слишком как-то абстрактно написано,
речь идёт об оптимизации когда? красивом оформлении?
приведите пример кода самой высокой степени дерьмовости и самой низкой
Точно не согласен с пунктами 3-5 и 8.
Если вы считаете, что для вас верен пункт 3, вам вообще лучше сменить род занятий. Зачем насиловать себя и других.
Я регулярно встречаю кучу отличного кода и ориентируюсь на него. Возьмите какую-нибудь OpenSource библиотеку, которая у всех на слуху и с большой вероятностью вы увидите хороший код.
Если вы считаете, что для вас верен пункт 3, вам вообще лучше сменить род занятий. Зачем насиловать себя и других.
Я регулярно встречаю кучу отличного кода и ориентируюсь на него. Возьмите какую-нибудь OpenSource библиотеку, которая у всех на слуху и с большой вероятностью вы увидите хороший код.
не согласен с пунктом 4
У нас в рамках дисциплины «Надежность программного обеспечения» эту фразу преподаватель говорил каждую лекцию, иногда не один раз. Т.е. нас этому все же учили.
4. В программе всегда есть баг
ВСЕГДА! Вопрос только в том, сколько времени потребуется, чтобы найти баг.
У нас в рамках дисциплины «Надежность программного обеспечения» эту фразу преподаватель говорил каждую лекцию, иногда не один раз. Т.е. нас этому все же учили.
Перешёл на источник по ссылке и там ещё почитал. В общем, автор выбирает провокационные выражения для привлечения внимания и из-за этого, если переводить частично, без всех приложенных пояснений — теряется смысл.
Автор пишет — «All code is crap», а на самом деле имеет в виду — «Любой код не идеален». Я без проблем соглашусь со вторым, но никогда с первым.
Автор пишет — «All code is crap», а на самом деле имеет в виду — «Любой код не идеален». Я без проблем соглашусь со вторым, но никогда с первым.
Перевод статьи полный. Каюсь, что ссылки по тексту не проставил. Те кому интересно, могут обратиться к источнику. Насчет crap — из песни слово не выкинешь. Не стоит воспринимать все слова однозначно и принимать статью как четкий план. Как указано в этой статье — все мы не правы. Отличаемся только глубиной своих заблуждений. Думаю, что и эта статья не претендует на безусловную истину.
Моё мнение, что оригинальная статья прикрывает «жёлтыми» заголовками прописные истины типа: «Никто и ничто не идеально в этом мире», «Старайтесь получать удовольствие от работы» и «Не изобретайте велосипед». Думаю, автор получил свою долю внимания, посещений, переходов по рекламным ссылкам и т.д. (зависит от того, зачем он это всё затеял).
Теперь немного подокапываюсь до перевода. 6 пункт я бы перевёл следующим образом (куча отсебятины, но по смыслу стараюсь держаться близко к тексту):
Разработка «на бумаге» не работает.
Раньше я верил, что можно сначала продумать всю программу на бумаге, а потом на компьютере дописать по-мелочи. Но такой метод просто не работает.
Разработка ПО сложна и трудно «увидеть» все сущности и отношения между ними до тех пор, пока не начнёте писать код. Так что продолжайте планировать и прикидывать архитектуру (это очень полезно), но не застревайте на этом этапе слишком долго. И не рассматривайте диаграммы, нарисованные на этом этапе как «последнюю инстанцию».
Теперь немного подокапываюсь до перевода. 6 пункт я бы перевёл следующим образом (куча отсебятины, но по смыслу стараюсь держаться близко к тексту):
Разработка «на бумаге» не работает.
Раньше я верил, что можно сначала продумать всю программу на бумаге, а потом на компьютере дописать по-мелочи. Но такой метод просто не работает.
Разработка ПО сложна и трудно «увидеть» все сущности и отношения между ними до тех пор, пока не начнёте писать код. Так что продолжайте планировать и прикидывать архитектуру (это очень полезно), но не застревайте на этом этапе слишком долго. И не рассматривайте диаграммы, нарисованные на этом этапе как «последнюю инстанцию».
Навеяло )))
— Ничто не работает так, как планировалось запрограммировать.
— Ничто не программируется так, как должно работать.
— Хороший программист характеризуется умением доказать почему задачу невозможно выполнить, когда ему просто лень её выполнять.
— На решение проблемы уходит в 3 раза меньше времени, чем на обсуждение всех “за” и “против” её решения.
— Обещанный срок сдачи – это аккуратно рассчитанная дата окончания проекта плюс 6 месяцев.
— Программисту всегда известна последовательность действий, которыми пользователь может повесить его программу, но он никогда не чинит эту проблему, надеясь на то, что никому никогда не придёт в голову эту последовательность выполнять.
— Настоящие программисты любят Windows – все ошибки, сделанные по собственной тупости, можно свалить на Microsoft.
— Следствие Гейтса: 99% проблем, сваливаемых на Microsoft, является следствием тупости самих программистов.
— В приступе злости все почему-то молотят по невинному монитору, вместо системного блока.
— В случае голодовки настоящий программист ещё месяц сможет питаться едой, выковырянной из-под кнопок клавиатуры.
— Настоящий программист уже как минимум поменял три залитых пивом клавиатуры.
— Все, кто испытывает проблемы с настройкой кодировки, автоматически считаются неандертальцами.
— Дилетантские разговоры о компьютерах вызывают резкую тошноту вплоть до приступов рвоты. Вопрос о том, как поменять “обои” в Windows вызывает желание перерезать горло вопрошающему.
— У большинства людей, нуждающихся в твоей помощи, причина ошибки в работе программы чисто генетическая.
— HTML, HTTP, FTP, SMTP, TCP/IP, RTFM и т.д. – это слова, а не аббревиатуры.
— Словосочетание “мышка-норушка” не несёт никакого смысла.
— Самые мистические проблемы, широко раздуваемые и афишируемые, в конце концов оказываются твоими глупейшими ошибками.
— Следствие: Если твоя программа выполняет мистические действия, значит, ты сделал что-то невероятно тупое.
— Самое плохое ощущение для программиста – когда вокруг тебя стоят 10 человек и все пытаются найти причину проблемы в твоей программе, а ты уже понял, в чём проблема, но боишься сказать, потому что это что-то вопиюще глупое…
— Решение всех жизненных проблем находится на интернете. Надо только уметь хорошо искать.
— Конфликт логических указаний в жизни взывает фатальную ошибку в работе мозга программиста – возможно повышение температуры и сильное головокружение вплоть до рвоты или потери сознания.
— Тех, кто презирает программистов, программисты презирают сильнее, чем те, кто презирает программистов, презирают программистов, которые презирают тех, кто их презирает.
— Если ты понял предыдущее – то ты программист.
Дополнение
— Программировать нельзя научиться. Можно только научиться учиться программировать.
— Приметы прораммиста
— Если новая программа с первого раза компилируется без ошибок, значит, она написана принципиально неправильно.
— Если к вам перестали поступать жалобы на вашу программу, значит, ею уже никто не пользуется.
— Чем универсальнее написана программа, тем меньше найдётся мест, где можно было бы её применить.
— Чем точнее программист выполняет требования заказчика, тем бестолковее получается программа.
— Чем больше заказчик понимает в программировании, тем больше он мешает работе.
— Ошибки легче всего делаются и труднее всего обнаруживаются в самых простых местах программы.
— Нет более живучих программ, чем заплатки, сделанные на скорую руку.
— Чем чаще программист жалуется на чужой soft, тем хуже он делает свой.
Закон МУРА
— Производительность электронных микросхем удваивается без изменения их цены каждые 18 месяцев.
Закон БОСКО
— Производительность оптических устройств удваивается в 2 раза быстрее.
— Правило IP-технологий
— Послал пакет, и молча стой, авось дойдёт.
— Народная мудрость
— Сытый инспектор добрее не становится, он становится ленивее.
— Ничто не работает так, как планировалось запрограммировать.
— Ничто не программируется так, как должно работать.
— Хороший программист характеризуется умением доказать почему задачу невозможно выполнить, когда ему просто лень её выполнять.
— На решение проблемы уходит в 3 раза меньше времени, чем на обсуждение всех “за” и “против” её решения.
— Обещанный срок сдачи – это аккуратно рассчитанная дата окончания проекта плюс 6 месяцев.
— Программисту всегда известна последовательность действий, которыми пользователь может повесить его программу, но он никогда не чинит эту проблему, надеясь на то, что никому никогда не придёт в голову эту последовательность выполнять.
— Настоящие программисты любят Windows – все ошибки, сделанные по собственной тупости, можно свалить на Microsoft.
— Следствие Гейтса: 99% проблем, сваливаемых на Microsoft, является следствием тупости самих программистов.
— В приступе злости все почему-то молотят по невинному монитору, вместо системного блока.
— В случае голодовки настоящий программист ещё месяц сможет питаться едой, выковырянной из-под кнопок клавиатуры.
— Настоящий программист уже как минимум поменял три залитых пивом клавиатуры.
— Все, кто испытывает проблемы с настройкой кодировки, автоматически считаются неандертальцами.
— Дилетантские разговоры о компьютерах вызывают резкую тошноту вплоть до приступов рвоты. Вопрос о том, как поменять “обои” в Windows вызывает желание перерезать горло вопрошающему.
— У большинства людей, нуждающихся в твоей помощи, причина ошибки в работе программы чисто генетическая.
— HTML, HTTP, FTP, SMTP, TCP/IP, RTFM и т.д. – это слова, а не аббревиатуры.
— Словосочетание “мышка-норушка” не несёт никакого смысла.
— Самые мистические проблемы, широко раздуваемые и афишируемые, в конце концов оказываются твоими глупейшими ошибками.
— Следствие: Если твоя программа выполняет мистические действия, значит, ты сделал что-то невероятно тупое.
— Самое плохое ощущение для программиста – когда вокруг тебя стоят 10 человек и все пытаются найти причину проблемы в твоей программе, а ты уже понял, в чём проблема, но боишься сказать, потому что это что-то вопиюще глупое…
— Решение всех жизненных проблем находится на интернете. Надо только уметь хорошо искать.
— Конфликт логических указаний в жизни взывает фатальную ошибку в работе мозга программиста – возможно повышение температуры и сильное головокружение вплоть до рвоты или потери сознания.
— Тех, кто презирает программистов, программисты презирают сильнее, чем те, кто презирает программистов, презирают программистов, которые презирают тех, кто их презирает.
— Если ты понял предыдущее – то ты программист.
Дополнение
— Программировать нельзя научиться. Можно только научиться учиться программировать.
— Приметы прораммиста
— Если новая программа с первого раза компилируется без ошибок, значит, она написана принципиально неправильно.
— Если к вам перестали поступать жалобы на вашу программу, значит, ею уже никто не пользуется.
— Чем универсальнее написана программа, тем меньше найдётся мест, где можно было бы её применить.
— Чем точнее программист выполняет требования заказчика, тем бестолковее получается программа.
— Чем больше заказчик понимает в программировании, тем больше он мешает работе.
— Ошибки легче всего делаются и труднее всего обнаруживаются в самых простых местах программы.
— Нет более живучих программ, чем заплатки, сделанные на скорую руку.
— Чем чаще программист жалуется на чужой soft, тем хуже он делает свой.
Закон МУРА
— Производительность электронных микросхем удваивается без изменения их цены каждые 18 месяцев.
Закон БОСКО
— Производительность оптических устройств удваивается в 2 раза быстрее.
— Правило IP-технологий
— Послал пакет, и молча стой, авось дойдёт.
— Народная мудрость
— Сытый инспектор добрее не становится, он становится ленивее.
самый лучший код, который я видел было достаточно сложно читать.
С другой стороны
Код, который достаточно сложно читать часто является дерьмо.
парадокс :)
У автора слишком плохое отношение к образованию, нам в той или иной мере говорили все пункты, кроме пункта «Весь код — дерьмо».
Ребят, я студент и мне повезло. Нам все эти истины, и не только эти, вдалбливали в голову на протяжении семестра, за что я очень благодарен.
Может чего-то и не преподавали в универе, но ко всему нужно приходить своими умозаключения, исходя из полученного базиса… :)
Краткое вольное изложение книги Фредерика Брукса?
В нашем вузе про него рассказывали.
что в 75 году, что уже 35 лет спустя, идея профессии программиста остается той же… даже не смотря на модернизацию и скачки в развитии технологий, методологий и пр…
В нашем вузе про него рассказывали.
что в 75 году, что уже 35 лет спустя, идея профессии программиста остается той же… даже не смотря на модернизацию и скачки в развитии технологий, методологий и пр…
Толку от преподавания или попыток интеллектуально понять эти правила нет никакого, их надо прочувствовать. Так какой смысл тогда о них писать? Бывалый их и так знает, а новичек только еще больше запутается. На предложение переписать особо грязный кусок кода он будет отвечать «весь код дерьмо» (это не гипотетический пример, у одного сейчас статус такой в скайпе, успокаивает обиженное самолюбие), когда ему будут говорить, чтоб заткнул дыры в безопасности или добавить комментарии, он будет отвечать «а клиент доволен, че».
а вот у меня в вузе (на факультете информатики) не припадают программистам одну вещь — ПРОГРАММИРОВАНИЕ.
хотя стоп. все таки паскаль на 1м курсе я выучил. дальше только сам.
хотя стоп. все таки паскаль на 1м курсе я выучил. дальше только сам.
По поводу 10-го пункта (изобретения велосипедов).
Каждый из моих знакомых PHP-разработчиков на разных стадиях своей профессиональной жизни делал собственную CMS, которая «должна работать лучше чем все другие». Я тут добавлю, что изобретение велосипеда все-таки нужный этап, другое дело что на коммерческих проектах их изобретать не нужно.
Каждый из моих знакомых PHP-разработчиков на разных стадиях своей профессиональной жизни делал собственную CMS, которая «должна работать лучше чем все другие». Я тут добавлю, что изобретение велосипеда все-таки нужный этап, другое дело что на коммерческих проектах их изобретать не нужно.
Я тут добавлю, что изобретение велосипеда все-таки нужный этап, другое дело что на коммерческих проектах их изобретать не нужно.
Позвольте не согласиться. Порой готовые решения стоят дороже, чем изобретение велосипеда. Ну или они попросту не имеют весь набор необходимого функционала, и «допиливание» опять таки трудозатратнее. Хотя это по большей части касается больших и трудных проектов.
А в плане велосипедов при разработке коммерческих проектов, так тут имхо самый важный риск — срыв сроков.
Я говорю про те случаи (их, полагаю, около 90%) когда разработчики вместо того что бы взять готовое бесплатное решение решают, что «мы сами программисты, напишем лучше».
Если клиент хочет сайт-блог со стандартными функциями, то наверное лучше поставить ему Вордпресс, а не писать мега-кмс с нуля. Потому что в итоге клиент поимеет проблем:
1) со сроками
2) с деньгами
3) с поддержкой (устранением багов, добавлением функционала)
4) натяжкой нового дизайна.
Помучившись с год, клиент наймет нового программиста, который выцепит данные из БД, и заэкспортит их в Вордпресс. Киньте в меня камнем, если подобные случаи не происходят сплошь и рядом.
То есть подытоживая, хочется сказать так: ни один клиент не хочет, чтоб программировать учились на его проектах. То, что программисту все-таки надо на чем-то совершенствовать свои навыки, и развиваться — уже другой вопрос. Но клиента/заказчика он не должен беспокоить.
Если клиент хочет сайт-блог со стандартными функциями, то наверное лучше поставить ему Вордпресс, а не писать мега-кмс с нуля. Потому что в итоге клиент поимеет проблем:
1) со сроками
2) с деньгами
3) с поддержкой (устранением багов, добавлением функционала)
4) натяжкой нового дизайна.
Помучившись с год, клиент наймет нового программиста, который выцепит данные из БД, и заэкспортит их в Вордпресс. Киньте в меня камнем, если подобные случаи не происходят сплошь и рядом.
То есть подытоживая, хочется сказать так: ни один клиент не хочет, чтоб программировать учились на его проектах. То, что программисту все-таки надо на чем-то совершенствовать свои навыки, и развиваться — уже другой вопрос. Но клиента/заказчика он не должен беспокоить.
… если это не Bolgenos, то создание велосипедов — действительно полезно. В плане получения опыта.
Эх, сколько я велосипедов написал.
Эх, а сколько я их еще напишу..))
Эх, сколько я велосипедов написал.
Эх, а сколько я их еще напишу..))
В некоторых случаях это оправдано. В смысле, не писать свою «самую-крутую-cms-в-мире-друпалы-вордпрессы-джумлы-рядом-не-стояли», а что под некоторые вещи легче написать свой движок, особенно если проект простенький, времени немного и нету опыта полноценной работы с хорошими CMS.
Большинство пунктов статьи — та или иная интерпретация т.н. закона Мерфи.
1. Если вы написали программу — проверьте ее на ошибки.
2. Исправьте найденные ошибки.
3. Проверьте программу на ошибки.
4. Исправьте ошибки.
5. Проверьте программу на ошибки, если их нет — вы плохой программист
2. Исправьте найденные ошибки.
3. Проверьте программу на ошибки.
4. Исправьте ошибки.
5. Проверьте программу на ошибки, если их нет — вы плохой программист
Вот к чему этот пафос? Ну проверил я программу, понял что плохой программист. Дальше что?
А если нашел ошибки в третий раз, то я лучше? А если и в 20 раз нашел? Наверное тогда я вообще идеальный программист. И заказчик просто светится от счастья, ему так важна корректная обработка ситуации, когда сумма оплаты в его интернет-магазинчике переполняет 32-битное целое.
А если нашел ошибки в третий раз, то я лучше? А если и в 20 раз нашел? Наверное тогда я вообще идеальный программист. И заказчик просто светится от счастья, ему так важна корректная обработка ситуации, когда сумма оплаты в его интернет-магазинчике переполняет 32-битное целое.
4. В программе всегда есть баг
Ну что ж так фатально-то.
К примеру, сколько багов содержит «Hello, World!» на любимом языке программирования?
Моментально ведь прибегут люди, которые раздуют хелловорлд с трех до двадцати строчек, зато будет правильно :)
Вспомнилась разве что вот эта статья:
habrahabr.ru/blogs/nix_coding/75971/
habrahabr.ru/blogs/nix_coding/75971/
Не совсем правильный 2 пункт, нужно добавить:
Все что может сломаться, ломается.
Все что НЕ может сломаться, ломается тоже.
Все что может сломаться, ломается.
Все что НЕ может сломаться, ломается тоже.
Если во время учебы элементарно делать свой проект, то кроме 5 и 9 всему можно научиться.
4. В программе всегда есть баг
А в некоторых вузах вместо этого рассказывают про формальную верификацию программ :)
По поводу багов я всегда говорю так…
Слабое звено в программировании это человек. Пока программы пишут люди, в них будут баги. Вот когда код будут писать роботы, тогда в программах баги тоже будут. Потому что роботов этих запрограммировали тоже люди.
Слабое звено в программировании это человек. Пока программы пишут люди, в них будут баги. Вот когда код будут писать роботы, тогда в программах баги тоже будут. Потому что роботов этих запрограммировали тоже люди.
Пишите программы, которые делают одну вещь и делают её хорошо.
Пишите программы, которые бы работали вместе.
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
©
Пишите программы, которые бы работали вместе.
Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.
©
Задрали уже. Идите работать! irony
Отличная статья, прекрасный слог. Вы молодец :)
>Конечно, есть множество степеней дерьмовости кода, но самый лучший код, который я видел было достаточно сложно читать.
Хороший код легко читать.
Хороший код легко читать.
Количество минусующих комментарии типа «Не знаю в каком ВУЗе учился автор, но у нас...» явно подтверждает тенденцию набега на хабр тупорылой школоты и «перваков», которые нихера не учатся и считают по умолчанию что ВСЕ ВУЗы этой страны сраное говно и во всех ВУЗах все преподы мудаки и не учат программированию.
«если вы говорите слово «должно», то у вас проблемы»
«Весь код — дерьмо»
«В программе всегда есть баг. ВСЕГДА! Вопрос только в том, сколько времени потребуется, чтобы найти баг.»
«Программа, изложенная на бумаге не работает»
< ?php echo «hello, world!»;? >
1) я говорю, что этот код ДОЛЖЕН напечатать «hello, world!». у меня проблемы?
2) конечно же, этот код тоже дерьмо. потому что он не читается довольно-таки сложно!
3) через сколько вы найдете в этой программе баг?
4) представьте, что тут недавно я обнаружил… я написал эту программу на бумаге, а потом перенес на компьютер и — вы не поверите мне! — она ЗАРАБОТАЛА!
«Бонусный пункт! Эй! А ведь наша работа клевая!»
подлизы
«Весь код — дерьмо»
«В программе всегда есть баг. ВСЕГДА! Вопрос только в том, сколько времени потребуется, чтобы найти баг.»
«Программа, изложенная на бумаге не работает»
< ?php echo «hello, world!»;? >
1) я говорю, что этот код ДОЛЖЕН напечатать «hello, world!». у меня проблемы?
2) конечно же, этот код тоже дерьмо. потому что он не читается довольно-таки сложно!
3) через сколько вы найдете в этой программе баг?
4) представьте, что тут недавно я обнаружил… я написал эту программу на бумаге, а потом перенес на компьютер и — вы не поверите мне! — она ЗАРАБОТАЛА!
«Бонусный пункт! Эй! А ведь наша работа клевая!»
подлизы
Не во всех вузах.
У нас преподают в каком-то виде 8-й и 10-й пункт.
У нас преподают в каком-то виде 8-й и 10-й пункт.
| 10. Кто-то это уже делал
А потом, когда ты подходишь к человеку и спрашиваешь «Почему это здесь так написано?» следует «Я погуглил и нашел такое решение». И т.е. это все? Кто-то когда-то это сделал, сделал это некачественно, а все остальные гуглят и получая этот результат берут себе… и это распространяется очень быстро… Так зачем тогда вообще программисты с какими-то навыками? Можно взять школьника, умеющего делать копи-паст, и сказать что он программист?
А потом, когда ты подходишь к человеку и спрашиваешь «Почему это здесь так написано?» следует «Я погуглил и нашел такое решение». И т.е. это все? Кто-то когда-то это сделал, сделал это некачественно, а все остальные гуглят и получая этот результат берут себе… и это распространяется очень быстро… Так зачем тогда вообще программисты с какими-то навыками? Можно взять школьника, умеющего делать копи-паст, и сказать что он программист?
Если он сделает копипаст и, не задавая сотни вопросов другим людям по поводу «как что куда вставить», получит работающее приложение, то да.
А если это работающее приложение будет терпеть изменения в короткий срок? и именно этот код станет помехой… как быть?
Ну тут стоит разделить сам копируемый код:
1)уже проверенный (часть известного/популярного набора компонентов, известный вендор, имеющиеся отзывы, использование в других проектах).
2)не проверенный (запись в чьём-то бложике).
В обоих случаях код стоит просматривать на то, чтобы он не поломал приложение, а во втором случае стоит его очень внимательно разобрать.
Собственно я и сказал — если копипаста — осмысленная (человек понимает что делает этот код и _как_), то вреда она не принесёт.
— Опять же к копипасте спокойно можно отнести использование сторонних классов, библиотек… Мне вот тут пришлось на java se пописать (в последний раз нормально писал на яве год назад, и то это было j2me). Так вот я пользовался копипастой в обоих смыслах:
1.Использовал сторонние библиотеки (ява ими очень славится и не зря)
2.Гуглил реализацию нужных мне моментов, читал код и если он делал что мне нужно — адаптировал его под своё приложение.
Конечно если «программист» копирует-вставляет тот код, который нормальный человек и гуглить не станет, заваливает какойнить форум связанными вопросами аля «Как мне прочитать данные из файла», а через 30 минут «Как мне изменить полученные данные таким образом, что...» а потом «Как мне записать данные в файл», то тут уже стоит ставить под сомнение что человек-программист.
— Ну а если вставленный (не важно какой код) поломал приложение, то нормальный программист сможет это исправить, а ненормальный будет откатываться до момента «работает», искать другое решение, делать копипасту и повторять этот цикл до момента, пока глюки не перестанут всплывать.
1)уже проверенный (часть известного/популярного набора компонентов, известный вендор, имеющиеся отзывы, использование в других проектах).
2)не проверенный (запись в чьём-то бложике).
В обоих случаях код стоит просматривать на то, чтобы он не поломал приложение, а во втором случае стоит его очень внимательно разобрать.
Собственно я и сказал — если копипаста — осмысленная (человек понимает что делает этот код и _как_), то вреда она не принесёт.
— Опять же к копипасте спокойно можно отнести использование сторонних классов, библиотек… Мне вот тут пришлось на java se пописать (в последний раз нормально писал на яве год назад, и то это было j2me). Так вот я пользовался копипастой в обоих смыслах:
1.Использовал сторонние библиотеки (ява ими очень славится и не зря)
2.Гуглил реализацию нужных мне моментов, читал код и если он делал что мне нужно — адаптировал его под своё приложение.
Конечно если «программист» копирует-вставляет тот код, который нормальный человек и гуглить не станет, заваливает какойнить форум связанными вопросами аля «Как мне прочитать данные из файла», а через 30 минут «Как мне изменить полученные данные таким образом, что...» а потом «Как мне записать данные в файл», то тут уже стоит ставить под сомнение что человек-программист.
— Ну а если вставленный (не важно какой код) поломал приложение, то нормальный программист сможет это исправить, а ненормальный будет откатываться до момента «работает», искать другое решение, делать копипасту и повторять этот цикл до момента, пока глюки не перестанут всплывать.
Не нужно воспринимать все буквально. Думать головой никто не запрещает.
Опять про юзабилити забыли :-) так всегда
Видимо, у нас какой-то неправильный ВУЗ. Нас всему этому научили еще на 1-2 курсах.
11. все относительно
12. Смешная дополнительная опция.
13. пипл негодуэ
Сначало бумага + карандаш, после этого тупое кодирование. Только так. Если не можешь продумать программу на бумаге, все твои действия напоминают фразу: «Ввяжемся в драку, а там видно будет». И такое мог сказать только студент =).
Бывает и не дерьмовый, а наоборот идеальный код. Просто хороших программистов мало. Хороший код читабелен всегда, другой вопрос что этот код выходит за рамки компетенции среднего программиста.
Не всегда есть задачи, которые кто-то делал. Даже казалось бы на вполне обычных GUI интерфейсах можно споткнутся так и не найти решения и подсказок во всем инете. Если вы с этим не сталкивались это означает лишь отсуствие такого опыта.
Баги есть всегда, это аксимома, но бумага и карандаш, творят чудеса =)
в остальном более-менее согласен.
Бывает и не дерьмовый, а наоборот идеальный код. Просто хороших программистов мало. Хороший код читабелен всегда, другой вопрос что этот код выходит за рамки компетенции среднего программиста.
Не всегда есть задачи, которые кто-то делал. Даже казалось бы на вполне обычных GUI интерфейсах можно споткнутся так и не найти решения и подсказок во всем инете. Если вы с этим не сталкивались это означает лишь отсуствие такого опыта.
Баги есть всегда, это аксимома, но бумага и карандаш, творят чудеса =)
в остальном более-менее согласен.
Спасибо за пункт 8. Остальные знал, а вот конкретно с восьмым у меня было много заморочек.
Иногда разработчики используют технологии или навязывают другие инженерные изыски только лишь ради правильных подходов. Но запомните, если это не добавит ценности клиенту, выбросьте их.
Если бы всё выбрасывали, и не предлагали, так бы и му… лись с IE6. :D
на самом деле всё перечисленное растёт от пункта 1, излишняя самоуверенность разработчиков или заказчиков — корень всех зол.
Самое плохое чему учит ВУЗ — завышенное самомнение, поэтому любой тред в рунете приходится начинать с доказательства что автор мудак ;), а дальше пытаться донести аргументы, если не окажется, что ты сам ещё больший мудак.
Самое плохое чему учит ВУЗ — завышенное самомнение, поэтому любой тред в рунете приходится начинать с доказательства что автор мудак ;), а дальше пытаться донести аргументы, если не окажется, что ты сам ещё больший мудак.
Слишком похоже на Макконелла. Подозреваю, что у него же и свиснуто.
1. Ничто так не мешает видеть, как точка зрения © Дон-Аминадо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 вещей, которые никогда не преподаются программистам в вузах