Комментарии 16
Мне понравился пост. Советы, лично для меня, не новы, но вдохновляет.
Автору:
Уделяйте больше внимания русскому языку. Этот пост тяжело читать. Надеюсь, что следующие будут лучше в этом плане.
Автору:
Уделяйте больше внимания русскому языку. Этот пост тяжело читать. Надеюсь, что следующие будут лучше в этом плане.
У вас кончились, держите: ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,.
Тесты для TDD не составляются, а пишутся. И не в момент продумывания архитектуры, а при вводе каждого нового элемента поведения.
1 — спорно, 2 — кэп, 3 — чушь, 4 — кэп.
Порадовала ваша лаконичность
Соответственно, конкретика:
1. Тонны говнокода не сделают из джуниора сеньора.
А вот хороший код написанный после чтения правильных книг и правильных советов — да.
Поэтому правильный совет — больше читайте и больше общайтесь на конференциях, тусовках, социалках и так далее.
3. Ну как бы сразу отправляемся читать Мартина Фаулера и прочих agile-гуру.
1. Тонны говнокода не сделают из джуниора сеньора.
А вот хороший код написанный после чтения правильных книг и правильных советов — да.
Поэтому правильный совет — больше читайте и больше общайтесь на конференциях, тусовках, социалках и так далее.
3. Ну как бы сразу отправляемся читать Мартина Фаулера и прочих agile-гуру.
Коллеги, не делайте так как пишет автор никогда.
1. Изучение всего и много, очень хорошо пока вы учитесь, как правило это студенческие годы,
тогда да, можно учить и линуксы и потоки и over 9000 языков и фреймворков. Это время поиска себя.
К окончанию ВУЗа же, уже стоит найти свою нишу, то что больше по душе, и наращивать свои знания в этой области, потому как знать хорошо абсолютно все, невозможно. А отличное знание одной-двух-трех областей обеспечит вам и достойную жизнь и интересные задачи, с которыми приятно будет заниматься.
Это не значит, что не стоит пробовать, что-то новое, конечно, стоит, но только когда вы овладеете на достаточном уровне чем-то одним(двумя-тремя).
2. В наше время тестирование не закладывают в сроки только в самых дремучих и отсталых компаниях, не ходите туда работать. Не ходите работать и туда где сроки ставит только «Бизнес» — потратите нервы, испортите карму.
3. Проектирование — это здорово. Но проектирование != UML. Проектируйте так как вам удобнее. Не проектируйте большими кусками, если вы не старый бородатый дядька с 20+ годами стажа, от вас этого и не потребуют. Скорее всего максимум, что вы лично будете проектировать, это некоторые модули классов не более чем на 50-70. Разбивайте проектирование на подзадачи. Не проектируйте до последнего метода, все равно придется менять.
Что такое TDD автор не знает, никто не пишет ВСЕ тесты сразу после проектирования архитектуры. Тесты пишутся вместе с кодом. Автор, открываем Бека и читаем.
4. Капитанщина. На деле, гуру рекомендуют покрывать внешние вызовы тестами. Конечно, если недоступны родные тесты используемых библиотек. Если же они есть, изучите их, тесты — отличные примеры и документация возможностей.
В единственном я согласен с автором, хотя он высказал это в более мягкой форме — Пиши код блеять!
1. Изучение всего и много, очень хорошо пока вы учитесь, как правило это студенческие годы,
тогда да, можно учить и линуксы и потоки и over 9000 языков и фреймворков. Это время поиска себя.
К окончанию ВУЗа же, уже стоит найти свою нишу, то что больше по душе, и наращивать свои знания в этой области, потому как знать хорошо абсолютно все, невозможно. А отличное знание одной-двух-трех областей обеспечит вам и достойную жизнь и интересные задачи, с которыми приятно будет заниматься.
Это не значит, что не стоит пробовать, что-то новое, конечно, стоит, но только когда вы овладеете на достаточном уровне чем-то одним(двумя-тремя).
2. В наше время тестирование не закладывают в сроки только в самых дремучих и отсталых компаниях, не ходите туда работать. Не ходите работать и туда где сроки ставит только «Бизнес» — потратите нервы, испортите карму.
3. Проектирование — это здорово. Но проектирование != UML. Проектируйте так как вам удобнее. Не проектируйте большими кусками, если вы не старый бородатый дядька с 20+ годами стажа, от вас этого и не потребуют. Скорее всего максимум, что вы лично будете проектировать, это некоторые модули классов не более чем на 50-70. Разбивайте проектирование на подзадачи. Не проектируйте до последнего метода, все равно придется менять.
Что такое TDD автор не знает, никто не пишет ВСЕ тесты сразу после проектирования архитектуры. Тесты пишутся вместе с кодом. Автор, открываем Бека и читаем.
4. Капитанщина. На деле, гуру рекомендуют покрывать внешние вызовы тестами. Конечно, если недоступны родные тесты используемых библиотек. Если же они есть, изучите их, тесты — отличные примеры и документация возможностей.
В единственном я согласен с автором, хотя он высказал это в более мягкой форме — Пиши код блеять!
Благодарю Вас за информативный комментарий
1. Я не совсем об этом. Дело в том, что в любой сфере всегда есть огромное поле для обучения. Более того, после универа я стал обучаться намного больше и активнее. Взять например Android, работая с данной ОС мой путь (в плане изучения) был таков: программирование на Java под эту ОС, далее полез изучать вспомогательные фреймворки (ORM, аннотации и.д.), потом стал писать на C++ и а далее и вовсе начал ковырять исходники Android. Некоторые навыки не пригодились, но 99 процентов полученных знаний дали прикладную отдачу. И мой перечень того, что я хотел бы выучить в данной платформе и близко не близиться к концу, а скорее наоборот растет;
2. Не соглашусь, однако и опровергнуть в силу многих обстоятельств не могу;
3. Спасибо за совет, я судя по всему действительно плаваю в терминологии и по этому не четко изложил свою мысль, но, очень постараюсь исправиться к следующей статье;
4. В последнем пункте я совсем говорил не о тестах а о необходимости изучать «физику процесса». Сегодня очень много программистов привыкли исправлять следствия а не причины и это печально =(
1. Я не совсем об этом. Дело в том, что в любой сфере всегда есть огромное поле для обучения. Более того, после универа я стал обучаться намного больше и активнее. Взять например Android, работая с данной ОС мой путь (в плане изучения) был таков: программирование на Java под эту ОС, далее полез изучать вспомогательные фреймворки (ORM, аннотации и.д.), потом стал писать на C++ и а далее и вовсе начал ковырять исходники Android. Некоторые навыки не пригодились, но 99 процентов полученных знаний дали прикладную отдачу. И мой перечень того, что я хотел бы выучить в данной платформе и близко не близиться к концу, а скорее наоборот растет;
2. Не соглашусь, однако и опровергнуть в силу многих обстоятельств не могу;
3. Спасибо за совет, я судя по всему действительно плаваю в терминологии и по этому не четко изложил свою мысль, но, очень постараюсь исправиться к следующей статье;
4. В последнем пункте я совсем говорил не о тестах а о необходимости изучать «физику процесса». Сегодня очень много программистов привыкли исправлять следствия а не причины и это печально =(
1. Безусловно, если вы изучаете Android, значит вы должны знать все об андройде. С этим я согласен. Я о том что не стоит изучать сегодня Android, завтра WP, после завтра Symbian. Мало того, положа руку на сердце, разницы в итоге не много, если представляешь общую канву построения мобильных приложений, то опираясь на опыт одной платформы, относительно не сложно путем сравнения перелезть на другую, если жизнь заставит.
2. Объясню свою позицию — жизнь коротка, а работы для нашей профессии сейчас очень и очень много и хорошей работы тоже очень много, не стоит тратить жизнь на работу, которая приносит много проблем и держит в постоянном стрессе. Человек проводит на работе большую часть своей жизни, поэтому от работы надо получать удовольствие.
3. Кстати я Бека не зря рекомендую, все-таки он основоположник TDD, мало того Java (с которой вы работаете) наверное, самая удобная платформа для TDD, для нее есть практически все нужные инструменты хорошего качества.
4. Если изучать физику процесса в каждом случае, то никакого времени не хватит (я не говорю про Just for fun, я именно про рабочую ситуацию), по идее рассматривать любое внешнее приложение/библиотеку стоит как черный ящик, до тех пор пока ее поведение соответствует вашим ожиданиям, если что-то пошло не так, тогда да, можно разобраться.
2. Объясню свою позицию — жизнь коротка, а работы для нашей профессии сейчас очень и очень много и хорошей работы тоже очень много, не стоит тратить жизнь на работу, которая приносит много проблем и держит в постоянном стрессе. Человек проводит на работе большую часть своей жизни, поэтому от работы надо получать удовольствие.
3. Кстати я Бека не зря рекомендую, все-таки он основоположник TDD, мало того Java (с которой вы работаете) наверное, самая удобная платформа для TDD, для нее есть практически все нужные инструменты хорошего качества.
4. Если изучать физику процесса в каждом случае, то никакого времени не хватит (я не говорю про Just for fun, я именно про рабочую ситуацию), по идее рассматривать любое внешнее приложение/библиотеку стоит как черный ящик, до тех пор пока ее поведение соответствует вашим ожиданиям, если что-то пошло не так, тогда да, можно разобраться.
Я думаю мы с Вами стоим на одних позициях, так как согласен со всем сказанным Вами.
1. Думаю что «универсальный» разработчик часто является поверхностным, углубиться можно действительно лишь в очень узкий круг вопросов. Это и плюс и минус одновременно.
3. Огромное спасибо!
4. И я о том же, проблема в том что при возникновении вне штатных ситуаций многие исправляют следствия. Например перехватывают частные (неверные) случаи которые возвращает библиотека и корректируют результат. Тем самым усложняют код не нужными эвристиками не изучив суть. В остальных случаях я согласен, нету ни малейшей возможности изучить все что используешь(по крайней мере не сразу).
1. Думаю что «универсальный» разработчик часто является поверхностным, углубиться можно действительно лишь в очень узкий круг вопросов. Это и плюс и минус одновременно.
3. Огромное спасибо!
4. И я о том же, проблема в том что при возникновении вне штатных ситуаций многие исправляют следствия. Например перехватывают частные (неверные) случаи которые возвращает библиотека и корректируют результат. Тем самым усложняют код не нужными эвристиками не изучив суть. В остальных случаях я согласен, нету ни малейшей возможности изучить все что используешь(по крайней мере не сразу).
Содержание слабо отражает первую часть названия статьи. Мне нравиться такой вариант: «Некоторые принципы обучения программированию».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Философия программирования. Некоторые принципы обучения