“Bu web sitesini / uygulamayı nasıl inşa edersiniz” görüşme soruları için genel düşünce süreci [kapalı]


14

"Nasıl bir fotoğraf albümü uygulaması tasarlayacağınızı açıklayın", "Bu web sitesinin bu özel özelliğini nasıl tasarlayacağınızı açıklayın" (örneğin Facebook'ta beğenme, Amazon'da öneri, alışveriş sepeti, oyun) siyah jak). Peki, bu şeyin milyonları varsa? Ne değiştirirdin?

Bu bir veritabanı şeması ya da bir grup sınıf tanımı (ya da her ikisi?) Bekliyor gibi görünüyor. Okuldaki veritabanlarını öğrendim, ancak daha önce hiç bir uygulama tasarlamadım ve nereden başlayacağımı, bulduğum tasarımların "iyi" olup olmadığını ve ölçeklenebilir hale getirmek için neleri değiştirebileceğimi bilmekte sorun yaşamadım.

Bu sistemleri tasarlarken genel bir yaklaşım veya düşünce süreci var mı? Ve tasarımda çok fazla ortaya çıkan genel sorunlar / problemlerden kaçınmaya çalışmalıyım? Birisi beni bunlardan birinin (veya her birinin ihtiyaçlarını karşılaştırırken tercihen hepsinden) geçip açıklayabilir mi:

1) Hangi varlıklara ihtiyaç duyulduğunu nasıl buluyorsun? 2) Her şeyin hangi ilişkilere sahip olacağına nasıl karar verirsiniz? 3) Performans optimizasyonunu tasarımınıza nasıl dahil edersiniz? 4) Bunu sınıfları veya veritabanlarını kullanarak mı yaparım? Bir fark yaratır mı (örneğin, gerçekten bir veritabanı tablosuna çevrilemeyen bir sınıfa sahip olur muyum?)

Sormamın temel nedeni, "Kodlama Röportajını Kırma" dan geçiyor olmamdı ve cevaplarımın yazarından tamamen farklıydı - hangi sınıfların önemli olduğu hakkında çok farklı fikirlerim vardı.

Benim GİRİŞİM: Fotoğraf paylaşım uygulaması ile dersleri / tabloları olurdu: Fotoğraf ve Kullanıcı kesinlikle.

Sonra, bir şema oluşturmaya çalışıyorsak, fotoğraftaki her kişinin fotoğrafla bağlantılı olduğunu varsayarsak fotoğraf ve kullanıcı arasında bir tablo olur (bu tablo gerekli mi? çoktan çoğa ilişkiler için ayrı bir tablonuz olsun veya olmasın?).

Ancak, nesne yönelimli bir yaklaşım benimsemeye çalışıyorsak, bunun yerine belki de tüm işi yapan ve diğer iki tablodan / sınıftan tüm bilgilere sahip olan albüm adında bir sınıfımız olurdu. Bu kitapta fark ettiğim bir şey - bir sürü sınıf var ve sonra temelde tüm bilgilere sahip olan ve diğer sınıfları birbirine bağlayan bir sınıf var - bu yaygın mı? Örneğin, yukarıdaki örneklerimde, bu geçerli olacak mı?

Ben sadece bazı genel kurallar / yönergeleri takip umuyorum çünkü şu anda büyük bir sistem için iyi bir mimari neye benzediğini nasıl anlatacağım hakkında hiçbir fikrim yok.


1
Bir fotoğraf albümünü hobi projesi olarak kodladığınızı varsayalım. "Doğru yolda mıyım?" (elbette, tüm gereksinimler bir şekilde karşılanacak olduğundan), muhtemelen "tasarımın bu yönü, işleri gereksiz yere garip hale getiriyor gibi görünüyor; her şeyi daha basit hale getirmek için işleri değiştirebilir miyiz? " Ancak, tasarımın bazı genel yönlerinin olduğunu nereden biliyorsunuz? Kullanım durumları ve en kötü durumlar gibi düşünce deneyleri üzerinde çalışarak. Ayrıca: "bu giriş şartı oldukça yaygındır; kendimizi yeniden keşfetmek yerine bir kütüphane bulabilir miyiz?"
Evgeni Sergeev

Yanıtlar:


19

Bu tür soruların amacı, bir yazılım uygulaması yazma konusunda gerçek dünyadaki becerilerinizin olup olmadığını değerlendirmektir. Bazı teoriler öğrendiniz, ancak teorik bilgi ancak o kadar ileri gidebilir. Yazılım geliştirmeyi gerçekten anlamanın tek yolu bunu yapmaktır.

Bunun kısayolu yoktur, çünkü "hangi varlıklara ihtiyaç var?" Bunun yerine, eldeki soruna pratik bir çözüm bulmak için çeşitli araç ve paradigma deneyimlerinizi ve bunların birlikte nasıl çalıştıklarını uygulamanız gerekir.

