Всем здрям!
Вопрос может конечно и банальный но все-таки подскажите:
как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО.
Заранее благодарен.
Здравствуйте, krokodil955, Вы писали:
K>Всем здрям! K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код
Никак. По крайней мере не научился. Некачественно написать легче. И сразу же доработать напильником для качества. K>(т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО. http://www.rsdn.ru/res/book/prog/refactoring.xml
Вобщем, ключевые слова — экстремальное программирование, TDD, рефакторинг. Там тестирование используется как методика на этапе написания кода. То что нужно программисту.
Здравствуйте, krokodil955, Вы писали:
K>Всем здрям! K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО.
Здравствуйте, eao197, Вы писали:
E>5-6?
Обычно подобные вопросы через это время сами проходят, остаются другие
E>Как следствие -- код лучше вообще не писать
писать или не писать, вот в чем вопрос... не хотя бы для интереса писать все же стоит
Здравствуйте, krokodil955, Вы писали:
K>Всем здрям! K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО. http://www.rsdn.ru/res/book/prog/programming_pearls.xml
... "Все программисты делают ошибки. Я — программист, значит, мой код тоже содержит ошибки. Мой код будет содержать ошибки. Даже самые крутые гуру делают ошибки."
Через некоторое время придёт осознание, а вслед за ним — просветление.
Здравствуйте, krokodil955, Вы писали:
K>Всем здрям! K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО. K>Заранее благодарен.
Имхо, не так уж это нереально.
Просто при написании надо запустить в голове много фоновых процессов, которые контролируют качество кода и писать медленно.
Здравствуйте, krokodil955, Вы писали:
K>Всем здрям! K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО.
--
Много полезной конкретной информации можно найти в книге "Code Complete" by Steve McConnell.
Здравствуйте, krokodil955, Вы писали:
K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО.
А что называть качественным кодом? Я всегда считал, что это код, который учитывает все ньюансы системы/приложения (в том числе и внешнее воздействие на нее/него), возникающие на стадии тестирования и (!)эксплуатации. Беда в том, что на стадиях проектирования и разработки, все эти ньюансы не известны. Т.о. осмелюсь заметить, что ИМХО в 100% случаев писать качественный код — это фантастика.
И как говорил Edward A Berard (немного не о том, но суть та же):
Walking on water and developing software from specification are easy, if both are frozen.
Здравствуйте, SilverCloud, Вы писали:
SC>... "Все программисты делают ошибки. Я — программист, значит, мой код тоже содержит ошибки. Мой код будет содержать ошибки. Даже самые крутые гуру делают ошибки." SC>Через некоторое время придёт осознание, а вслед за ним — просветление.
"...Человеку несвойственно совершенство, и оно является необходимым лишь в немногих сферах его деятельности. Мне кажется, что при освоении программирования труднее всего привыкнуть к требованию совершенства..."
Фредерик П.Брукс. "Мифический человеко-месяц или как создатся программные системы"
Вот просто интересно, за что человеку минусов понаставили. Минус это как известно "Не согласен" (см. tooltip), значит Nickolay Ch и Plague не согласны что надо думать?
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, krokodil955, Вы писали:
K>Вопрос может конечно и банальный но все-таки подскажите: K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) и киньте плз любую инфу на эту тему а также по тестированию ПО.
Ну... если тебя не интересует время и в тебе есть литературная струнка, то можешь побробовать литературное программирование (оно же иногда упоминимается как содержательное или документированное, но последний термин не совсем точно отражает суть).
Здравствуйте, vitaly_spb, Вы писали:
OT>>Думать не пробовал, когда код пишешь?
_>Вот просто интересно, за что человеку минусов понаставили. Минус это как известно "Не согласен" (см. tooltip), значит Nickolay Ch и Plague не согласны что надо думать?
Лично я не согласен с такой формой ответа.
Вам бы понравилось, если б я в ответ на Ваш вопрос написал то же самое?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, krokodil955, Вы писали:
K>>Всем здрям! K>>Вопрос может конечно и банальный но все-таки подскажите: K>>как сразу писать качественный код GZ>Никак. По крайней мере не научился. Некачественно написать легче. И сразу же доработать напильником для качества.
Кажется у Кернигана было, научится прграмировать можно только програмируя. Это как езда на велосипеде можно прочитать об этом десятки книжек, но без практики вы на нём не поедете и наверняка пока научитесь набъёте немало шишек, а может и охота этим заниматся пропадёт, хотя умные книжки тоже надо читать, но надо подкреплять их практическим опытом закрепляя прочитаное.
GZ>http://www.rsdn.ru/res/book/prog/refactoring.xml
GZ>Вобщем, ключевые слова — экстремальное программирование, TDD, рефакторинг. Там тестирование используется как методика на этапе написания кода. То что нужно программисту.
По собственному опыту, тот же рефакторинг с неплогохо качества, по вашему мнению, кода даёт значительно лучшие результаты чем написать сразу тяп-ляп, а потом доводить до ума. Просто принятые из самого начала неверные решения изза отсутствия этапа более детального анализа просто не могут привести к качественому решению.
Да XP это круто при небольшой команде и ограниченых ресурсах, но хорошие результаты как по мне получаются только когда каманда разработчиков, по крайней мере большая её часть, достаточно высокого уровня. Это как разводной ключ, умелый сантехник за раз им соединения соединит, а неумелый только резьбу сорвёт(гы просто недавно краны менял )
Лично я для себя данную проблему решил сменой основного языка на тот, который не пропускает большинство распространенных ошибок
Это после многих лет профессионального программирования
Если такое решение устраивает, то добро пожаловать в формальное программирование и на http://www.haskell.org
reductor wrote: > > Лично я для себя данную проблему решил сменой основного языка на тот, > который не пропускает большинство распространенных ошибок > Это после многих лет профессионального программирования > > Если такое решение устраивает, то добро пожаловать в формальное > программирование и на http://www.haskell.org
Меня интересует, понимания ради, а не флейму для , как Хаскель
вписывается в, скажем так, коммерческое (не академическое) программирование.
А именно:
1. Где брать кадры?
2. Как преодолевать естественное сопротивление менеджеров?
3. Для каких практических проектов он подходит? (только не надо
говорить, "для всех" — это отписка, и я сразу приведу опровергающий пример).
4. Насколько получающиеся программы ресурсоемки? Тут бы хотелось
какой-то практический ответ, а не сравнение с C/C++/C#/Java/Perl/... —
такие сравнения не имеют смысла.
5. Насколько хорошо получающиеся программы живут под операционными
системами, которыми пользуются пользователи?
Это конечно уже выходит за рамки как философии, так и программирования, но
Pzz>Меня интересует, понимания ради, а не флейму для , как Хаскель Pzz>вписывается в, скажем так, коммерческое (не академическое) программирование.
Pzz>А именно: Pzz> 1. Где брать кадры?
Если в России, то воспитывать.
Я серьезно. Брать студентов и учить вручную — на практике выходит гораздо эффективнее, брать ученых в пользу менее эффективного инструмента. Конкретно хаскель по опыту (я четырех человек обучил) свежими (не обремененными специальностью) мозгами усваивается очень быстро — благо там учить нечего, язык простой как три рубля.
Pzz> 2. Как преодолевать естественное сопротивление менеджеров?
Ну, кроме мудрых речей ничего в голову не приходит. Простого ответа тут конечно нет, но и мотивация у менеджеров всегда разная. Лично моя была бы моей ленью и нежеланием слышать потом вопли идиотов, что их заставляют выкручивать себе мозги, лечилось бы обещанием взять их на себя
Pzz> 3. Для каких практических проектов он подходит? (только не надо Pzz>говорить, "для всех" — это отписка, и я сразу приведу опровергающий пример).
Конечно не для всех. Однозначно не подходит для написания драйверов и для реального времени (язык с ленивой семантикой, потому выполнение нестрогое). Как язык со статической и строгой типизацией, видимо, не самый лучший кандидат на скриптинг (ну на одноразовый по крайней мере).
В остальном принципиальных ограничений нет, но больше всего остальных он обходит в написании компиляторов, системах со сложной логикой (сложными правилами и алгоритмами), системах, где нужна максимальная надежность (медицина, армия, космос и тп)
А так — спектр очень широкий в т.ч благодаря и довольно сильным метавозможностям даже без макросов (TemplateHaskell).
Вот недавно я попробовал GUI всякий пописать, так там в wxhaskell целый свой маленький язык сделан на комбинаторах — в результате все описывается очень компактно и понятно в xml-подобном стиле.
Pzz> 4. Насколько получающиеся программы ресурсоемки? Тут бы хотелось Pzz>какой-то практический ответ, а не сравнение с C/C++/C#/Java/Perl/... - Pzz>такие сравнения не имеют смысла.
Однозначно тут ответить нельзя — некоторые конструкции (особенно у начинающих) могут и медленно работать и потреблять дикое количество памяти (всеж на рекурсии да на копировании). Но уверенных руках хаскель (в данный момент и в данном случае речь идет о GHC в первую очередь) очень эффективен — то есть кое где и Си оставит позади (в основном благодаря более аккуратной работе со всякими структурами и ленивому вычислению). Замечу еще что теоретически он может компилироваться в _очень_ эффективный код, но современные компиляторы пока далеки от совершенства в этом плане, потому какие-то вещи приходится конечно оптимизировать руками (явно объявлять принудительное вычисление аргументов и использовать там например массивы вместо более удобных списков где-то). Я не знаю как дать более практический ответ. Память вовсе не является его слабым местом (она или вся быстро уходит или на минимальном уровне потребляется ) А по скорости хаскель проседает (настолько, что есть смысл задумывать о переписывании функции на Си) в основном когда нужны битовые операции и всякая такая гадость.
Pzz> 5. Насколько хорошо получающиеся программы живут под операционными Pzz>системами, которыми пользуются пользователи?
Речь про windows, я так понимаю
Ничего кроме того, что адреса двух главных разработчиков GHC заканчиваются на @microsoft.com я сказать не могу
А вот на маке чтобы заставить корректно работать wxhaskell мне пришлось попотеть (хотя это претензии скорее напрямую к wxwidgets)
Здравствуйте, krokodil955, Вы писали:
K>как сразу писать качественный код (т.е. с минимальным числом алгоритмических ошибок и чтобы как можно меньше их исправлять на стадии тестирования) ...
Умный вещь №1: Никак. Ибо человеком сие проделать невозможно по определению.
Но! Можно построить систему и ритуалы которые помогают
а) локализовать ошибки
б) минимизировать последствия ошибок
Например:
1) сначала нарисовать кубики на бумаге, как ни парадоксально но помогает здорово. (это то что предыдущие ораторы подразумевали под "думать")
2) создавая файл (модуль) четко знать — здесь я буду писать вот это.
3) пиши изначально простой код, классы и функции.
3a) тело функций как правило не должно превышать видимой области в редакторе.
3б) использование сложных конструкций типа stl templates на первых порах ограничить до минимума. До тех пор пока точно не будешь знать что они делают.
4) базовые, принципиальные кубики в основании программы проверять тестами по ходу (unit testing).
5) не лениться и все базовые параметры и вход процедур проверять асертами (assert) — проверенно — очень эффективно отсекаются очень многие несуразицы.
Еще кто вспомнит чего?
И еще, универсального решателя задач пока не придумано. Сооветсвенно не сущесвует
надежных автоматических методик проверки истинности. Т.е. на компайлер надейся, но сам не плошай.
Ну м понятно что сие есть сугубо мой личный результат увлекательного
процесса хождения по граблям.
Здравствуйте, Nickolay Ch, Вы писали: NC>Здравствуйте, vitaly_spb, Вы писали: OT>>>Думать не пробовал, когда код пишешь? _>>Вот просто интересно, за что человеку минусов понаставили. Минус это как известно "Не согласен" (см. tooltip), значит Nickolay Ch и Plague не согласны что надо думать? NC>Лично я не согласен с такой формой ответа. NC>Вам бы понравилось, если б я в ответ на Ваш вопрос написал то же самое?
Отличие в том, что отвечают не вам.
Здравствуйте, Stoune, Вы писали:
GZ>>Никак. По крайней мере не научился. Некачественно написать легче. И сразу же доработать напильником для качества. S>Кажется у Кернигана было, научится прграмировать можно только програмируя. Это как езда на велосипеде можно прочитать об этом десятки книжек, но без практики вы на нём не поедете и наверняка пока научитесь набъёте немало шишек, а может и охота этим заниматся пропадёт, хотя умные книжки тоже надо читать, но надо подкреплять их практическим опытом закрепляя прочитаное.
Ты не понял. Это у меня стиль такой. Вначале я пишу функцию. А потом просматриваю что у меня получилось. И если некрасиво(а такое бывает часто), то рефакторю неотходя от кассы, и не забывая что пять минут назад делал. И уж тем более не чекиня такие изменения.
S>По собственному опыту, тот же рефакторинг с неплогохо качества, по вашему мнению, кода даёт значительно лучшие результаты чем написать сразу тяп-ляп, а потом доводить до ума.
Тут я совсем не понял. Что такое "лучшие результаты рефакторинга"?
И сразу же доработать напильником для качества.
)
