Вот этот топик возмутил: habrahabr.ru/blogs/htranslations/95063, и посему перечисляю эти десять вещей
Мы правы всякий раз, когда думаем, что знаем, как именно необходимо строить систему. Потому что зачастую готовые решения не подходят идеально в какой-либо ситуации. А те решения, которые имеются, например паттерны, коих огромное количество, — писались нами же. Программистами. Поэтому, да! Мы правы. Ну а что касается необходимости выслушать друг друга, — это скорее проблема комуникационного характера.
Теоретически сломаться может всё. Даже то, что достаточно атомарно, и просто исключён вариант поломки. Но почему оно не ломается? Потому, что необходимы соответствующие условия, которые могут наступить, а могут и не наступить. Известны случаи, когда при перепроектировании систем выявлялись ошибки, которые были способны аварийно завершить работу системы. Но за многие годы работы системы соответствующие условия так и не наступили.
Простите за такой заголовок. Иной раз код, где трижды повторяется один и тот же набор операторов — работает стабильней аналогичного кода, где набор операторов заключён в цикл. Это не призыв писать подобным образом, а лишь попытка обратить внимание читателя на палитру вариантов, при которых поставленная задача решается, и система работает долго и отказоустойчиво.
Вообще, «дерьмовость» кода — это сугубо субъективное понятие. Ведь каждый программист с высоты своего опыта способен оценить, насколько универсальней/эффективней/быстрей/красивей он может написать. Поэтому имеют место сайты наподобие «говнокода» и прочие бестолковые ресурсы в сети.
Багов нет в программе, которая ещё не написана :-).
Но вспоминаю случай на втором курсе университета. В hex редакторе написал com-программу, которая ничего не делала. Нужно было написать 2 опкода: nop и ret. Они были перепутаны местами. Не страшный, но баг.
Эти вещи я не променяю ни на какие амбиции никакого клиента. Буду перебиваться по мелочам, первое время зарабатывать не так много, как хотелось бы. Буду искать варианты. Но главное — не остановиться в развитии и помнить, что для тебя как для растущего программиста действительно важно.
Это привычка после сдачи лабораторных работ на первых курсах универа. Особо усердные студенты могут даже пару раз набросать свою программу на бумаге до того, как захотят перенести её в электронный исходник. Некоторые особо усердные преподаватели ругают не особо старательных студентов, за то что они набрасывают программу в редакторе и после отладки печатают её в отчёт а не переписывают руками. О чем я хочу сказать: о том, что изложение программы на бумаге — это полный бред.
Вопрос скорее философский. Смотря чего больше, и чего меньше. Идеальный вариант по моему мнению, — это когда много мелкого, и это мелкое взаимодействует между собой. Но не стоит забывать, что готове рецепты всё равно не решают идеально задачу. Поэтому вопрос сохраняет за собой статус философского.
Если различать понятия «кодирование» и «программирование», то наоборот — кодирование занимает 80% времени, а настоящее программирование — только 20%.
Если же не различать эти понятия, то опыт показывает, что закон Парето не всегда идеально работает. И это зависит от величины системы. Зачастую система может быть простой, но объемной в плане реализации. Тогда планирование и т.д. и т.п. занимают малую часть времени. И наоборот, система может быть маленькой, но сложной в реализации. При этом можно целую неделю её планировать, моделировать. А потом за ночь написать двести строк кода и успешно отладить за пару часов.
Он знает, что хочет:
— некое решение
— автоматизацию
— представительный сайт
— систему контроля
— экономию
Как это будет реализовано, какими инструментами и средствами, какие детали будут в проекте, сколько человек его будут писать, на python или php, — это заказчику не нужно. Он целиком и полностью в бизнесе, он знает, что ему нужно в контексте бизнеса.
В то время как рутинная задача требует полной отдачи для преодоления рутинного барьера.
Если кто-то уже делал, конечно стоит посмотреть. Но из выше перечисленных пунктов понятно, что порой бывает лучше написать свой «быдлокод», чем подтягивать тяжеловесный нагромождённый фреймворк, особенно когда этого по сути не требуется.
1. Мы правы
Мы правы всякий раз, когда думаем, что знаем, как именно необходимо строить систему. Потому что зачастую готовые решения не подходят идеально в какой-либо ситуации. А те решения, которые имеются, например паттерны, коих огромное количество, — писались нами же. Программистами. Поэтому, да! Мы правы. Ну а что касается необходимости выслушать друг друга, — это скорее проблема комуникационного характера.
2. Не всё, что может сломаться — ломается
Теоретически сломаться может всё. Даже то, что достаточно атомарно, и просто исключён вариант поломки. Но почему оно не ломается? Потому, что необходимы соответствующие условия, которые могут наступить, а могут и не наступить. Известны случаи, когда при перепроектировании систем выявлялись ошибки, которые были способны аварийно завершить работу системы. Но за многие годы работы системы соответствующие условия так и не наступили.
3. Не весь код — «дерьмо»
Простите за такой заголовок. Иной раз код, где трижды повторяется один и тот же набор операторов — работает стабильней аналогичного кода, где набор операторов заключён в цикл. Это не призыв писать подобным образом, а лишь попытка обратить внимание читателя на палитру вариантов, при которых поставленная задача решается, и система работает долго и отказоустойчиво.
Вообще, «дерьмовость» кода — это сугубо субъективное понятие. Ведь каждый программист с высоты своего опыта способен оценить, насколько универсальней/эффективней/быстрей/красивей он может написать. Поэтому имеют место сайты наподобие «говнокода» и прочие бестолковые ресурсы в сети.
4. В программе не всегда есть баг
Багов нет в программе, которая ещё не написана :-).
Но вспоминаю случай на втором курсе университета. В hex редакторе написал com-программу, которая ничего не делала. Нужно было написать 2 опкода: nop и ret. Они были перепутаны местами. Не страшный, но баг.
5. Наиболее важная вещь — благополучие и стремление к совершенству
Эти вещи я не променяю ни на какие амбиции никакого клиента. Буду перебиваться по мелочам, первое время зарабатывать не так много, как хотелось бы. Буду искать варианты. Но главное — не остановиться в развитии и помнить, что для тебя как для растущего программиста действительно важно.
6. Программа, изложенная на бумаге...
Это привычка после сдачи лабораторных работ на первых курсах универа. Особо усердные студенты могут даже пару раз набросать свою программу на бумаге до того, как захотят перенести её в электронный исходник. Некоторые особо усердные преподаватели ругают не особо старательных студентов, за то что они набрасывают программу в редакторе и после отладки печатают её в отчёт а не переписывают руками. О чем я хочу сказать: о том, что изложение программы на бумаге — это полный бред.
7. Меньше лучше, больше — ещё лучше.
Вопрос скорее философский. Смотря чего больше, и чего меньше. Идеальный вариант по моему мнению, — это когда много мелкого, и это мелкое взаимодействует между собой. Но не стоит забывать, что готове рецепты всё равно не решают идеально задачу. Поэтому вопрос сохраняет за собой статус философского.
8. Кодирование занимает 20% времени
Если различать понятия «кодирование» и «программирование», то наоборот — кодирование занимает 80% времени, а настоящее программирование — только 20%.
Если же не различать эти понятия, то опыт показывает, что закон Парето не всегда идеально работает. И это зависит от величины системы. Зачастую система может быть простой, но объемной в плане реализации. Тогда планирование и т.д. и т.п. занимают малую часть времени. И наоборот, система может быть маленькой, но сложной в реализации. При этом можно целую неделю её планировать, моделировать. А потом за ночь написать двести строк кода и успешно отладить за пару часов.
9. Заказчик знает, что он хочет
Он знает, что хочет:
— некое решение
— автоматизацию
— представительный сайт
— систему контроля
— экономию
Как это будет реализовано, какими инструментами и средствами, какие детали будут в проекте, сколько человек его будут писать, на python или php, — это заказчику не нужно. Он целиком и полностью в бизнесе, он знает, что ему нужно в контексте бизнеса.
10. Интересная задача — половина успеха в её решении
В то время как рутинная задача требует полной отдачи для преодоления рутинного барьера.
Если кто-то уже делал, конечно стоит посмотреть. Но из выше перечисленных пунктов понятно, что порой бывает лучше написать свой «быдлокод», чем подтягивать тяжеловесный нагромождённый фреймворк, особенно когда этого по сути не требуется.