"Bunu sınıfları veya veritabanlarını kullanarak yapabilir miyim?" şeylerin ne olduğu ve nasıl çalıştığı hakkında temel bir bilgiye sahip olmamanızı önerir. Sınıflar kodunuzu düzenlemek için bir paradigmadır; veritabanları bir veri depolama yöntemidir. Bunlar, doğası gereği birbiriyle ilişkili olmayan iki kavramdır (birlikte çalışabilirler). Bu bir ya da soru değildir.

Zor olmak istemiyorum, ancak bence böyle bir iş görüşmesinde başarılı olmak için kodlama deneyiminizi geliştirmeniz gerekiyor. Kesinlikle bir potansiyele sahipsiniz - fotoğraf paylaşım uygulaması hakkındaki tartışmanız bazı doğru fikirlere sahip ve doğru yönde ilerliyor. Ama bunun ilk elden nasıl çalıştığını öğrenmeniz gerekiyor. Röportajınıza hazırlanmanın en iyi yolu aslında baştan sona bir uygulama oluşturmaktır. Bir fotoğraf paylaşım uygulaması uygun büyüklükte bir proje olabilir veya başka bir şey seçebilirsiniz. Çalışan bir uygulama yapmak için tüm parçaların birlikte nasıl çalışabileceğini gördüğünüzde bilginiz gerçekten genişleyecektir.


8

Bu bir veritabanı şeması veya bir grup sınıf tanımı (ya da her ikisi mi?)

Bence burada ayrıntılara çok odaklanmışsın. Bu soru ile, işveren yazacağınız tüm sınıfların tam bir açıklamasını beklememektedir (aksi takdirde sizden kod yazmanızı, hakkında konuşmamayı isteyeceklerdir).

Cevabınızın öncelikle büyük resim - mimari, katmanlar, katmanlar, hatta proje yaşam döngüsü ve uygulayacağınız geliştirme süreci hakkında olması gerekir. Yanıtınızı ayarlamak için uygulamanın çalışması gereken gereksinimler ve ortam hakkında soru sormaktan çekinmeyin. Dan1111'in işaret ettiği gibi, doğru bir uygulama tasarımı için genel bir tarif yoktur. Tüm tasarımlar bağlama bağlıdır.

Sadece işveren gerçekten özel sorular sormaya başlarsa, başlık altında hangi sınıfları, varlıkları veya veritabanı tablolarını kullanacağınız hakkında ayrıntılara girmelisiniz.

Ayrıca, çok az deneyiminiz varsa, sadece şu ana kadar öğretilen ve kullandığım uygulama tasarımını kullanarak size bir çözüm göstereceğim. Bunu ve sizi tanımlayabileceğim diğer yaklaşımları biliyorum ama gerçekten onları hiç uygulamadı. Ben de başkalarını keşfetmeye ve uygulamaya açıkım ".

Araç kutunuzda, deneyiminizin sahip olmanıza izin veren çok fazla araç olduğunu kabul etmenin yanlış bir yanı yoktur - aslında, pratikte nasıl çalıştığına dair hiçbir fikriniz olmayan prova bir cevap vermek daha iyidir.


2

İlk sorunuz hakkında hızlı bir yorum yapacağımı düşündüm:

1) Hangi varlıklara ihtiyaç duyulduğunu nasıl buluyorsun?

Yeni bir proje için yaptığım ilk şey, bir beyaz tahtada veya büyük bir boş kağıda, benim ve ekibimin düşünebileceği o proje hakkında tüm fiziksel ve kavramsal şeyleri yazmak. Bu bir beyin fırtınası oturumu.

İsimler nesne olma eğilimindedir, fiiller kullanım senaryoları veya yöntemleri olma eğilimindedir.

Fiziksel: fotoğraf (bariz!), Ekran tipi, sistem, fotoğraf dosyası, dosya formatı, kullanıcı, tarih ....
Kavramsal: ekleme, silme, kaydetme / kaydetme, alma, sıralama, değiştirme, görüntüleme / görüntüleme ...

İsimler ve fiiller arasında bağlantı kurun. Kullanıcı Fotoğraf Ekler. (Şey - bir kullanım örneği var!)

Ayrıca UML ve Tasarım Desenlerine ve bunların genel OOD'da nasıl kullanılabileceğini de öneriyorum. (Uyarı - Yukarıdaki hiçbir yerde bir dil veya veritabanından bahsetmedim. Bir dil seçmeyin ve sonra OOD'nizi yapın. OOD'unuzu tasarımın herhangi bir OOL tarafından uygulanabilecek şekilde yapın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.